I’ve written a driver for a high precision time source, and am feeding this data to a Windows Time Provider I have written which is then used by the Windows Time Service (w32time).
As part of the time provider I get callbacks when something has forced a change in system time; however I can’t track down ‘who’ is setting the clock. I have disabled NTP as best as I know how, and am not doing any manual clock changes nor am I programmatically setting the clock. Yet still, I can see ‘something’ is setting my clock on a roughly 3 minute periodic interval.
Does kernel debugging via WinDbg slam my clock periodically to maintain some sort of synchronization between host machine and machine under test?
I doubt this very much. Often I don’t need the target to be on LAN, and when
I debug using kernel mode debugging, after several runs ( long breaking into
kernel ) the test machines time lags behind ( normal behavior for a kernel
debugger, ie to freeze time !).
So there must be something other than Windbg that is trying to reset the
clock !!!
-pro
On Wed, Mar 5, 2008 at 2:18 PM, wrote:
> I’ve written a driver for a high precision time source, and am feeding
> this data to a Windows Time Provider I have written which is then used by
> the Windows Time Service (w32time).
>
> As part of the time provider I get callbacks when something has forced a
> change in system time; however I can’t track down ‘who’ is setting the
> clock. I have disabled NTP as best as I know how, and am not doing any
> manual clock changes nor am I programmatically setting the clock. Yet
> still, I can see ‘something’ is setting my clock on a roughly 3 minute
> periodic interval.
>
> Does kernel debugging via WinDbg slam my clock periodically to maintain
> some sort of synchronization between host machine and machine under test?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>… I can’t track down ‘who’ is setting the clock.
No one does. Actually, this is the reason why you get discrepancies in time - the OS should update system time upon the system clock interrupt, but if you broke into the system with a debugger, it does not do it until you resume the system. As Pkokash already pointed out, this is absolutely normal scenario when you do kernel debugging - in order to make your debugging session reliable, the debugger tries its best to preserve the state of the system. Unfortunately, this is just an ideal that cannot get achieved in practice even when you do remote debugging, let alone debug on the same machine (this is the reason why SoftIce had some “twists”) - after all, observing the system “from inside” invariably implies modification to its state. The only scenario when it can get done is when your target debugee runs under the control of hypervisor, so that you observe the system not “from inside” but “from outside”…
Anton Bassov
I think perhaps that on exit from the debugger the system time ‘gets
slammed’. Perhaps that is what the op is seeing?
On Wed, Mar 5, 2008 at 11:55 PM, wrote:
> >… I can’t track down ‘who’ is setting the clock.
>
> No one does. Actually, this is the reason why you get discrepancies in
> time - the OS should update system time upon the system clock interrupt, but
> if you broke into the system with a debugger, it does not do it until you
> resume the system. As Pkokash already pointed out, this is absolutely
> normal scenario when you do kernel debugging - in order to make your
> debugging session reliable, the debugger tries its best to preserve the
> state of the system. Unfortunately, this is just an ideal that cannot get
> achieved in practice even when you do remote debugging, let alone debug on
> the same machine (this is the reason why SoftIce had some “twists”) - after
> all, observing the system “from inside” invariably implies modification to
> its state. The only scenario when it can get done is when your target
> debugee runs under the control of hypervisor, so that you observe the system
> not “from inside” but “from outside”…
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy