KMDF: USB device remote wakeup troubles

Vijairaj_R · November 13, 2007, 8:51am

Hi,
I have a USB device capable of remote wakeup along with a KMDF driver.
I have some trouble getting remote wakeup to work:

The machine is capable of sleeping in S1 and S3.
The machine is capable of remote wakeup from S1 but not from S3.
Power state mapping:
S0 -> D0, S1 -> D2, {S2, S3, S4, S5} -> D3

Now I have two questions:

Is it possible, in WDF, to fail query for S3 and force the machine to
S1? If yes, what is the recommended approach?
* To allow the machine to sleep in S3 without remote wakeup.
* To force the machine to sleep in S1 with remote wakeup.
When the device is plugged out when the system is in S3, then the
system crashes on resume.
* The crash seems to happens during IRP_MN_SET_POWER/System(S0).
* The crash log is attached below.

Has someone seen this behaviour?

–
Warm regards,
Vijairaj

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, f99d0371, f9ca7968, f9ca7664}

Probably caused by : Wdf01000.sys ( Wdf01000!FxPkgFdo::RaiseDevicePower+50 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3
kd> !analyze -v

Bugcheck Analysis

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f99d0371, The address that the exception occurred at
Arg3: f9ca7968, Exception Record Address
Arg4: f9ca7664, Context Record Address

Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
usbhub!USBH_SetPowerD0+d3
f99d0371 8908 mov dword ptr [eax],ecx

EXCEPTION_RECORD: f9ca7968 – (.exr fffffffff9ca7968)
ExceptionAddress: f99d0371 (usbhub!USBH_SetPowerD0+0x000000d3)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000107
Attempt to write to address 00000107

CONTEXT: f9ca7664 – (.cxr fffffffff9ca7664)
eax=00000107 ebx=81293c0c ecx=811e0fc4 edx=811e0fc4 esi=811e0d50 edi=812db4f0
eip=f99d0371 esp=f9ca7a30 ebp=f9ca7a48 iopl=0 nv up ei pl nz ac po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010213
usbhub!USBH_SetPowerD0+0xd3:
f99d0371 8908 mov dword ptr [eax],ecx ds:0023:00000107=???
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

WRITE_ADDRESS: 00000107

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f99d04b2 to f99d0371

STACK_TEXT:
f9ca7a48 f99d04b2 81b7eeb8 00000100 812db4f0 usbhub!USBH_SetPowerD0+0xd3
f9ca7a64 f99d0727 812db4f0 81b7eeb8 81b7eeb8 usbhub!USBH_PdoSetPower+0x80
f9ca7a84 f99c897b 81b7ef70 81b7eeb8 00000002 usbhub!USBH_PdoPower+0x201
f9ca7aa4 f99c61d8 812db4f0 81b7eeb8 f9ca7ae8 usbhub!USBH_PdoDispatch+0x83
f9ca7ab4 804e3d77 812db438 81b7eeb8 806ed2a4 usbhub!USBH_HubDispatch+0x48
f9ca7ac4 8066a2c5 80560668 81b7ef70 00000001 nt!IopfCallDriver+0x31
f9ca7ae8 805095d4 81b7ef70 81b7eeb8 00000000 nt!IovCallDriver+0xa0
f9ca7afc 80508e36 81b7ef70 81b7eeb8 81b7ef8c nt!PopPresentIrp+0x57
f9ca7b1c f3ce769c 812db438 812db620 812af048 nt!PoCallDriver+0x195
f9ca7b3c f3ce7763 f9ca7b7c f3cfa790 81b7ef94 Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f9ca7b50 f3ce7798 81b7ef94 f9ca7b80 f3cdb0d6 Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0xb6
f9ca7b5c f3cdb0d6 812af048 f9ca7b7c 00000000 Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f9ca7b80 f3cc4d9a 81b7eeb8 f9ca7ba8 f3cc4f9f Wdf01000!FxPkgPnp::Dispatch+0x26e
f9ca7b8c f3cc4f9f 812b2f00 81b7eeb8 812b2f00 Wdf01000!FxDevice::Dispatch+0x7f
f9ca7ba8 804e3d77 812b2f00 81b7eeb8 806ed2a4 Wdf01000!FxDevice::DispatchWithLock+0x5d
f9ca7bb8 8066a2c5 80560668 81b7ef94 00000001 nt!IopfCallDriver+0x31
f9ca7bdc 805095d4 81b7ef94 81b7eeb8 00000000 nt!IovCallDriver+0xa0
f9ca7bf0 80508e36 81b7ef94 81b7eeb8 81b7efb8 nt!PopPresentIrp+0x57
f9ca7c10 805090a7 812b2f00 812b2fd0 00000000 nt!PoCallDriver+0x195
f9ca7c2c f3ce643f 812b2f00 00000002 00000001 nt!PoRequestPowerIrp+0x129
f9ca7c68 f3ce6b06 00000001 00000001 f9ca7cf0 Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x4d
f9ca7c78 f3ce5592 812af048 f3cfb9c8 812af048 Wdf01000!FxPkgPnp::PowerPolSystemWakeDeviceWakeTriggeredS0+0x11
f9ca7cf0 f3ce607d 0000052d 812af1bc 812af048 Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
f9ca7d18 f3ce6394 f9ca7d48 806ed0b8 812af1b0 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x20b
f9ca7d2c f3ce6f34 812af048 f9ca7d48 ff72d208 Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x26
f9ca7d58 f3ce6fdc f9ca7d74 80563e8f 812b2f00 Wdf01000!FxEventQueue::EventQueueWorker+0x47
f9ca7d60 80563e8f 812b2f00 812af1b0 80561b7c Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f9ca7d74 804e47fe ff72d208 00000000 8132b020 nt!IopProcessWorkItem+0x13
f9ca7dac 8057dfed ff72d208 00000000 00000000 nt!ExpWorkerThread+0x100
f9ca7ddc 804fa477 804e4729 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Wdf01000!FxPkgFdo::RaiseDevicePower+50
f3ce769c 5f pop edi

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4549b23a

STACK_COMMAND: .cxr 0xfffffffff9ca7664 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Followup: MachineOwner

Michal_Vodicka-2 · November 13, 2007, 12:45pm

I’m not quite sure but it looks like one of USB bugs I’ve encountered in the past. What is your OS version and SP? It can be already fixed.

As for failing S3 query, it is wrong approach and I guess it isn’t allowed at Vista anymore. Sleep without remote wakeup, instead.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, November 13, 2007 2:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: USB device remote wakeup troubles

Hi,
I have a USB device capable of remote wakeup along with a KMDF driver.
I have some trouble getting remote wakeup to work:

The machine is capable of sleeping in S1 and S3.

The machine is capable of remote wakeup from S1 but not from S3.

Power state mapping:
S0 -> D0, S1 -> D2, {S2, S3, S4, S5} -> D3

Now I have two questions:

Is it possible, in WDF, to fail query for S3 and force the machine to
S1? If yes, what is the recommended approach?
* To allow the machine to sleep in S3 without remote wakeup.
* To force the machine to sleep in S1 with remote wakeup.

When the device is plugged out when the system is in S3, then the
system crashes on resume.
* The crash seems to happens during IRP_MN_SET_POWER/System(S0).
* The crash log is attached below.

Has someone seen this behaviour?

–
Warm regards,
Vijairaj

> Use !analyze -v to get detailed debugging information.
>
> BugCheck 7E, {c0000005, f99d0371, f9ca7968, f9ca7664}
>
> Probably caused by : Wdf01000.sys ( Wdf01000!FxPkgFdo::RaiseDevicePower+50 )
>
> Followup: MachineOwner
> ---------
>
> nt!RtlpBreakWithStatusInstruction:
> 804e3b25 cc int 3
> kd> !analyze -v
> ***
> *
> * Bugcheck Analysis
> *
>
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: f99d0371, The address that the exception occurred at
> Arg3: f9ca7968, Exception Record Address
> Arg4: f9ca7664, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> FAULTING_IP:
> usbhub!USBH_SetPowerD0+d3
> f99d0371 8908 mov dword ptr [eax],ecx
>
> EXCEPTION_RECORD: f9ca7968 – (.exr fffffffff9ca7968)
> ExceptionAddress: f99d0371 (usbhub!USBH_SetPowerD0+0x000000d3)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000001
> Parameter[1]: 00000107
> Attempt to write to address 00000107
>
> CONTEXT: f9ca7664 – (.cxr fffffffff9ca7664)
> eax=00000107 ebx=81293c0c ecx=811e0fc4 edx=811e0fc4 esi=811e0d50 edi=812db4f0
> eip=f99d0371 esp=f9ca7a30 ebp=f9ca7a48 iopl=0 nv up ei pl nz ac po cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010213
> usbhub!USBH_SetPowerD0+0xd3:
> f99d0371 8908 mov dword ptr [eax],ecx ds:0023:00000107=???
> Resetting default scope
>
> PROCESS_NAME: System>
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
>
> WRITE_ADDRESS: 00000107
>
> BUGCHECK_STR: 0x7E
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LAST_CONTROL_TRANSFER: from f99d04b2 to f99d0371
>
> STACK_TEXT:
> f9ca7a48 f99d04b2 81b7eeb8 00000100 812db4f0 usbhub!USBH_SetPowerD0+0xd3
> f9ca7a64 f99d0727 812db4f0 81b7eeb8 81b7eeb8 usbhub!USBH_PdoSetPower+0x80
> f9ca7a84 f99c897b 81b7ef70 81b7eeb8 00000002 usbhub!USBH_PdoPower+0x201
> f9ca7aa4 f99c61d8 812db4f0 81b7eeb8 f9ca7ae8 usbhub!USBH_PdoDispatch+0x83
> f9ca7ab4 804e3d77 812db438 81b7eeb8 806ed2a4 usbhub!USBH_HubDispatch+0x48
> f9ca7ac4 8066a2c5 80560668 81b7ef70 00000001 nt!IopfCallDriver+0x31
> f9ca7ae8 805095d4 81b7ef70 81b7eeb8 00000000 nt!IovCallDriver+0xa0
> f9ca7afc 80508e36 81b7ef70 81b7eeb8 81b7ef8c nt!PopPresentIrp+0x57
> f9ca7b1c f3ce769c 812db438 812db620 812af048 nt!PoCallDriver+0x195
> f9ca7b3c f3ce7763 f9ca7b7c f3cfa790 81b7ef94 Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
> f9ca7b50 f3ce7798 81b7ef94 f9ca7b80 f3cdb0d6 Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0xb6
> f9ca7b5c f3cdb0d6 812af048 f9ca7b7c 00000000 Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
> f9ca7b80 f3cc4d9a 81b7eeb8 f9ca7ba8 f3cc4f9f Wdf01000!FxPkgPnp::Dispatch+0x26e
> f9ca7b8c f3cc4f9f 812b2f00 81b7eeb8 812b2f00 Wdf01000!FxDevice::Dispatch+0x7f
> f9ca7ba8 804e3d77 812b2f00 81b7eeb8 806ed2a4 Wdf01000!FxDevice::DispatchWithLock+0x5d
> f9ca7bb8 8066a2c5 80560668 81b7ef94 00000001 nt!IopfCallDriver+0x31
> f9ca7bdc 805095d4 81b7ef94 81b7eeb8 00000000 nt!IovCallDriver+0xa0
> f9ca7bf0 80508e36 81b7ef94 81b7eeb8 81b7efb8 nt!PopPresentIrp+0x57
> f9ca7c10 805090a7 812b2f00 812b2fd0 00000000 nt!PoCallDriver+0x195
> f9ca7c2c f3ce643f 812b2f00 00000002 00000001 nt!PoRequestPowerIrp+0x129
> f9ca7c68 f3ce6b06 00000001 00000001 f9ca7cf0 Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x4d
> f9ca7c78 f3ce5592 812af048 f3cfb9c8 812af048 Wdf01000!FxPkgPnp::PowerPolSystemWakeDeviceWakeTriggeredS0+0x11
> f9ca7cf0 f3ce607d 0000052d 812af1bc 812af048 Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
> f9ca7d18 f3ce6394 f9ca7d48 806ed0b8 812af1b0 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x20b
> f9ca7d2c f3ce6f34 812af048 f9ca7d48 ff72d208 Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x26
> f9ca7d58 f3ce6fdc f9ca7d74 80563e8f 812b2f00 Wdf01000!FxEventQueue::EventQueueWorker+0x47
> f9ca7d60 80563e8f 812b2f00 812af1b0 80561b7c Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
> f9ca7d74 804e47fe ff72d208 00000000 8132b020 nt!IopProcessWorkItem+0x13
> f9ca7dac 8057dfed ff72d208 00000000 00000000 nt!ExpWorkerThread+0x100
> f9ca7ddc 804fa477 804e4729 00000001 00000000 nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FOLLOWUP_IP:
> Wdf01000!FxPkgFdo::RaiseDevicePower+50
> f3ce769c 5f pop edi
>
> SYMBOL_STACK_INDEX: 9
>
> SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: Wdf01000
>
> IMAGE_NAME: Wdf01000.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4549b23a
>
> STACK_COMMAND: .cxr 0xfffffffff9ca7664 ; kb
>
> FAILURE_BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50
>
> BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50
>
> Followup: MachineOwner
>

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

Doron_Holan · November 13, 2007, 1:41pm

it is not possible using only WDF apis to fail query for S3. You can do this if you register a wdm preprocess routine and handle the query Sx. BUT, this is not recommended. What if your driver failed the query S3 and another driver failed the query S1? Then the user cannot put the machine into Sx at all. It is not the driver’s job to veto a query Sx request, it is better to do this from an application so at least the user can interact with the software that is doing the veto

The recommended approach is S3 without remote wake

Known bug in usb. http://blogs.msdn.com/doronh/archive/2006/03/20/556053.aspx. Nothing to do with KMDF

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, November 13, 2007 5:51 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF: USB device remote wakeup troubles

Hi,
I have a USB device capable of remote wakeup along with a KMDF driver.
I have some trouble getting remote wakeup to work:

The machine is capable of sleeping in S1 and S3.
The machine is capable of remote wakeup from S1 but not from S3.
Power state mapping:
S0 -> D0, S1 -> D2, {S2, S3, S4, S5} -> D3

Now I have two questions:

Is it possible, in WDF, to fail query for S3 and force the machine to
S1? If yes, what is the recommended approach?
* To allow the machine to sleep in S3 without remote wakeup.
* To force the machine to sleep in S1 with remote wakeup.
When the device is plugged out when the system is in S3, then the
system crashes on resume.
* The crash seems to happens during IRP_MN_SET_POWER/System(S0).
* The crash log is attached below.

Has someone seen this behaviour?

–
Warm regards,
Vijairaj

Use !analyze -v to get detailed debugging information.

BugCheck 7E, {c0000005, f99d0371, f9ca7968, f9ca7664}

Probably caused by : Wdf01000.sys ( Wdf01000!FxPkgFdo::RaiseDevicePower+50 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
804e3b25 cc int 3
kd> !analyze -v

Bugcheck Analysis

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: f99d0371, The address that the exception occurred at
Arg3: f9ca7968, Exception Record Address
Arg4: f9ca7664, Context Record Address

Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
usbhub!USBH_SetPowerD0+d3
f99d0371 8908 mov dword ptr [eax],ecx

EXCEPTION_RECORD: f9ca7968 – (.exr fffffffff9ca7968)
ExceptionAddress: f99d0371 (usbhub!USBH_SetPowerD0+0x000000d3)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000107
Attempt to write to address 00000107

CONTEXT: f9ca7664 – (.cxr fffffffff9ca7664)
eax=00000107 ebx=81293c0c ecx=811e0fc4 edx=811e0fc4 esi=811e0d50 edi=812db4f0
eip=f99d0371 esp=f9ca7a30 ebp=f9ca7a48 iopl=0 nv up ei pl nz ac po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010213
usbhub!USBH_SetPowerD0+0xd3:
f99d0371 8908 mov dword ptr [eax],ecx ds:0023:00000107=???
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

WRITE_ADDRESS: 00000107

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f99d04b2 to f99d0371

STACK_TEXT:
f9ca7a48 f99d04b2 81b7eeb8 00000100 812db4f0 usbhub!USBH_SetPowerD0+0xd3
f9ca7a64 f99d0727 812db4f0 81b7eeb8 81b7eeb8 usbhub!USBH_PdoSetPower+0x80
f9ca7a84 f99c897b 81b7ef70 81b7eeb8 00000002 usbhub!USBH_PdoPower+0x201
f9ca7aa4 f99c61d8 812db4f0 81b7eeb8 f9ca7ae8 usbhub!USBH_PdoDispatch+0x83
f9ca7ab4 804e3d77 812db438 81b7eeb8 806ed2a4 usbhub!USBH_HubDispatch+0x48
f9ca7ac4 8066a2c5 80560668 81b7ef70 00000001 nt!IopfCallDriver+0x31
f9ca7ae8 805095d4 81b7ef70 81b7eeb8 00000000 nt!IovCallDriver+0xa0
f9ca7afc 80508e36 81b7ef70 81b7eeb8 81b7ef8c nt!PopPresentIrp+0x57
f9ca7b1c f3ce769c 812db438 812db620 812af048 nt!PoCallDriver+0x195
f9ca7b3c f3ce7763 f9ca7b7c f3cfa790 81b7ef94 Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f9ca7b50 f3ce7798 81b7ef94 f9ca7b80 f3cdb0d6 Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0xb6
f9ca7b5c f3cdb0d6 812af048 f9ca7b7c 00000000 Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f9ca7b80 f3cc4d9a 81b7eeb8 f9ca7ba8 f3cc4f9f Wdf01000!FxPkgPnp::Dispatch+0x26e
f9ca7b8c f3cc4f9f 812b2f00 81b7eeb8 812b2f00 Wdf01000!FxDevice::Dispatch+0x7f
f9ca7ba8 804e3d77 812b2f00 81b7eeb8 806ed2a4 Wdf01000!FxDevice::DispatchWithLock+0x5d
f9ca7bb8 8066a2c5 80560668 81b7ef94 00000001 nt!IopfCallDriver+0x31
f9ca7bdc 805095d4 81b7ef94 81b7eeb8 00000000 nt!IovCallDriver+0xa0
f9ca7bf0 80508e36 81b7ef94 81b7eeb8 81b7efb8 nt!PopPresentIrp+0x57
f9ca7c10 805090a7 812b2f00 812b2fd0 00000000 nt!PoCallDriver+0x195
f9ca7c2c f3ce643f 812b2f00 00000002 00000001 nt!PoRequestPowerIrp+0x129
f9ca7c68 f3ce6b06 00000001 00000001 f9ca7cf0 Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x4d
f9ca7c78 f3ce5592 812af048 f3cfb9c8 812af048 Wdf01000!FxPkgPnp::PowerPolSystemWakeDeviceWakeTriggeredS0+0x11
f9ca7cf0 f3ce607d 0000052d 812af1bc 812af048 Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
f9ca7d18 f3ce6394 f9ca7d48 806ed0b8 812af1b0 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x20b
f9ca7d2c f3ce6f34 812af048 f9ca7d48 ff72d208 Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x26
f9ca7d58 f3ce6fdc f9ca7d74 80563e8f 812b2f00 Wdf01000!FxEventQueue::EventQueueWorker+0x47
f9ca7d60 80563e8f 812b2f00 812af1b0 80561b7c Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f9ca7d74 804e47fe ff72d208 00000000 8132b020 nt!IopProcessWorkItem+0x13
f9ca7dac 8057dfed ff72d208 00000000 00000000 nt!ExpWorkerThread+0x100
f9ca7ddc 804fa477 804e4729 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
Wdf01000!FxPkgFdo::RaiseDevicePower+50
f3ce769c 5f pop edi

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4549b23a

STACK_COMMAND: .cxr 0xfffffffff9ca7664 ; kb

FAILURE_BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_VRF_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Followup: MachineOwner

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

Vijairaj_R · November 14, 2007, 12:50am

Thanks Michal and Doron.

That blog article is a nice read.

I couldn’t find a KB article or a hot fix - Is there one available?

Doron_Holan · November 14, 2007, 2:35am

Not yet, one is in the works though

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, November 13, 2007 9:50 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF: USB device remote wakeup troubles