MKDF USB driver crash stack trace

Hi,

Sometime ago I asked a question about a problem with my KMDF USB driver
crashing the system when the device was removed in standby. I was asked to
post the stack trace of that crash.

I was not able to reproduce this problem on my test machine so i had to
reproduce it on my laptop.
When I did that the system did not break into the debugger on my other
machine (which I thought it was supposed to do) but I configured it to save
a kernel dump so I was able to analyze that.

I configured windbg to use the microsoft public symbol store, but it still
could not find the symbols for wdf01000.sys and usbhub.sys.
I am guessing with my limited crash dump knowledge that an exception is
generated in the usb hub driver which is never caught.
(see windbg analysis below)
Is there anything I can do to solve this problem or is this another case of
‘tough luck’

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

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: f7813371, The address that the exception occurred at
Arg3: f7b369cc, Exception Record Address
Arg4: f7b366c8, Context Record Address

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21be

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

FAULTING_IP:
usbhub+c371
f7813371 8908 mov [eax],ecx

EXCEPTION_RECORD: f7b369cc – (.exr fffffffff7b369cc)
ExceptionAddress: f7813371 (usbhub+0x0000c371)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000107
Attempt to write to address 00000107

CONTEXT: f7b366c8 – (.cxr fffffffff7b366c8)
eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8
edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0 nv up ei pl nz ac pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010213
usbhub+0xc371:
f7813371 8908 mov [eax],ecx
ds:0023:00000107=???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from f78134b2 to f7813371

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub+0xc371
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0 usbhub+0xc4b2
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub+0xc727
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c usbhub+0x497b
f7b36b18 804e37f7 8293c330 82962cc0 82962d78 usbhub+0x21d8
f7b36b3c 80507adf 82962d78 82962cc0 82962d94 nt!IofCallDriver+0x32
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0xa2
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730 Wdf01000+0x52316
f7b36b90 ed4da3ee 82962d9c f7b36bbc ed4cd8d9 Wdf01000+0x523b9
f7b36b9c ed4cd8d9 8293ca00 f7b36bb8 00000000 Wdf01000+0x523ee
f7b36bbc ed4b8df7 82962cc0 f7b36be4 ed4b8eb6 Wdf01000+0x458d9
f7b36bc8 ed4b8eb6 8294d980 82962cc0 8055ff68 Wdf01000+0x30df7
f7b36be4 804e37f7 8294d980 82962cc0 82962d9c Wdf01000+0x30eb6
f7b36c08 80507adf 82962d9c 82962cc0 82962dc0 nt!IofCallDriver+0x32
f7b36c28 80507cb0 8294d980 8294da50 ed4ee1e8 nt!PoCallDriver+0xa2
f7b36c44 ed4d8e3b 8294d980 00000002 00000001 nt!PoRequestPowerIrp+0x106
f7b36c7c ed4d92f1 00000001 00000001 f7b36d04 Wdf01000+0x50e3b
f7b36c8c ed4d8594 8293ca00 ed4eda10 8293ca00 Wdf01000+0x512f1
f7b36d04 ed4d9127 0000052d 8293cb74 8293ca00 Wdf01000+0x50594
f7b36d2c ed4d95c6 806ed0b8 8293cb68 f7b36d58 Wdf01000+0x51127
f7b36d3c ed4d9be1 8293ca00 82c27c38 8294d980 Wdf01000+0x515c6
f7b36d58 ed4d9c7d f7b36d74 80563790 8294d980 Wdf01000+0x51be1
f7b36d60 80563790 8294d980 8293cb68 8056147c Wdf01000+0x51c7d
f7b36d74 804e426b 82c27c38 00000000 82fc43c8 nt!SeDeleteAccessState+0x3f2
f7b36dac 8057be15 82c27c38 00000000 00000000 nt!ExQueueWorkItem+0x104
f7b36ddc 804fa4da 804e4196 00000001 00000000 nt!PsCreateSystemThread+0x70
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

FOLLOWUP_IP:
Wdf01000+52316
ed4da316 5f pop edi

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000+52316

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

STACK_COMMAND: .cxr 0xfffffffff7b366c8 ; kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Wdf01000 symbols will be in the DDK install directory (wdf\kmdf\10.…
IIRC), but should also be on the public sym store. I don’t think your
NT symbols are correct either based on the output. Are you using a
release OS on the laptop? Did you try to debug the symbol issue?

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Monday, March 20, 2006 5:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] MKDF USB driver crash stack trace

