bug check 0x10D (0x1, ...) on hibernate when WDF driver is in the paging path

NTDEV
1

My WDF driver is a bus driver for some xen virtual devices. One of these
virtual devices is a scsiport driver.

I posted a while back that hibernate wasn’t working - my PDO never got
D0Exit with WdfPowerDevicePrepareForHibernation, and I had to work
around it.

Now what I’m finding is that if I hibernate and resume immediately it
all works just fine, but if I hibernate, wait for a bit (say 30 minutes)
and then resume, the system immediately bug checks with 0x10D (0x1, …)
which is WDF_VIOLATION - timeout.

I suspect that what is happening is that because WDF isn’t properly
aware that the system has hibernated, it thinks that the 30 minute delay
between hibernate and resume is caused by a hang rather than the
hibernation.

Assuming that my suspicion is correct (haven’t managed to get a debug
dump yet), is there any way to turn off the bit of WDF that detects the
timeout?

Thanks

James

2

0x1 means that a power callback did not return to KMDF in over 10 minutes. There is a debugger extension which can extend the watchdog period (!wdfkd.wdfextendwatchdog) to 24 hours. The bugcheck parameter after the 0x01 is a pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure which will give you the current state of the power or power policy state machine as well as the PETHREAD of the hung call.

My guess is that you are blocking in one of the power down routines until you resume from hiber and then let things come back online.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, August 17, 2009 11:43 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] bug check 0x10D (0x1, …) on hibernate when WDF driver is in the paging path

My WDF driver is a bus driver for some xen virtual devices. One of these
virtual devices is a scsiport driver.

I posted a while back that hibernate wasn’t working - my PDO never got
D0Exit with WdfPowerDevicePrepareForHibernation, and I had to work
around it.

Now what I’m finding is that if I hibernate and resume immediately it
all works just fine, but if I hibernate, wait for a bit (say 30 minutes)
and then resume, the system immediately bug checks with 0x10D (0x1, …)
which is WDF_VIOLATION - timeout.

I suspect that what is happening is that because WDF isn’t properly
aware that the system has hibernated, it thinks that the 30 minute delay
between hibernate and resume is caused by a hang rather than the
hibernation.

Assuming that my suspicion is correct (haven’t managed to get a debug
dump yet), is there any way to turn off the bit of WDF that detects the
timeout?

Thanks

James

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

3

>

0x1 means that a power callback did not return to KMDF in over 10
minutes.
There is a debugger extension which can extend the watchdog period
(!wdfkd.wdfextendwatchdog) to 24 hours. The bugcheck parameter after
the 0x01
is a pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure which
will give
you the current state of the power or power policy state machine as
well as
the PETHREAD of the hung call.

My guess is that you are blocking in one of the power down routines
until you
resume from hiber and then let things come back online.

Are you referring to ‘D0Exit’ when you say ‘one of the power down
routines’? I assume that if I was blocking in one of those then windows
wouldn’t let the system hibernate would it and it would deadlock
instead, so I’m guessing you are referring to something else?

Thanks

James

4

> 0x1 means that a power callback did not return to KMDF in over 10
minutes.

There is a debugger extension which can extend the watchdog period
(!wdfkd.wdfextendwatchdog) to 24 hours. The bugcheck parameter after
the 0x01
is a pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure which
will give
you the current state of the power or power policy state machine as
well as
the PETHREAD of the hung call.

Should I just be able to use dt to get the
WDF_POWER_ROUTINE_TIMED_OUT_DATA? It says “symbol not found” so I assume
I’m doing something wrong.

James

5

>

0x1 means that a power callback did not return to KMDF in over 10
minutes.
There is a debugger extension which can extend the watchdog period
(!wdfkd.wdfextendwatchdog) to 24 hours. The bugcheck parameter after
the 0x01
is a pointer to a WDF_POWER_ROUTINE_TIMED_OUT_DATA structure which
will give
you the current state of the power or power policy state machine as
well as
the PETHREAD of the hung call.

I should have paid more attention to what you wrote above. The docs say
parameter 0x02 is “Pointer to a WDF_POINTER_ROUTINE_TIMED_OUT_DATA
structure” but of course as you said it’s actually
WDF_POWER_ROUTINE_TIMED_OUT_DATA, so “dt
_WDF_POWER_ROUTINE_TIMED_OUT_DATA” tells me all kinds of things I need
to know.

Thanks

James