can't break into target system

Mircea_Giurgeu · June 2, 2009, 10:32am

Hi,

I’ve read a few of the posts here on the same topic but didn’t find much help. I’m new to this.

I have a sick XP-sp3 system which boots into a BSOD. I have a feeling it’s a driver issue and I want to disable it. I changed boot.ini on the target to add /debug /debugport=1394 /channel=10 and put the corresponding channel in Windbg (Ctrl-K) but I can’t seem to be able to break in. All I’m getting is “The HOST cannot communicate with the TARGET!”

Both systems are laptops, the host runs Vista x32 with the latest Windbg.

I did not disable the 1394 drivers on the target as I cannot boot that system in the GUI.

Any help in a timely manner is highly appreciated. tx,

Mircea_Giurgeu · June 2, 2009, 10:47am

I just noticed that the cable was not properly plugged into the target system (sorry for failing to notice this before my initial post). Now, when I try to break in, Windbg dies!!! It just terminates with no message… Strange

Gary_Little-3 · June 2, 2009, 11:06am

What version of WinDbg?

The personal opinion of
Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 9:46 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

I just noticed that the cable was not properly plugged into the target
system (sorry for failing to notice this before my initial post). Now, when
I try to break in, Windbg dies!!! It just terminates with no message…
Strange

WINDBG 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

Mircea_Giurgeu · June 2, 2009, 11:30am

WinDbg:6.11.0001.404 X86

Ken_Johnson · June 2, 2009, 11:37am

Can you attach a debugger to the instance that you’re KD’ing with ahead of time, set a bp on ntdll!NtTerminateProcess, and grab a call stack when it “vainishes”?

S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 08:29
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

WinDbg:6.11.0001.404 X86

—
WINDBG 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

Scott_Noone_OSR · June 2, 2009, 11:52am

If you connect WinDBG again does it work the second time? I have cases where
WinDBG exits if it's attached while the system is booting. Once booted, I
can attach it again and all is happy.

-scott

Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.

wrote in message news:xxxxx@windbg...
> WinDbg:6.11.0001.404 X86
>

Mircea_Giurgeu · June 2, 2009, 12:35pm

Thanks a lot for your help.

I got in by breaking in early as opposed to waiting until the target crashed (sorry if this is a no-no, I’m new to debugging). However my symbols can’t be found. Here is the message in WinDbg:

Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2 12:15:54.725 2009 (GMT-4)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Z:\Documents\Symbols\XPsp3
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe -
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp_sp3_gdr.090206-1234
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
System Uptime: not available
Break instruction exception - code 80000003 (first chance)

I’ve downloaded “Windows XP with Service Pack 3 x86 retail symbols, all languages (File size: 209 MB)” from http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d, unpack in Z:\Documents\Symbols\XPsp3 (where I see a lot of short name directories (acm, ax, cnv, com, etc)) and entered the symbol path in the WinDbg as Z:\Documents\Symbols\XPsp3

What’s wrong? I know this is a newbee question, I appologise in advance.

Gary_Little-3 · June 2, 2009, 12:56pm

You can use Ctl+ALT+K to set a break on first load. There is a couple more
selections as well.

The personal opinion of
Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 11:35 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

Thanks a lot for your help.

I got in by breaking in early as opposed to waiting until the target crashed
(sorry if this is a no-no, I’m new to debugging). However my symbols can’t
be found. Here is the message in WinDbg:

Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2
12:15:54.725 2009 (GMT-4)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Z:\Documents\Symbols\XPsp3
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrpamp.exe -
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp_sp3_gdr.090206-1234
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
System Uptime: not available
Break instruction exception - code 80000003 (first chance)

I’ve downloaded “Windows XP with Service Pack 3 x86 retail symbols, all
languages (File size: 209 MB)” from
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d, unpack in
Z:\Documents\Symbols\XPsp3 (where I see a lot of short name directories
(acm, ax, cnv, com, etc)) and entered the symbol path in the WinDbg as
Z:\Documents\Symbols\XPsp3