Hi,

Sometime ago I asked a question about a problem with my KMDF USB driver
crashing the system when the device was removed in standby. I was asked
to
post the stack trace of that crash.

I was not able to reproduce this problem on my test machine so i had to
reproduce it on my laptop.
When I did that the system did not break into the debugger on my other
machine (which I thought it was supposed to do) but I configured it to
save
a kernel dump so I was able to analyze that.

I configured windbg to use the microsoft public symbol store, but it
still
could not find the symbols for wdf01000.sys and usbhub.sys.
I am guessing with my limited crash dump knowledge that an exception is
generated in the usb hub driver which is never caught.
(see windbg analysis below)
Is there anything I can do to solve this problem or is this another case
of
‘tough luck’

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

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: f7813371, The address that the exception occurred at
Arg3: f7b369cc, Exception Record Address
Arg4: f7b366c8, Context Record Address

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: nt!_KPRCB
***
***
***
************************************************************************
*

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21be

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

FAULTING_IP:
usbhub+c371
f7813371 8908 mov [eax],ecx

EXCEPTION_RECORD: f7b369cc – (.exr fffffffff7b369cc)
ExceptionAddress: f7813371 (usbhub+0x0000c371)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000107
Attempt to write to address 00000107

CONTEXT: f7b366c8 – (.cxr fffffffff7b366c8)
eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8
edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0 nv up ei pl nz ac
pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010213
usbhub+0xc371:
f7813371 8908 mov [eax],ecx
ds:0023:00000107=???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from f78134b2 to f7813371

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be

wrong.
f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub+0xc371
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0 usbhub+0xc4b2
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub+0xc727
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c usbhub+0x497b
f7b36b18 804e37f7 8293c330 82962cc0 82962d78 usbhub+0x21d8
f7b36b3c 80507adf 82962d78 82962cc0 82962d94 nt!IofCallDriver+0x32
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0xa2
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730 Wdf01000+0x52316
f7b36b90 ed4da3ee 82962d9c f7b36bbc ed4cd8d9 Wdf01000+0x523b9
f7b36b9c ed4cd8d9 8293ca00 f7b36bb8 00000000 Wdf01000+0x523ee
f7b36bbc ed4b8df7 82962cc0 f7b36be4 ed4b8eb6 Wdf01000+0x458d9
f7b36bc8 ed4b8eb6 8294d980 82962cc0 8055ff68 Wdf01000+0x30df7
f7b36be4 804e37f7 8294d980 82962cc0 82962d9c Wdf01000+0x30eb6
f7b36c08 80507adf 82962d9c 82962cc0 82962dc0 nt!IofCallDriver+0x32
f7b36c28 80507cb0 8294d980 8294da50 ed4ee1e8 nt!PoCallDriver+0xa2
f7b36c44 ed4d8e3b 8294d980 00000002 00000001 nt!PoRequestPowerIrp+0x106
f7b36c7c ed4d92f1 00000001 00000001 f7b36d04 Wdf01000+0x50e3b
f7b36c8c ed4d8594 8293ca00 ed4eda10 8293ca00 Wdf01000+0x512f1
f7b36d04 ed4d9127 0000052d 8293cb74 8293ca00 Wdf01000+0x50594
f7b36d2c ed4d95c6 806ed0b8 8293cb68 f7b36d58 Wdf01000+0x51127
f7b36d3c ed4d9be1 8293ca00 82c27c38 8294d980 Wdf01000+0x515c6
f7b36d58 ed4d9c7d f7b36d74 80563790 8294d980 Wdf01000+0x51be1
f7b36d60 80563790 8294d980 8293cb68 8056147c Wdf01000+0x51c7d
f7b36d74 804e426b 82c27c38 00000000 82fc43c8
nt!SeDeleteAccessState+0x3f2
f7b36dac 8057be15 82c27c38 00000000 00000000 nt!ExQueueWorkItem+0x104
f7b36ddc 804fa4da 804e4196 00000001 00000000
nt!PsCreateSystemThread+0x70
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

FOLLOWUP_IP:
Wdf01000+52316
ed4da316 5f pop edi

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 7

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000+52316

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

