KMDF driver crashes if USB device is disconnect during "stand by"

Hi all,

My KMDF-based driver crashes if system is put to stand by, then a USB device is disconnected, then system wakes.
I have tried the simplest possible KMDF driver src\kmdf\osrusbfx2\sys\step1\step1.c
but no luck, the crash is still in place.

Scenario:

  1. USB device is connected, the driver loads, everyone is happy.
  2. Stand by or hybernate.
  3. Disconnect the USB device
  4. Wake the PC ===> crash

This is reproduced both with KMDF 1.5 and 1.7 on Windows XP SP2.
I have tried to update the USB stack, was able to bring it to the level of 5.1.2600.3020.
The crash is still there.

Here is the “!analyze -v” output:

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
f85ff371 8908 mov dword ptr [eax],ecx

EXCEPTION_RECORD: f899e9b4 – (.exr 0xfffffffff899e9b4)
ExceptionAddress: f85ff371 (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: f899e6b0 – (.cxr 0xfffffffff899e6b0)
eax=00000107 ebx=820b0ee8 ecx=81eabfc4 edx=81eabfc4 esi=81eabd50 edi=82159438
eip=f85ff371 esp=f899ea7c ebp=f899ea94 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:
f85ff371 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 f85ff4b2 to f85ff371

STACK_TEXT:
f899ea94 f85ff4b2 821cd730 00000500 82159438 usbhub!USBH_SetPowerD0+0xd3
f899eab0 f85ff727 82159438 821cd730 821cd730 usbhub!USBH_PdoSetPower+0x80
f899ead0 f85f797b 821cd7e8 821cd730 00000002 usbhub!USBH_PdoPower+0x201
f899eaf0 f85f51d8 82159438 821cd730 f899eb24 usbhub!USBH_PdoDispatch+0x83
f899eb00 804e13d9 82159380 821cd730 821cd7e8 usbhub!USBH_HubDispatch+0x48
f899eb10 8050e1a2 821cd7e8 821cd730 00000000 nt!IopfCallDriver+0x31
f899eb24 8050e259 821cd7e8 821cd730 821cd804 nt!PopPresentIrp+0x57
f899eb44 a9d66c61 82159380 82159568 81c4eba8 nt!PoCallDriver+0x195
f899eb64 a9d66d28 f899eba4 a9d797a0 821cd80c Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f899eb78 a9d66d5d 821cd80c f899eba8 a9d59bcf Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0xb6
f899eb84 a9d59bcf 81c4eba8 f899eba4 821cd730 Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f899eba8 a9d43665 821cd730 f899ebd0 a9d43888 Wdf01000!FxPkgPnp::Dispatch+0x2a6
f899ebb4 a9d43888 81dbec18 821cd730 80567fe8 Wdf01000!FxDevice::Dispatch+0x7f
f899ebd0 804e13d9 81dbec18 821cd730 821cd80c Wdf01000!FxDevice::DispatchWithLock+0x7b
f899ebe0 8050e1a2 821cd80c 821cd730 00000000 nt!IopfCallDriver+0x31
f899ebf4 8050e259 821cd80c 821cd730 821cd830 nt!PopPresentIrp+0x57
f899ec14 8050e36b 81dbec18 81dbece8 00000000 nt!PoCallDriver+0x195
f899ec30 a9d6586a 81dbec18 00000002 00000001 nt!PoRequestPowerIrp+0x129
f899ec6c a9d65cb7 00000001 00000001 f899ecf4 Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x4d
f899ec7c a9d6449a 81c4eba8 a9d7a9e0 81c4eba8 Wdf01000!FxPkgPnp::PowerPolWokeFromS0+0x11
f899ecf4 a9d64ff3 0000052d 81c4ed20 81c4eba8 Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
f899ed1c a9d657bf f899ed4c 806ff830 81c4ed14 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x21e
f899ed30 a9d664ee 81c4eba8 f899ed4c 81eaba38 Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x26
f899ed60 a9d665af f899ed7c 8056d03c 81dbec18 Wdf01000!FxEventQueue::EventQueueWorker+0x4a
f899ed68 8056d03c 81dbec18 81c4ed14 805694fc Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f899ed7c 804e23b5 81eaba38 00000000 823c63c8 nt!IopProcessWorkItem+0x13
f899edac 80574128 81eaba38 00000000 00000000 nt!ExpWorkerThread+0xef
f899eddc 804ec781 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

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

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47919015

STACK_COMMAND: .cxr 0xfffffffff899e6b0 ; kb

FAILURE_BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Forgot to mention that the crash is reproduced *only* with self-powered USB device.
Bus-powered USB device is ok.

Alexey Polonsky wrote:

My KMDF-based driver crashes if system is put to stand by, then a
USB device is disconnected, then system wakes.

Well-known bug in usbhub.sys. Hopefully this is fixed in XP SP3.

This is a bug in the usb core stack (http://blogs.msdn.com/doronh/archive/2006/03/20/556053.aspx), I think there is a QFE available for this, but I am not 100% sure

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@jungo.com
Sent: Wednesday, April 30, 2008 7:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] KMDF driver crashes if USB device is disconnect during “stand by”

Hi all,

My KMDF-based driver crashes if system is put to stand by, then a USB device is disconnected, then system wakes.
I have tried the simplest possible KMDF driver src\kmdf\osrusbfx2\sys\step1\step1.c
but no luck, the crash is still in place.

Scenario:

  1. USB device is connected, the driver loads, everyone is happy.
  2. Stand by or hybernate.
  3. Disconnect the USB device
  4. Wake the PC ===> crash

This is reproduced both with KMDF 1.5 and 1.7 on Windows XP SP2.
I have tried to update the USB stack, was able to bring it to the level of 5.1.2600.3020.
The crash is still there.

Here is the “!analyze -v” output:

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
f85ff371 8908 mov dword ptr [eax],ecx

EXCEPTION_RECORD: f899e9b4 – (.exr 0xfffffffff899e9b4)
ExceptionAddress: f85ff371 (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: f899e6b0 – (.cxr 0xfffffffff899e6b0)
eax=00000107 ebx=820b0ee8 ecx=81eabfc4 edx=81eabfc4 esi=81eabd50 edi=82159438
eip=f85ff371 esp=f899ea7c ebp=f899ea94 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:
f85ff371 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 f85ff4b2 to f85ff371

STACK_TEXT:
f899ea94 f85ff4b2 821cd730 00000500 82159438 usbhub!USBH_SetPowerD0+0xd3
f899eab0 f85ff727 82159438 821cd730 821cd730 usbhub!USBH_PdoSetPower+0x80
f899ead0 f85f797b 821cd7e8 821cd730 00000002 usbhub!USBH_PdoPower+0x201
f899eaf0 f85f51d8 82159438 821cd730 f899eb24 usbhub!USBH_PdoDispatch+0x83
f899eb00 804e13d9 82159380 821cd730 821cd7e8 usbhub!USBH_HubDispatch+0x48
f899eb10 8050e1a2 821cd7e8 821cd730 00000000 nt!IopfCallDriver+0x31
f899eb24 8050e259 821cd7e8 821cd730 821cd804 nt!PopPresentIrp+0x57
f899eb44 a9d66c61 82159380 82159568 81c4eba8 nt!PoCallDriver+0x195
f899eb64 a9d66d28 f899eba4 a9d797a0 821cd80c Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f899eb78 a9d66d5d 821cd80c f899eba8 a9d59bcf Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0xb6
f899eb84 a9d59bcf 81c4eba8 f899eba4 821cd730 Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f899eba8 a9d43665 821cd730 f899ebd0 a9d43888 Wdf01000!FxPkgPnp::Dispatch+0x2a6
f899ebb4 a9d43888 81dbec18 821cd730 80567fe8 Wdf01000!FxDevice::Dispatch+0x7f
f899ebd0 804e13d9 81dbec18 821cd730 821cd80c Wdf01000!FxDevice::DispatchWithLock+0x7b
f899ebe0 8050e1a2 821cd80c 821cd730 00000000 nt!IopfCallDriver+0x31
f899ebf4 8050e259 821cd80c 821cd730 821cd830 nt!PopPresentIrp+0x57
f899ec14 8050e36b 81dbec18 81dbece8 00000000 nt!PoCallDriver+0x195
f899ec30 a9d6586a 81dbec18 00000002 00000001 nt!PoRequestPowerIrp+0x129
f899ec6c a9d65cb7 00000001 00000001 f899ecf4 Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x4d
f899ec7c a9d6449a 81c4eba8 a9d7a9e0 81c4eba8 Wdf01000!FxPkgPnp::PowerPolWokeFromS0+0x11
f899ecf4 a9d64ff3 0000052d 81c4ed20 81c4eba8 Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
f899ed1c a9d657bf f899ed4c 806ff830 81c4ed14 Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x21e
f899ed30 a9d664ee 81c4eba8 f899ed4c 81eaba38 Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x26
f899ed60 a9d665af f899ed7c 8056d03c 81dbec18 Wdf01000!FxEventQueue::EventQueueWorker+0x4a
f899ed68 8056d03c 81dbec18 81c4ed14 805694fc Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f899ed7c 804e23b5 81eaba38 00000000 823c63c8 nt!IopProcessWorkItem+0x13
f899edac 80574128 81eaba38 00000000 00000000 nt!ExpWorkerThread+0xef
f899eddc 804ec781 804e22f1 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

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

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47919015

STACK_COMMAND: .cxr 0xfffffffff899e6b0 ; kb

FAILURE_BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50


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

Thanks Chris and Doron, the bug indeed seems to be well known.
Hope XP SP3 will solve this.
On Vista RTM the bug does not exist, so the only question is if the bug fix made his way to earlier Windows versions.

Thanks again.