What’s wrong? I know this is a newbee question, I appologise in advance.

WINDBG 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

Ken_Johnson · June 2, 2009, 1:00pm

I recommend using the symbol server and not the symbol packages. The symbol server can automagically go and grab the correct symbols bits for Microsoft binaries if you have a live Internet connection at the site where you are running the debugger.

To use, use the command “.symfix DownstreamStore”, e.g. “.symfix Z:\Symbols”, then issue a “.reload”.

S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 09:36
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

Thanks a lot for your help.

I got in by breaking in early as opposed to waiting until the target crashed (sorry if this is a no-no, I’m new to debugging). However my symbols can’t be found. Here is the message in WinDbg:

Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2 12:15:54.725 2009 (GMT-4)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Z:\Documents\Symbols\XPsp3
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrpamp.exe -
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp_sp3_gdr.090206-1234
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
System Uptime: not available
Break instruction exception - code 80000003 (first chance)

I’ve downloaded “Windows XP with Service Pack 3 x86 retail symbols, all languages (File size: 209 MB)” from http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d, unpack in Z:\Documents\Symbols\XPsp3 (where I see a lot of short name directories (acm, ax, cnv, com, etc)) and entered the symbol path in the WinDbg as Z:\Documents\Symbols\XPsp3

What’s wrong? I know this is a newbee question, I appologise in advance.

—
WINDBG 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

Mircea_Giurgeu · June 2, 2009, 2:29pm

I managed to get the sick system back up and running although I would like to have the knowledge to find out what happened, but I guess that would be too much to ask of this forum.

Thank you very much for all the help.

David_J_Craig · June 2, 2009, 2:46pm

The only time you have to use the symbol packages is for Win7 and Server
2008 R2 Beta and RC1 releases. You might have to use them for w2k, but I
haven’t looked lately to see if the MS symbol server still supports w2k. I
guess if someone is still doing NT4, that might also be a problem.

Having very good Internet connections at work and home (at least for the
U.S., but far inferior to Japan and several other countries), this only
takes a few minutes the first time you need to debug a new OS. The biggest
problem on the first time is that you just have to wait until your little
network icon finally stops before you continue after the Ctrl+Alt+K. I
usually use a “.reload /n” on the first break but add “/f” for the first
time with an OS. Then you can do “lm kvm ” for those
pieces you need such as the kernel, hal, win32k, KMDF, PCI, etc. as your
situation requires.

“Skywing” wrote in message
news:xxxxx@windbg…
I recommend using the symbol server and not the symbol packages. The symbol
server can automagically go and grab the correct symbols bits for Microsoft
binaries if you have a live Internet connection at the site where you are
running the debugger.

To use, use the command “.symfix DownstreamStore”, e.g. “.symfix
Z:\Symbols”, then issue a “.reload”.

- S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 09:36
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

Thanks a lot for your help.

I got in by breaking in early as opposed to waiting until the target crashed
(sorry if this is a no-no, I’m new to debugging). However my symbols can’t
be found. Here is the message in WinDbg:

Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2
12:15:54.725 2009 (GMT-4)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Z:\Documents\Symbols\XPsp3
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntkrpamp.exe -
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible
Built by: 2600.xpsp_sp3_gdr.090206-1234
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
System Uptime: not available
Break instruction exception - code 80000003 (first chance)

I’ve downloaded “Windows XP with Service Pack 3 x86 retail symbols, all
languages (File size: 209 MB)” from
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d, unpack in
Z:\Documents\Symbols\XPsp3 (where I see a lot of short name directories
(acm, ax, cnv, com, etc)) and entered the symbol path in the WinDbg as
Z:\Documents\Symbols\XPsp3

What’s wrong? I know this is a newbee question, I appologise in advance.

—
WINDBG 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

Tim_Roberts · June 2, 2009, 2:49pm

