Hello,
I’m looking for any help on figuring out a way to calculate time (system time or relative time) when a miniport driver is in crashdump/hiber mode. Currenlty, it seems that in Windows Vista and Win7, if a call is made to StorPortQuerySystemTime during crashdump/hiber mode, the function will return 0.
Has anyone found a way to calculate, or get, time while in crashdump/hiber mode?
Thanks for any responses,
Ray
> Hello,
I’m looking for any help on figuring out a way to calculate time
(system time
or relative time) when a miniport driver is in crashdump/hiber mode.
Currenlty, it seems that in Windows Vista and Win7, if a call is made
to
StorPortQuerySystemTime during crashdump/hiber mode, the function will
return
0.Has anyone found a way to calculate, or get, time while in
crashdump/hiber
mode?
What sort of accuracy/granularity do you need? You could possibly call
__rdtsc directly if you just want to know how much time has advanced
between this call and the last relative to other calls, assuming that
storport crash dump executes only on the same CPU. If CPU throttling
happens during a crash dump it might reduce the accuracy of this to a
level that becomes useless though.
I’m curious why you need to know this.
James
Hi James,
I’m looking for microsecond granularity, best case. __rdtsc is definitely an option, however, you bring up a good point, crash dump is assumed to happen only on one CPU, even in a multi-processor system. This might be an issue for what I need.
I’m in need of this because I’m looking for a solution to implement timers for a miniport driver while in crashdump/hiber mode. System time is unavailable to me during crash dump mode, so I need a mechanism by which I can implement timers without having access to time. Relativity is fine, but there does not seem to be an easy way to do this. I’m just curious if any other driver developers have faced and resolved this issue before.
Ray
I suspect that you won’t find much more than simple busy/delay loops (a-ka KeStallExecutionProcessor) available at crash dump time. (However I am not an expert in the crash dump stack.) Remember that the less state and complexity you rely on in the crash dump path, the more likely crash dumps are to actually work.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Friday, June 04, 2010 4:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to calculate system time in crashdump/hiber mode in a miniport driver?
Hi James,
I’m looking for microsecond granularity, best case. __rdtsc is definitely an option, however, you bring up a good point, crash dump is assumed to happen only on one CPU, even in a multi-processor system. This might be an issue for what I need.
I’m in need of this because I’m looking for a solution to implement timers for a miniport driver while in crashdump/hiber mode. System time is unavailable to me during crash dump mode, so I need a mechanism by which I can implement timers without having access to time. Relativity is fine, but there does not seem to be an easy way to do this. I’m just curious if any other driver developers have faced and resolved this issue before.
Ray
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
Hi Ken,
This is a good point. A follow-up questions though, does not KeStallExecutionProcessor stall the entire processor so that nothing else runs? In crash dump mode, the windows kernel is forced to a single threaded model, so I’m wondering if stalling the processor is the correct thing to do while single threaded?
Ray
yes and yes.
Make your driver as dumb as possible in dump mode. Don’t call anything function unless you have to.
>
yes and yes.
Make your driver as dumb as possible in dump mode. Don’t call anything
function unless you have to.
Maybe in the web version of this mailing list your response has context,
but in my inbox (Microsoft Outlook) it is completely unclear which post
you were responding to.
James
There is nothing else going on during crash dump other than your dump driver
delivering bytes to the dump device, so stall away to your hearts content.
Of course this assumes that you aren’t expecting some other (non dump stack)
device to asynchronously act on your behalf. That isn’t going to happen, mp
or up.
Mark Roddy
On Fri, Jun 4, 2010 at 8:01 PM, wrote:
> Hi Ken,
>
> This is a good point. A follow-up questions though, does not
> KeStallExecutionProcessor stall the entire processor so that nothing else
> runs? In crash dump mode, the windows kernel is forced to a single threaded
> model, so I’m wondering if stalling the processor is the correct thing to do
> while single threaded?
>
> Ray
>
> —
> 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
>
>crashdump/hiber mode. System time is unavailable to me during crash dump mode
And I expect interrupts are not available for the code during crash dump mode too.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> This is a good point. A follow-up questions though, does not KeStallExecutionProcessor stall the
entire processor so that nothing else runs?
Yes, it’s a busy loop.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Sigh…
As with so many posts here, let’s step back and as the OP:
You have a basic problem to solve. Instead of asking us about a mechanism to implement a solution that you’ve devised for that problem, why not explain the basic problem to us… If you do, maybe we can help you find the best solution.
Peter
OSR