How to tell which process set the high timer resolution in Windows

Question

My system is suffering from a high timer resolution (NtQueryTimerResolution returns 0.5ms).

Maximum timer interval: 15.600 ms
Minimum timer interval: 0.500 ms
Current timer interval: 0.500 ms

Some process must be calling NtSetTimerResolution with a value of 5000 (0.5ms), but how can I determine which one? I saw Intel has a tool called Battery Life Analyzer that shows the current timer resolution per process, but that tool is only available to Intel partners. Is there another tool or a way to see it via WinDbg? Note: It seems to happen at boot time as setting a breakpoint isn't working (the resolution is already high when the debugger starts).

Answer 1

I found that Windows 7 keeps track of timer resolution per process in the _EPROCESS kernel structure.

With debugging enabled (boot with /debug) it is possible to browse the ExpTimerResolutionListHead list with windbg (run windbg -kl) and extract timer information like this:

lkd> !list "-e -x \"dt nt!_EPROCESS @$extret-@@(#FIELD_OFFSET(nt!_EPROCESS,TimerResolutionLink)) ImageFileName UniqueProcessId SmallestTimerResolution RequestedTimerResolution\" nt!ExpTimerResolutionListHead"

In my case however the process ID was NULL (probably because a driver made the request), and I still couldn't figure out which driver it was.

Answer 2

The only way I know and have used so far is injecting into each of running processes and inside that process calling timeEndPeriod for each increased resolution (values 1-15) in a loop over these resolutions and checking whether the timeEndPeriod call for a current resolution returns TIMERR_NOCANDO or TIMERR_NOERROR (note: these return values are NOT correspondingly false and true). And if it returns TIMERR_NOERROR then concluding that the program is using that frequency, and then calling again timeBeginPeriod to restore the original resolution requested by the program.

Unfortunately this method does not detect the 0.5 ms timer resolutions that can be set by undocumented NtSetTimerResolution function.

If you want to continuously monitor the new timer resolutions then hooking calls to undocumented NtSetTimerResolution function in ntdll.dll is the way I use currently (the function's signature can be taken for example from here).

Unfortunately hooking does not detect timer resolutions that were requested before the hook was installed, so you need to combine it with the above timeEndPeriod trick and note also that the 0.5 ms resolution requests before the hooking stay undetected.

And I agree, this method seems cumbersome. Moreover, it is a bit intrusive since it modifies the state of the process, and also assumes that you are able to inject into all processes.

If anybody has better methods, I would be interested knowing about them too.

Answer 3

Input

You can run the following command in a Administrative CMD Prompt:

c:\temp> powercfg -energy duration 5

This will create a report called: C:\temp\energy-report.html

This report will show you which processes have changed the Clock Latency/Resolution on your computer. Normally these are RTC (Real-Time Communication) applications, but as you have noticed can be Chrome and other applications.

Output

An (albeit German) example of the output looks like this. Sorry I don't have access to an English client at the moment.

First Statement in Report: Something has changed

Plattform-Zeitgeberauflösung:Plattform-Zeitgeberauflösung

Die standardmäßige Plattform-Zeitgeberauflösung beträgt 15,6 ms (15625000 ns) und sollte immer dann verwendet werden, wenn sich das System im Leerlauf befindet. Wenn die Zeitgeberauflösung erhöht wird, sind die Technologien zur Prozessorenergieverwaltung möglicherweise nicht wirksam. Die erhöhte Zeitgeberauflösung kann auf eine Multimediawiedergabe oder Grafikanimationen zurückzuführen sein.

Aktuelle Zeitgeberauflösung (100-ns-Einheiten) 10000 <<=== CURRENT SETTING
Maximale Zeitgeberperiode (100-ns-Einheiten) 156250 <<== DEFAULT SETTING

Second Statement in Report: The Culprit

Plattform-Zeitgeberauflösung:Ausstehende Zeitgeberanforderung

Von einem Programm oder Dienst wurde eine Zeitgeberauflösung angefordert, die kleiner als die maximale Zeitgeberauflösung der Plattform ist.

Angeforderter Zeitraum 10000 <<== Requested Clock Latency
ID des anfordernden Prozesses 12592 <<== Process ID of application requesting different Clock Latency
Pfad des anfordernden Prozesses \Device\HarddiskVolume4\Program Files (x86)\C4B\XPhone Connect Client\C4B.XPhone.Commander.exe <<== The culprit

The information can be separated from each other and can contain different modules in between the individual blocks, but you should be able to find the culprit armed with the information provided above.