xxxxx@gmail.com wrote:

I managed to get the sick system back up and running although I would like to have the knowledge to find out what happened, but I guess that would be too much to ask of this forum.

There’s no need to get snotty about it. We don’t know what happened.
We weren’t there, and your symptoms were not familiar. What you did has
worked for other people. If you want guaranteed response, open up a
paid support incident with Microsoft Product Support Services.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Mircea_Giurgeu · June 2, 2009, 3:09pm

Tim,

What I meant to say is that I do not dare to ask here for help in trying to find out what caused the BSOD. You folks helped me with the problem I posted and I’m very grateful for that.

My deepest appologies for the misunderstanding. I detest snotty people and I will use the excuse that English is my second language (Romanian is the first).

I hope that none of you were offended. Please let me know if there is anything else I can do to pay back for my unintentional mistake.

Thanks again,

Gary_Little-3 · June 2, 2009, 3:56pm

Hmm, and just why would you NOT ask here for help in finding out what caused
a BSOD, since that is one reason why this forum exists? Yeah, if we find out
you’re hooking, you just might get your hands slapped, but over all, all of
us have had our rabies shots … ok … maybe Peter was gone that day …

The personal opinion of
Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, June 02, 2009 2:09 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] can’t break into target system

Tim,

What I meant to say is that I do not dare to ask here for help in trying to
find out what caused the BSOD. You folks helped me with the problem I posted
and I’m very grateful for that.

My deepest appologies for the misunderstanding. I detest snotty people and I
will use the excuse that English is my second language (Romanian is the
first).

I hope that none of you were offended. Please let me know if there is
anything else I can do to pay back for my unintentional mistake.

Thanks again,

WINDBG 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

Mircea_Giurgeu · June 2, 2009, 4:26pm

The reason I did not want to ask about BSOD is that I did not want to be accused of taking advantage of your kindness. I asked a question, you helped, that should be it. But after reading Gary's reply I'm going to give it a shot.

I don't know much (if anything) about debugging but I'm fascinated about it and I'm seriously considering taking the Kernel Debugging seminar in September.

Anyway, back to BSOD. With your help in getting the debugger going I determined that it was caused by usbport.sys I booted into ERD Commander renamed the file and the system came up normally. Device Manager now shows all all USB drivers with an exclamation. I downloaded the chipset drivers from Intel and installed them. All is well. However, the new usbport.sys that got put back is identical to the one I renamed. So it was not the root cause of the problem. I have no clue how to proceed from here. Bellow is the WinDbg output for the crash. All I was able to understand from it is that usbport.sys is the culprit. I have a feeling that attending the seminar in San Jose will help make more of it.

Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2 13:04:41.508 2009 (GMT-4)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................
Loading User Symbols

Loading unloaded module list
.............
1: 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: ba4ff8f3, The address that the exception occurred at
Arg3: ba4ff7f4, Exception Record Address
Arg4: ba4ff4f0, Context Record Address

Debugging Details:

*** No owner thread found for resource 8055b4e0
*** No owner thread found for resource 8055b4e0
*** No owner thread found for resource 8055b4e0
*** No owner thread found for resource 8055b4e0

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

FAULTING_IP:
+5bc7952f01cdddf8
ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]

EXCEPTION_RECORD: ba4ff7f4 -- (.exr 0xffffffffba4ff7f4)
ExceptionAddress: ba4ff8f3
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 0000004f
Attempt to read from address 0000004f

CONTEXT: ba4ff4f0 -- (.cxr 0xffffffffba4ff4f0)
eax=00000001 ebx=89e0adf8 ecx=00000000 edx=b97cf649 esi=8a37f0e0 edi=8a37f300
eip=ba4ff8f3 esp=ba4ff8bc ebp=80546acc iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh] ds:0023:0000004f=??
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.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 0000004f

READ_ADDRESS: 0000004f

FOLLOWUP_IP:
USBPORT!USBPORT_InitializeDevice+131
b97cf649 3bc3 cmp eax,ebx

