Task Manager’s Performance tab (CPU section) shows the Uptime information of the system, but you may be wondering why your boot-up time doesn’t match the uptime data reported.
This is because Task Manager or WMI wouldn’t deduct the duration of sleep/hibernation when calculating uptime. And, with Fast Startup introduced and enabled by default in Windows 8 and Windows 10, the uptime reported may not correlate with your actual last boot-up time.
Fast startup is a hybrid of cold startup + hibernate. When you shut down the computer with fast startup enabled, the user accounts are logged off completely. Then the system goes to hibernate mode (instead of traditional cold shutdown) so that the next boot up till the login screen will be quicker (30-70 % faster).
Different Ways to Find the System Uptime
There are some of the methods you can use to find the Uptime of your computer, all using WMI.
PowerShell
[DateTime]::Now – [Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime))
Here is the Uptime information.
SystemInfo
From a Command Prompt window, run:
systeminfo | find /i "Boot Time"
Net Statistics
From a Command Prompt window, run:
net statistics workstation
WMIC (WMI’s Command-line Interface)
wmic os get lastbootuptime
That’s in WMI time. But exactly means the same as 1 & 2 above.
Alternately, you can run this command-line:
wmic path Win32_PerfFormattedData_PerfOS_System get SystemUptime
The output will show the uptime of your computer in “Seconds.”
Microsoft Uptime.exe utility
Uptime showed the same.
Task Manager
Task Manager and WMI show incorrect uptime
Every method above showed the same uptime, varying only by a few seconds/minutes, because of the time interval taken for taking screenshots for each item.
But the fact is, the uptime is shown using every method also includes the hibernate time. The actual uptime should be 5 hrs, 55 minutes as of the time (08:24 PM) I’m writing this post. And you can verify that by checking shutdown and login events in Event Viewer.
Workaround 1: Shutdown without preparing for Fast Startup
Running the following command shuts down (cold shutdown) the system completely. But the benefits of fast startup won’t be available for the next boot.
shutdown /s /t 0
(or)
Click Start, Power, and click Restart (instead of Shutdown)
Workaround 2: Disabling Fast Startup
If you want to disable fast startup, you can do so via Power Options.
- Open Control Panel, Power Options.
- Click Choose what the power buttons do
- Click Change settings that are currently unavailable
- Uncheck Turn on fast startup (recommended), and click OK.
Workaround 3: Refresh the uptime Without Disabling Fast startup
- Launch
Services.mscand stop the Windows Management Instrumentation service. - You’ll be prompted to stop the dependent services. Click Yes.
- Open the folder
C:\Windows\System32\Wbem\Repository
- Delete all the files there.
- Restart Windows. Task Manager (or any of the above methods) should show the correct boot-up time now.
But the problem is that you need to clear the WMI repository at every shutdown, or else the uptime would continue to show the aggregated figure.
Workaround 3: Create a Batch File and Run as a Shutdown Script (Windows Pro and higher)
You may create a Batch file with the following contents:
net stop iphlpsvc >d:\wmireset.txt
net stop ncasvc >>d:\wmireset.txt
net stop sharedaccess >>d:\wmireset.txt
net stop wscsvc >>d:\wmireset.txt
net stop winmgmt >>d:\wmireset.txt
sc query winmgmt >>d:\wmireset.txt
rd /s /q "C:\Windows\System32\wbem\repository" >>d:\wmireset.txt
md "C:\Windows\System32\wbem\repository"
date /t >>d:\wmireset.txt
time /t >>d:\wmireset.txtThat writes the batch file output along with the timestamp to a text file named wmireset.txt to know when was the batch file last run.
Then open the Local Group Policy Editor (gpedit.msc) and go to:
Computer Configuration → Scripts (Startup/Shutdown)
Add your batch file there and click OK.
Restart Windows and check the uptime. Also, test if the uptime is refreshed in the subsequent restarts.
Although I’ve not benchmarked the boot-up speed before clearing the WMI repository and after, it may delay your startup time as Windows has to rebuild the repository every time.
One small request: If you liked this post, please share this?
One "tiny" share from you would seriously help a lot with the growth of this blog. Some great suggestions:- Pin it!
- Share it to your favorite blog + Facebook, Reddit
- Tweet it!
the WMIC command is actually:
wmic os get lastbootuptime
This is good write up, detailed and simple
very informative .
I’ve been struggling with this issue for a long time. It’s very frustrating that Windows can’t do something as basic as report proper boot time – something that’s been fundamental to all operating systems since the invention of operating systems. I understand the challenges that Fast Boot presents. But it’s ridiculous that Microsoft has not addressed this issue with an updated WMI call, etc. It should easily be able to make the distinction between a fast boot timestamp and a “true” boot timestamp.
And while I appreciate and applaud your documentation of the various methods, I respectfully disagree with the work-around as an acceptable approach. We shouldn’t have to force a reboot to get an updated timestamp. That’s actually not a work-around at all. And manually manipulating WMI log files, cached data, etc., is completely unacceptable for the user to have to assume the responsibility of that action and the potential side effects – just to obtain a boot timestamp. That’s not a criticism of your creative approach, it’s a criticism of Microsoft.