STACK_COMMAND: .cxr 0xfffffffff7b366c8 ; kb

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Wdf01000 symbols will be in the DDK install directory (wdf\kmdf\10.…
IIRC), but should also be on the public sym store. I don’t think your
NT symbols are correct either based on the output. Are you using a
release OS on the laptop? Did you try to debug the symbol issue?

Hi Doron,

My laptop is running the release version of XP2 SP2 with latest updates.
The first time I opened the dump file I got complaints that the OS symbols
were not correct.
I then executed the command
.symfix+ D:\DebuggerSymbols

Which (if I understood the help correctly) will make windbg automatically
download the
required symbol files to D:\DebuggerSymbols so that they can be used

I then used the command !analyze -v to analyze the crash dump.
This took a few minutes the first time. I assume that it was downloading
symbols.
Then it generates the report i included with my first mail.

The following things appeared in my D:\DebuggerSymbols folder:
D:\DebuggerSymbols\ntoskrnl.exe\42250FF9214100\ntoskrnl.exe
D:\DebuggerSymbols\usbhub.sys\41107D68e100\usbhub.sys
D:\DebuggerSymbols\USBPORT.SYS\41107D6222e80\USBPORT.SYS
D:\DebuggerSymbols\pingme.txt

Originally there was nothing in that folder so the things that are there
were downloaded when I did the analyze.
Isn’t it strange btw that there are no PDB files there?

Just now I manually added the installed KMDF symbols to the symbol path.
Is it correct that I need the Free symbols?
I ask this because the driver was built with the checked build utility.
Come to think of it, that could not be the cause of my problem, could it?
The same driver works fine on another PC running XP release.

if I type .sympath i get the following output:
Symbol search path is:
D:\DebuggerSymbols;SRVD:\DebuggerSymbolshttp://msdl.microsoft.com/download/symbols;C:\WinDDK\WDF\KMDF10\symbols\x86fre\wdf\sys

if I do !analyze -v again I still get the same output though. It still
cannot do anything with the WDF symbols.
Is there something obvious I am missing?



Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

Try pointing it at both checked and free symbols. Also remember to do
“.reload” after you change the symbol path. Finally, turn on noisy
symbol loading (“!sym noisy”) so you can see from whence the symbols are
loaded (or not). You can also use the “lm” command to see the
information about what symbols are loaded.

Then try “!analyze -v” again.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Monday, March 20, 2006 11:16 AM
To: ntdev redirect
Subject: Re:[ntdev] MKDF USB driver crash stack trace

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Wdf01000 symbols will be in the DDK install directory (wdf\kmdf\10.…
IIRC), but should also be on the public sym store. I don’t think your
NT symbols are correct either based on the output. Are you using a
release OS on the laptop? Did you try to debug the symbol issue?

Hi Doron,

My laptop is running the release version of XP2 SP2 with latest updates.
The first time I opened the dump file I got complaints that the OS
symbols
were not correct.
I then executed the command
.symfix+ D:\DebuggerSymbols

Which (if I understood the help correctly) will make windbg
automatically
download the
required symbol files to D:\DebuggerSymbols so that they can be used

I then used the command !analyze -v to analyze the crash dump.
This took a few minutes the first time. I assume that it was downloading

symbols.
Then it generates the report i included with my first mail.

The following things appeared in my D:\DebuggerSymbols folder:
D:\DebuggerSymbols\ntoskrnl.exe\42250FF9214100\ntoskrnl.exe
D:\DebuggerSymbols\usbhub.sys\41107D68e100\usbhub.sys
D:\DebuggerSymbols\USBPORT.SYS\41107D6222e80\USBPORT.SYS
D:\DebuggerSymbols\pingme.txt

Originally there was nothing in that folder so the things that are there

were downloaded when I did the analyze.
Isn’t it strange btw that there are no PDB files there?

Just now I manually added the installed KMDF symbols to the symbol path.
Is it correct that I need the Free symbols?
I ask this because the driver was built with the checked build utility.
Come to think of it, that could not be the cause of my problem, could
it?
The same driver works fine on another PC running XP release.

if I type .sympath i get the following output:
Symbol search path is:
D:\DebuggerSymbols;SRVD:\DebuggerSymbolshttp://msdl.microsoft.com/down
load/symbols;C:\WinDDK\WDF\KMDF10\symbols\x86fre\wdf\sys