FAILED_INSTRUCTION_ADDRESS:
+5bc7952f01cdddf8
ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LOCK_ADDRESS: 8055b560 -- (!locks 8055b560)

Resource @ nt!IopDeviceTreeLock (0x8055b560) Shared 1 owning threads
Threads: 8a3ee8b8-01<*>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x8055b560
Thread Count : 1
Thread address: 0x8a3ee8b8
Thread wait : 0x46c

LAST_CONTROL_TRANSFER: from 804f8e09 to 8052b5ec

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
ba4ff8e8 b97cf649 8a37f028 02624e70 89e06b10 0xba4ff8f3
ba4ff91c b97d566f 00000000 8a37f028 ba4ff940 USBPORT!USBPORT_InitializeDevice+0x131
ba4ff92c ba25a405 89dfa030 8a26fb88 89e06b00 USBPORT!USBPORTBUSIF_InitializeUsbDevice+0x1b
ba4ff940 ba2630d6 89e08b18 8a26fb88 89dfa030 usbhub!USBD_InitializeDeviceEx+0x27
ba4ff98c ba25974c 00000000 00000001 89e00103 usbhub!USBH_CreateDevice+0x1e0
ba4ff9d4 ba259f9f 89e08b18 8a294b90 8a294b90 usbhub!USBH_FdoQueryBusRelations+0x1ce
ba4ff9f4 ba25a039 89e08b18 8a294b90 00000007 usbhub!USBH_FdoPnP+0x143
ba4ffa1c ba25a1ee 89e08b18 8a294b90 ba4ffa68 usbhub!USBH_FdoDispatch+0x63
ba4ffa2c 804ef19f 89e08a60 8a294b90 ba4ffaac usbhub!USBH_HubDispatch+0x5e
ba4ffa3c 80592b63 00000000 89e08dd0 89e08eb0 nt!IopfCallDriver+0x31
ba4ffa68 804f6de7 89e08a60 ba4ffa88 89e08eb0 nt!IopSynchronousCall+0xb7
ba4ffab0 8058ee79 00000000 89dfa030 00000001 nt!IopQueryDeviceRelations+0x45
ba4ffac8 805922db 89e08dd0 00000001 89ec5138 nt!PipEnumerateDevice+0x23
ba4ffd20 8059271a 89e08dd0 00000001 00000000 nt!PipProcessDevNodeTree+0x21b
ba4ffd54 804f6981 00000003 8055b5c0 8056485c nt!PiProcessReenumeration+0x60
ba4ffd7c 8053877d 00000000 00000000 8a3ee8b8 nt!PipDeviceActionWorker+0x14b
ba4ffdac 805cff70 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
ba4ffddc 805460ee 8053868e 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: USBPORT!USBPORT_InitializeDevice+131

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: USBPORT

IMAGE_NAME: USBPORT.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce

STACK_COMMAND: .cxr 0xffffffffba4ff4f0 ; kb

FAILURE_BUCKET_ID: 0x7E_BAD_IP_USBPORT!USBPORT_InitializeDevice+131

BUCKET_ID: 0x7E_BAD_IP_USBPORT!USBPORT_InitializeDevice+131

Followup: MachineOwner

Tim_Roberts · June 2, 2009, 4:35pm

xxxxx@gmail.com wrote:

What I meant to say is that I do not dare to ask here for help in trying to find out what caused the BSOD. You folks helped me with the problem I posted and I’m very grateful for that.

My deepest appologies for the misunderstanding. I detest snotty people and I will use the excuse that English is my second language (Romanian is the first).

I am sorry that I misunderstood you – please excuse me for being curt.

And, actually, this is not such a bad place to ask about your BSOD.
Although most of the posts have to do with using and configuring windbg,
there’s a lot of expertise here in analyzing debug dumps. It would
certainly give you a good start.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Scott_Noone_OSR · June 2, 2009, 5:26pm

It’s a bogus pointer deref:

CONTEXT: ba4ff4f0 – (.cxr 0xffffffffba4ff4f0)
eax=00000001 ebx=89e0adf8 ecx=00000000 edx=b97cf649 esi=8a37f0e0
edi=8a37f300
eip=ba4ff8f3 esp=ba4ff8bc ebp=80546acc iopl=0 nv up ei pl nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]
ds:0023:0000004f=??
Resetting default scope

Note that the bad deref was for EAX+4E, which evaluated to 0x4F, which isn’t
a valid address.

As you’ve noticed, disabling USBPORT is going to disable all of your USB
devices. This is an device enumeration, so you probably have some device
driver corrupting things or otherwise not behaving properly during
configuration.

What’s weird is that WinDBG isn’t showing a module for the faulting
instruction. If you do a:

u ba4ff8f3

What’s the output? You might also want to try doing a .reload, sometimes
your module list is out of whack and that will fix it.

Also, I think a:

!devnode 89e08dd0

Will probably also help you find out what device this is, but that’s not
guaranteed (a device node is the first param to nt!PipEnumerateDevice, but
the compiler might have reused it)

And the Debug Lab does a pretty good job of going over this kind of dump. We
even have “Stump the Chump” day on Friday afternoon where you can bring your
own dumps in for analysis

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…
> The reason I did not want to ask about BSOD is that I did not want to be
> accused of taking advantage of your kindness. I asked a question, you
> helped, that should be it. But after reading Gary’s reply I’m going to
> give it a shot.
>
> I don’t know much (if anything) about debugging but I’m fascinated about
> it and I’m seriously considering taking the Kernel Debugging seminar in
> September.
>
> Anyway, back to BSOD. With your help in getting the debugger going I
> determined that it was caused by usbport.sys I booted into ERD Commander
> renamed the file and the system came up normally. Device Manager now shows
> all all USB drivers with an exclamation. I downloaded the chipset drivers
> from Intel and installed them. All is well. However, the new usbport.sys
> that got put back is identical to the one I renamed. So it was not the
> root cause of the problem. I have no clue how to proceed from here. Bellow
> is the WinDbg output for the crash. All I was able to understand from it
> is that usbport.sys is the culprit. I have a feeling that attending the
> seminar in San Jose will help make more of it.
>
> Connected to Windows XP 2600 x86 compatible target at (Tue Jun 2
> 13:04:41.508 2009 (GMT-4)), ptr64 FALSE
> Loading Kernel Symbols
> …
> …
> Loading User Symbols
>
> Loading unloaded module list
> …
> 1: 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: ba4ff8f3, The address that the exception occurred at
> Arg3: ba4ff7f4, Exception Record Address
> Arg4: ba4ff4f0, Context Record Address
>
> Debugging Details:
> ------------------
>
> No owner thread found for resource 8055b4e0
> No owner thread found for resource 8055b4e0
> No owner thread found for resource 8055b4e0
> No owner thread found for resource 8055b4e0
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> +5bc7952f01cdddf8
> ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]
>
> EXCEPTION_RECORD: ba4ff7f4 – (.exr 0xffffffffba4ff7f4)
> ExceptionAddress: ba4ff8f3
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000000
> Parameter[1]: 0000004f
> Attempt to read from address 0000004f
>
> CONTEXT: ba4ff4f0 – (.cxr 0xffffffffba4ff4f0)
> eax=00000001 ebx=89e0adf8 ecx=00000000 edx=b97cf649 esi=8a37f0e0
> edi=8a37f300
> eip=ba4ff8f3 esp=ba4ff8bc ebp=80546acc iopl=0 nv up ei pl nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010206
> ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]
> ds:0023:0000004f=??
> 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.
>
> EXCEPTION_PARAMETER1: 00000000
>
> EXCEPTION_PARAMETER2: 0000004f
>
> READ_ADDRESS: 0000004f
>
> FOLLOWUP_IP:
> USBPORT!USBPORT_InitializeDevice+131
> b97cf649 3bc3 cmp eax,ebx
>
> FAILED_INSTRUCTION_ADDRESS:
> +5bc7952f01cdddf8
> ba4ff8f3 8a704e mov dh,byte ptr [eax+4Eh]
>
> BUGCHECK_STR: 0x7E
>
> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>
> LOCK_ADDRESS: 8055b560 – (!locks 8055b560)
>
> Resource @ nt!IopDeviceTreeLock (0x8055b560) Shared 1 owning threads
> Threads: 8a3ee8b8-01<>
> 1 total locks, 1 locks currently held
>
> PNP_TRIAGE:
> Lock address : 0x8055b560
> Thread Count : 1
> Thread address: 0x8a3ee8b8
> Thread wait : 0x46c
>
> LAST_CONTROL_TRANSFER: from 804f8e09 to 8052b5ec
>
> STACK_TEXT:
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> ba4ff8e8 b97cf649 8a37f028 02624e70 89e06b10 0xba4ff8f3
> ba4ff91c b97d566f 00000000 8a37f028 ba4ff940
> USBPORT!USBPORT_InitializeDevice+0x131
> ba4ff92c ba25a405 89dfa030 8a26fb88 89e06b00
> USBPORT!USBPORTBUSIF_InitializeUsbDevice+0x1b
> ba4ff940 ba2630d6 89e08b18 8a26fb88 89dfa030
> usbhub!USBD_InitializeDeviceEx+0x27
> ba4ff98c ba25974c 00000000 00000001 89e00103
> usbhub!USBH_CreateDevice+0x1e0
> ba4ff9d4 ba259f9f 89e08b18 8a294b90 8a294b90
> usbhub!USBH_FdoQueryBusRelations+0x1ce
> ba4ff9f4 ba25a039 89e08b18 8a294b90 00000007 usbhub!USBH_FdoPnP+0x143
> ba4ffa1c ba25a1ee 89e08b18 8a294b90 ba4ffa68 usbhub!USBH_FdoDispatch+0x63
> ba4ffa2c 804ef19f 89e08a60 8a294b90 ba4ffaac usbhub!USBH_HubDispatch+0x5e
> ba4ffa3c 80592b63 00000000 89e08dd0 89e08eb0 nt!IopfCallDriver+0x31
> ba4ffa68 804f6de7 89e08a60 ba4ffa88 89e08eb0 nt!IopSynchronousCall+0xb7
> ba4ffab0 8058ee79 00000000 89dfa030 00000001
> nt!IopQueryDeviceRelations+0x45
> ba4ffac8 805922db 89e08dd0 00000001 89ec5138 nt!PipEnumerateDevice+0x23
> ba4ffd20 8059271a 89e08dd0 00000001 00000000
> nt!PipProcessDevNodeTree+0x21b
> ba4ffd54 804f6981 00000003 8055b5c0 8056485c
> nt!PiProcessReenumeration+0x60
> ba4ffd7c 8053877d 00000000 00000000 8a3ee8b8
> nt!PipDeviceActionWorker+0x14b
> ba4ffdac 805cff70 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
> ba4ffddc 805460ee 8053868e 00000001 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> SYMBOL_STACK_INDEX: 1
>
> SYMBOL_NAME: USBPORT!USBPORT_InitializeDevice+131
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: USBPORT
>
> IMAGE_NAME: USBPORT.SYS
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 480254ce
>
> STACK_COMMAND: .cxr 0xffffffffba4ff4f0 ; kb
>
> FAILURE_BUCKET_ID: 0x7E_BAD_IP_USBPORT!USBPORT_InitializeDevice+131
>
> BUCKET_ID: 0x7E_BAD_IP_USBPORT!USBPORT_InitializeDevice+131
>
> Followup: MachineOwner
> ---------
>
>