| Date: | May 12, 2015 / year-entry #99 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20150512-00/?p=44884 |
| Comments: | 25 |
| Summary: | Task Manager shows a piece of information called "Up time". How is this value calculated, and why doesn't it agree with the value reported by GetTickCount/GetTickCount64? Task Manager calculates "up time" by subtracting the system boot time from the current time. In other words, it is misnamed; it really should be called time since system... |
Task Manager shows a piece of information called "Up time". How is this value calculated, and why doesn't it agree with the value reported by Task Manager calculates "up time" by subtracting the system boot time from the current time. In other words, it is misnamed; it really should be called time since system was started. It doesn't subtract out the time when the computer was in sleep or hibernation. The tick count, on the other hand, counts only time that elapses while the computer is on. |
Comments (25)
Comments are closed. |
Is this still true? It seems the "Up Time" being reported on my Windows 7 machine right now is indeed up time (about 11 hours) and not time since last boot (about 24 hours ago).
@Adrian i don't think so, my boot time is also 16h30 which isn't the last time i turned it on… Windows 7 too.
Mine is 19 hours and change, which is definitely not the time since I arrived at work this morning, when I last woke it up from hibernation. On the other hand, I did boot it yesterday morning due to Windows Update, so it all fits. See the description here:
windows.microsoft.com/…/see-details-computers-performance-task-manager
And I assume it uses undocumented functions to get the boot time? WMI has LastBootUptime but WMI is not always available. OpenProcess() does not work on the low-level system processes but the right Nt*() function will tell you.
Too bad Taskmanager is not a SDK sample app, it would have forced MS to play by the rules and the documented set of process functions would have been a lot better. On NT4 without psapi you are stuck with only the things (EnumProcesses pid list) OpenProcess has access to.
@skSdnW:
As if Microsoft needs another set of compatibility constraints and another fresh set of failure modes for system and apps. (And no good reason provided)
As for NT4, who cares. it's old system superseded by number of releases.
Klimax: If the NT4 taskmanager had been limited to documented APIs then the Windows team would have been forced to provide a better set of functions and that would have benefited all of us. NT4 might be dead but the usage of private APIs is not and continues to give MS an advantage over the competition…
OpenProcess() used to work on System process back then. And even if it didn't they had another choice. smss.exe started a second or two later and using its time would be good enough.
@skSdnW: Advantage over what competition? Is there a big market space for Windows Task Manager replacements? I consider Task Manager a part of the core operating system, and I would argue that core operating system components are allowed to use private APIs. It's not like we're talking about Office, etc. here.
What's all this nonsense about undocumented APIs in NT4? NT4's Task Manager didn't even show Up Time (and neither did Win2k or XP). But that's not because the information wasn't available — you have always been able to get Up Time from Perfmon (which in turn uses data available from documented performance counters).
Does Task Manager use documented APIs to get System Up Time? I don't know. But I do know that the information is available using documented means.
I don't know if the system uptime you get from the perf counters includes sleep/hibernation but I do know that the perf counters do not provide the process start time which means that you have to fall back to undocumented stuff for System and smss.exe etc…
Here's how Task Manager does it:
stackoverflow.com/…/2604492
@Brian_EE: Well, there are Task Manager replacements, Process Explorer being the most notable one. Process Explorer and the other one I'm aware of both end up using undocumented APIs because some critical information isn't available through documented APIs. And aside from task manager replacements, any product that presents some of the process performance information about itself in a "uniform" way as other data would benefit (I don't know if SQL Server actually does something like this, but a small part of the product I work on does this, and there are some Task Manager and Resource Monitor items that would be useful to make available and also to make available in less "laymen-think-it-is-costly-so-I-have-to-waste-time-explaining-'no-it-is-actually-fine'" way).
@skSdnW: PdhGetRawCounterValue with \SystemSystem Up Time returns a value that looks an awful like a FILETIME in the FirstValue field, so the formatted value probably includes sleep / hibernation.
But on the actual topic, I'm confused by this post and the docs for GetTickCount64 and QueryUnbiasedInterruptTime. GetTickCount64 has this in its remarks: "To obtain the time the system has spent in the working state since it was started, use the QueryUnbiasedInterruptTime function." And QueryUnbiasedInterruptTime has this in the function description: "The unbiased interrupt-time count does not include time the system spends in sleep or hibernation." So it seems like GetTickCount "still advances" the time when the computer is in sleep mode, but QueryUnbiasedInterruptTime behaves as you've described GetTickCount. A short test program running on Windows 7 that outputs the values returned by QUIT and GTC every second shows them roughly in sync with each other until I put the computer to sleep for a short amount of time, after which GTC jumped by ~40 seconds but QUIT advanced only by ~1. Am I misreading both the documentation for those functions and their output? Or has the behavior of GetTickCount changed between versions? I can completely see that I would be reading what I want to read in the docs, but misreading the values returned seems a bit less likely, but still possible, obviously.
Also:
"The elapsed time retrieved by GetTickCount or GetTickCount64 includes time the system spends in sleep or hibernation."
Source: msdn.microsoft.com/…/ms725496.aspx
@skSdnW
"…it would have forced MS to play by the rules…"
What rules? Who are they from? Is this something mandated by the federal government? Or, was this an accord reached by the top tech companies as a global pact (let's call it the Silicon Valley Conventions of 1949)?
"…the usage of private APIs is not and continues to give MS an advantage over the competition…"
Have you seen Google Chrome (especially when it first came out)? I'd argue the guys at Google know something about Win32 programming a better deal than some of the programmers as Microsoft. And I know that has a kernel of truth because Raymond's past posts are full of examples of Microsoft employees getting it wrong (recall that his blog was first a crib sheet for the company before becoming a crib sheet for all of us). I can think of some other examples of third party programs that are quite impressive native desktop apps. I wonder how they do it, you know, being at a disadvantage and all?
skSdnW, you have been a posting on this blog for quite some time. I have a hard time believing that you can be a long time reader and not have any of this material sink in and change your mind that things are not so black/white good/evil over at Microsoft. Bravo to you sir, you are definitely fighting the good fight of the pure GNU/Linux code base against the sullied code bases of all capitalist pig companies. Keep it up!
64-bit tick counts have been supported since XP 64 / Windows 2003. GetTickCount64 was added in Vista. On XP 64 / 2003, you can reinterpret_cast<decltype(&GetTickCount64)>(&GetTickCount). This works because EDX happens to have the high bits of the result. (In 64-bit builds, RAX happens to hold the full 64-bit result, so this still works.)
@Eddie Your incredibly patronizing rant would be rather embarrassing if it turned out that chrome used undocumented APIs because those were the only way to implement some feature, right?
There you go: arstechnica.com/…/1 Even nicely documented by them.
@skSdnW: What is the problem with smss.exe?
I can query WMI with "select * from Win32_Process where Name = 'smss.exe'"
and read CreationDate
@Eddie: They do have their share of issues. For example, I'm still waiting for them to release a version of Chrome that is not battery hungry when idle.
And I think the PEP team of jQuery would be grateful if Google will implement the Pointer Events W3C recommendation instead of extending something different fundamentally instead of properly implement it.
blog.jquery.com/…/getting-on-point
If you also count Android in, the list suddenly grows much much longer… and with WTFs. For example, when I was recently assigned to develop Android Apps, I come across this old bug ( code.google.com/…/detail ) that just marked as obsolete after 3 years after Android 5.0 released. To be fair Microsoft also does this on MS Connect, but this is just problematic.
Why is everyone replying to someone whose name is 'Windows Sucks' abbreviated and reversed? Don't feed the trolls.
> you are definitely fighting the good fight of the pure GNU/Linux code base against the sullied code bases of all capitalist pig companies. Keep it up!
Thanks for the demo of begging the question. I've been guilty of that heaps too.
Raymond > [I can't believe you're recommending that people rely on the value of an unused register. -Raymond]
I'm sorry; after rereading the disassembly, I know now that I mischaracterized what's happening. It's more accurate to say that the assembly code was written to support 64-bit tick counts, but no GetTickCount64 was exported. GetTickCount jumps to this internal 64-bit tick count routine on NT 5.2. EDX is set without anything actually using it, meaning that EDX is intended to be part of the return value of that internal routine.
Also, the only time I advocate such hacks is with *specific past* versions of Windows, when future compatibility is not at risk. If GetTickCount64 exists, obviously, use it. =)
Well then, looks like Myria is recommending normally atrocious behavior exactly where it won't make a difference. Windows 2003 is about to be done being patched.
Windows 7/Vista's Task Manager does give uptime – total time that elapsed while the computer is on minus time in hibernation/sleep. That is consistent with uptime.exe from Windows 2000 Resource Kit. Is there a built-in tool in Windows to calculate time since last reboot? net.exe statistics server gives the time when the OS last booted (Statistics since….)
skDdnW wrote "I do know that the perf counters do not provide the process start time".
They do. Have another look. Maybe squint a little.
@voo:
I didn't mean to say that Google Chrome did not use undocumented APIs. I'm simply addressing the notion that Microsoft has an unfair advantage over the rest of the world that is writing Windows applications. It is reasonable to expect that the NT kernel team can write better systems apps since who better knows the kernel. Likewise, it is reasonable to expect that the shell team can write desktop apps with top notch UI features since who better knows the shell API than the people who write it. However, other teams at Microsoft are clients of the Windows API at the same level as the rest of us. I don't buy into the idea that there is a company wide conspiracy.
@Everybody else:
Sorry for that post as it was rude and patronizing. It's one thing for new comers to find this site and post the usual "MS sucks because of XYZ." That's just a fact of life. But for a regular to keep up the tired old themes is just astonishing (and tiring).