CODEWITHSUNDEEP
windowswinapi
hypheni
hypheni

Reputation: 816

GetTickCount on system running more than 49days

According to MSDN GetTickCount API returns system elapsed time only if the system has not been running continuously for 49.7days. If its running more than that, it will return 0.

Anyone have any experience of such incident that this API actually returns 0 on systems, which is running more than 49.7 days?

I need to take some decision based on GetTickCount reported value and if I found 0 I will treat that as a special case and ask user for a system reboot.

Upvotes: 3

Views: 2397

Answers (3)

tenfour
tenfour

Reputation: 36896

Do not check for 0; others have covered why that check is flawed. If you want to avoid the wraparound behavior, avoid GetTickCount altogether. Use GetTickCount64, or if you need to support pre-Vista systems, use GetSystemTimeAsFileTime or QueryPerformanceCounter, which are both available as far back as Windows 2000.

For GetSystemTimeAsFileTime, the returned value is measured in 100-nanosecond ticks since January 1, 1601, so you can convert to milliseconds like this:

DWORD64 MyGetTickCount64()
{
  FILETIME ft;
  GetSystemTimeAsFileTime(&ft);
  DWORD64 ret = (DWORD64(ft.dwHighDateTime)<<32) | ft.dwLowDateTime;
  ret = ret / 10000;// convert to milliseconds.
  return ret;
}

QueryPerformanceCounter could be used like this:

DWORD64 MyGetTickCount64() {
  LARGE_INTEGER freq;
  QueryPerformanceFrequency(&freq);
  LARGE_INTEGER now;
  QueryPerformanceCounter(&now);
  return now.QuadPart / freq.QuadPart * 1000;
}

Upvotes: 2

David Heffernan
David Heffernan

Reputation: 612993

When the tick count rolls over, it goes back to 0 but continues counting. So you can get the following sequence of values: 4294967295, 0, 1, 2 and so on. Contrary to your suspicions, the tick count does not roll over to 0 and then remain there forever more. The tick count continues counting upwards after it has rolled over.

Asking the user to reboot the machine because your program is not capable of counting past 232 seems a rather weak solution to the problem. You should solve the problem properly. Perhaps with GetTickCount64, or indeed some other measurement of time that does not roll over.

Upvotes: 7

Jerry Coffin
Jerry Coffin

Reputation: 490148

No.

GetTickCount wraps around to 0 after 49.7 days, but as soon as it does, it starts counting up again.

You may want to use GetTickCount64 instead (it's been available since Vista). If you need to support older systems (and maybe even if you don't) you might want to use GetSystemTimeAsFileTime instead. This has been available nearly forever (officially listed as Windows 2000, but I think it may be even older than that).

Both of the latter use 64-bit counts, so rollover isn't a problem.

Upvotes: 2

Related Questions