if I do !analyze -v again I still get the same output though. It still
cannot do anything with the WDF symbols.
Is there something obvious I am missing?



Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thanks!

I had not done .reload (me == windbg newbie). that did the trick. now there
are no more unknown symbols.
my crash analysis now is this:

does this make more sense?

*******************************************************************************
*
*
* 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: f7813371, The address that the exception occurred at
Arg3: f7b369cc, Exception Record Address
Arg4: f7b366c8, 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
f7813371 8908 mov [eax],ecx

EXCEPTION_RECORD: f7b369cc – (.exr fffffffff7b369cc)
ExceptionAddress: f7813371 (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: f7b366c8 – (.cxr fffffffff7b366c8)
eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8
edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0 nv up ei pl nz ac pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010213
usbhub!USBH_SetPowerD0+0xd3:
f7813371 8908 mov [eax],ecx
ds:0023:00000107=???
Resetting default scope

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 f78134b2 to f7813371

STACK_TEXT:
f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub!USBH_SetPowerD0+0xd3
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0 usbhub!USBH_PdoSetPower+0x80
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub!USBH_PdoPower+0x201
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c usbhub!USBH_PdoDispatch+0x83
f7b36b18 804e37f7 8293c330 82962cc0 82962d78 usbhub!USBH_HubDispatch+0x48
f7b36b28 805081dc 82962d78 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36b3c 80507adf 82962d78 82962cc0 82962d94 nt!PopPresentIrp+0x57
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0x195
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730
Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f7b36b90 ed4da3ee 82962d9c f7b36bbc ed4cd8d9
Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x92
f7b36b9c ed4cd8d9 8293ca00 f7b36bb8 00000000
Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f7b36bbc ed4b8df7 82962cc0 f7b36be4 ed4b8eb6
Wdf01000!FxPkgPnp::Dispatch+0x107
f7b36bc8 ed4b8eb6 8294d980 82962cc0 8055ff68
Wdf01000!FxDevice::Dispatch+0x7f
f7b36be4 804e37f7 8294d980 82962cc0 82962d9c
Wdf01000!FxDevice::DispatchWithLock+0x60
f7b36bf4 805081dc 82962d9c 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36c08 80507adf 82962d9c 82962cc0 82962dc0 nt!PopPresentIrp+0x57
f7b36c28 80507cb0 8294d980 8294da50 ed4ee1e8 nt!PoCallDriver+0x195
f7b36c44 ed4d8e3b 8294d980 00000002 00000001 nt!PoRequestPowerIrp+0x129
f7b36c7c ed4d92f1 00000001 00000001 f7b36d04
Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x41
f7b36c8c ed4d8594 8293ca00 ed4eda10 8293ca00
Wdf01000!FxPkgPnp::PowerPolS0NoWakePowerUp+0x11
f7b36d04 ed4d9127 0000052d 8293cb74 8293ca00
Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x148
f7b36d2c ed4d95c6 806ed0b8 8293cb68 f7b36d58
Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x1bf
f7b36d3c ed4d9be1 8293ca00 82c27c38 8294d980
Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x23
f7b36d58 ed4d9c7d f7b36d74 80563790 8294d980
Wdf01000!FxEventQueue::EventQueueWorker+0x32
f7b36d60 80563790 8294d980 8293cb68 8056147c
Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f7b36d74 804e426b 82c27c38 00000000 82fc43c8 nt!IopProcessWorkItem+0x13
f7b36dac 8057be15 82c27c38 00000000 00000000 nt!ExpWorkerThread+0x100
f7b36ddc 804fa4da 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

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

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21be

STACK_COMMAND: .cxr 0xfffffffff7b366c8 ; kb

FAILURE_BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Followup: MachineOwner

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

This is indeed a bug in the usbhub driver. I asked the usb core team if
there is an updated version of the driver for you to use.

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Monday, March 20, 2006 8:41 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MKDF USB driver crash stack trace

Thanks!

I had not done .reload (me == windbg newbie). that did the trick. now
there
are no more unknown symbols.
my crash analysis now is this:

does this make more sense?

************************************************************************
*******
*
*
* 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: f7813371, The address that the exception occurred at
Arg3: f7b369cc, Exception Record Address
Arg4: f7b366c8, 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
f7813371 8908 mov [eax],ecx

EXCEPTION_RECORD: f7b369cc – (.exr fffffffff7b369cc)
ExceptionAddress: f7813371 (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: f7b366c8 – (.cxr fffffffff7b366c8)
eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8
edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0 nv up ei pl nz ac
pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010213
usbhub!USBH_SetPowerD0+0xd3:
f7813371 8908 mov [eax],ecx
ds:0023:00000107=???
Resetting default scope

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 f78134b2 to f7813371

STACK_TEXT:
f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub!USBH_SetPowerD0+0xd3
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0
usbhub!USBH_PdoSetPower+0x80
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub!USBH_PdoPower+0x201
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c
usbhub!USBH_PdoDispatch+0x83
f7b36b18 804e37f7 8293c330 82962cc0 82962d78
usbhub!USBH_HubDispatch+0x48
f7b36b28 805081dc 82962d78 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36b3c 80507adf 82962d78 82962cc0 82962d94 nt!PopPresentIrp+0x57
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0x195
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730
Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f7b36b90 ed4da3ee 82962d9c f7b36bbc ed4cd8d9
Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x92
f7b36b9c ed4cd8d9 8293ca00 f7b36bb8 00000000
Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f7b36bbc ed4b8df7 82962cc0 f7b36be4 ed4b8eb6
Wdf01000!FxPkgPnp::Dispatch+0x107
f7b36bc8 ed4b8eb6 8294d980 82962cc0 8055ff68
Wdf01000!FxDevice::Dispatch+0x7f
f7b36be4 804e37f7 8294d980 82962cc0 82962d9c
Wdf01000!FxDevice::DispatchWithLock+0x60
f7b36bf4 805081dc 82962d9c 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36c08 80507adf 82962d9c 82962cc0 82962dc0 nt!PopPresentIrp+0x57
f7b36c28 80507cb0 8294d980 8294da50 ed4ee1e8 nt!PoCallDriver+0x195
f7b36c44 ed4d8e3b 8294d980 00000002 00000001 nt!PoRequestPowerIrp+0x129
f7b36c7c ed4d92f1 00000001 00000001 f7b36d04
Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x41
f7b36c8c ed4d8594 8293ca00 ed4eda10 8293ca00
Wdf01000!FxPkgPnp::PowerPolS0NoWakePowerUp+0x11
f7b36d04 ed4d9127 0000052d 8293cb74 8293ca00
Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x148
f7b36d2c ed4d95c6 806ed0b8 8293cb68 f7b36d58
Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x1bf
f7b36d3c ed4d9be1 8293ca00 82c27c38 8294d980
Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x23
f7b36d58 ed4d9c7d f7b36d74 80563790 8294d980
Wdf01000!FxEventQueue::EventQueueWorker+0x32
f7b36d60 80563790 8294d980 8293cb68 8056147c
Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f7b36d74 804e426b 82c27c38 00000000 82fc43c8 nt!IopProcessWorkItem+0x13
f7b36dac 8057be15 82c27c38 00000000 00000000 nt!ExpWorkerThread+0x100
f7b36ddc 804fa4da 804e4196 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

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

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21be

STACK_COMMAND: .cxr 0xfffffffff7b366c8 ; kb

FAILURE_BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Followup: MachineOwner

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


For those who are curious on how I debugged this issue, I blogged about
it today.

http://blogs.msdn.com/doronh/archive/2006/03/20/556053.aspx

d

-----Original Message-----
From: Doron Holan
Sent: Monday, March 20, 2006 11:59 AM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] MKDF USB driver crash stack trace

This is indeed a bug in the usbhub driver. I asked the usb core team if
there is an updated version of the driver for you to use.

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bruno van Dooren
Sent: Monday, March 20, 2006 8:41 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MKDF USB driver crash stack trace

Thanks!

I had not done .reload (me == windbg newbie). that did the trick. now
there
are no more unknown symbols.
my crash analysis now is this:

does this make more sense?

************************************************************************
*******
*
*
* 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: f7813371, The address that the exception occurred at
Arg3: f7b369cc, Exception Record Address
Arg4: f7b366c8, 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
f7813371 8908 mov [eax],ecx

EXCEPTION_RECORD: f7b369cc – (.exr fffffffff7b369cc)
ExceptionAddress: f7813371 (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: f7b366c8 – (.cxr fffffffff7b366c8)
eax=00000107 ebx=82d60104 ecx=82e69f5c edx=82e69f5c esi=82e69ce8
edi=8293c3e8
eip=f7813371 esp=f7b36a94 ebp=f7b36aac iopl=0 nv up ei pl nz ac
pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010213
usbhub!USBH_SetPowerD0+0xd3:
f7813371 8908 mov [eax],ecx
ds:0023:00000107=???
Resetting default scope

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 f78134b2 to f7813371

STACK_TEXT:
f7b36aac f78134b2 82962cc0 00000100 8293c3e8 usbhub!USBH_SetPowerD0+0xd3
f7b36ac8 f7813727 8293c3e8 82962cc0 82962cc0
usbhub!USBH_PdoSetPower+0x80
f7b36ae8 f780b97b 82962d78 82962cc0 00000002 usbhub!USBH_PdoPower+0x201
f7b36b08 f78091d8 8293c3e8 82962cc0 f7b36b3c
usbhub!USBH_PdoDispatch+0x83
f7b36b18 804e37f7 8293c330 82962cc0 82962d78
usbhub!USBH_HubDispatch+0x48
f7b36b28 805081dc 82962d78 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36b3c 80507adf 82962d78 82962cc0 82962d94 nt!PopPresentIrp+0x57
f7b36b5c ed4da316 8293c330 8293c518 82962d9c nt!PoCallDriver+0x195
f7b36b7c ed4da3b9 f7b36bb8 8293ca00 ed4ec730
Wdf01000!FxPkgFdo::RaiseDevicePower+0x50
f7b36b90 ed4da3ee 82962d9c f7b36bbc ed4cd8d9
Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x92
f7b36b9c ed4cd8d9 8293ca00 f7b36bb8 00000000
Wdf01000!FxPkgFdo::_DispatchSetPower+0x23
f7b36bbc ed4b8df7 82962cc0 f7b36be4 ed4b8eb6
Wdf01000!FxPkgPnp::Dispatch+0x107
f7b36bc8 ed4b8eb6 8294d980 82962cc0 8055ff68
Wdf01000!FxDevice::Dispatch+0x7f
f7b36be4 804e37f7 8294d980 82962cc0 82962d9c
Wdf01000!FxDevice::DispatchWithLock+0x60
f7b36bf4 805081dc 82962d9c 82962cc0 00000000 nt!IopfCallDriver+0x31
f7b36c08 80507adf 82962d9c 82962cc0 82962dc0 nt!PopPresentIrp+0x57
f7b36c28 80507cb0 8294d980 8294da50 ed4ee1e8 nt!PoCallDriver+0x195
f7b36c44 ed4d8e3b 8294d980 00000002 00000001 nt!PoRequestPowerIrp+0x129
f7b36c7c ed4d92f1 00000001 00000001 f7b36d04
Wdf01000!FxPkgPnp::PowerPolicySendDevicePowerRequest+0x41
f7b36c8c ed4d8594 8293ca00 ed4eda10 8293ca00
Wdf01000!FxPkgPnp::PowerPolS0NoWakePowerUp+0x11
f7b36d04 ed4d9127 0000052d 8293cb74 8293ca00
Wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x148
f7b36d2c ed4d95c6 806ed0b8 8293cb68 f7b36d58
Wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x1bf
f7b36d3c ed4d9be1 8293ca00 82c27c38 8294d980
Wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x23
f7b36d58 ed4d9c7d f7b36d74 80563790 8294d980
Wdf01000!FxEventQueue::EventQueueWorker+0x32
f7b36d60 80563790 8294d980 8293cb68 8056147c
Wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
f7b36d74 804e426b 82c27c38 00000000 82fc43c8 nt!IopProcessWorkItem+0x13
f7b36dac 8057be15 82c27c38 00000000 00000000 nt!ExpWorkerThread+0x100
f7b36ddc 804fa4da 804e4196 00000001 00000000
nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

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

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 8

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Wdf01000!FxPkgFdo::RaiseDevicePower+50

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 438e21be

STACK_COMMAND: .cxr 0xfffffffff7b366c8 ; kb

FAILURE_BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

BUCKET_ID: 0x7E_Wdf01000!FxPkgFdo::RaiseDevicePower+50

Followup: MachineOwner

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer