A_TickCount is inaccurate after leaving the computer off for a few hours

[asdsk9skdsdas]

I have a script that I have scheduled with Task Scheduler to run at log in/system start; however, I have noticed that the if condition I have set with A_TickCount always fails if I run the script after my computer has been shutdown for a few hours. When the script fails, if I restart my computer, it works, so it is clearly caused by A_TickCount being inaccurate after shutting down for a few hours. Example script:

Code: Select all

#NoEnv
SetWorkingDir %A_ScriptDir%
SetWinDelay, 1
#NoTrayIcon

if (A_TickCount < 300000) 
{
	MsgBox, Test
}

Edit:
QueryPerformanceCounter() value at boot


A_TickCount value at boot


The values are confirmed to not start from 0 at boot after a few hours of shutting down.

[just me]

A_TickCount cannot be inaccurate because it always contains what GetTickCount() returns.

[JoeWinograd]

A_TickCount being inaccurate after shutting down for a few hours

Check out my article:
How to solve the problem of incorrect System Uptime being reported when a system has been up for a long time

Scroll down to the paragraph that begins with this:

As a final comment on the issue of determining system uptime, it has been documented that TickCount functions can be inaccurate in Windows 10 because of the Fast Startup feature, which is enabled by default in W10. You may disable it (when logged in as an admin) as follows:

Maybe that's the reason in your case. Regards, Joe

[just me]

... it has been documented that TickCount functions can be inaccurate in Windows 10 because of the Fast Startup feature ...

They aren't inaccurate. The system remains in a suspended state and won't be shut down.

[JoeWinograd]

They aren't inaccurate.

OK, I see your point, but it depends on your definition of "inaccurate", imo. I'm fine with calling it "inaccurate" in this situation, along with the accompanying comment on Fast Startup. Pretty much semantics, imo...not worth a diatribe. Regards, Joe