WinDbg Crash

Vinod_Mamtani · April 15, 2010, 2:57pm

I’ve been doing kernel debugging over Firewire with my current setup for the last few months. Last evening, when I tried to connect my target system using the cached workspace settings, Windbg crashed! All my attempts to repair WinDbg and clear work-space failed to resolve this issue.

In order to debug this problem, I launched Windbg from Windbg (on the host system) to catch any unhandled exceptions. Here is the stack trace that I’m seeing before the target Windbg exits. Any hints as to what could be happening here? Note that my host system is running steady state from Microsoft. Both the host and target machines are running Vista SP1.

The Windbg version is 6.11.0001.404.x86
Thanks in advance.

Vinod Mamtani

0:001> kv
ChildEBP RetAddr Args to Child
0091f0e4 772c9134 7729a869 ffffffff 80004005 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
0091f0e8 7729a869 ffffffff 80004005 0091f10c ntdll!NtTerminateProcess+0xc (FPO: [2,0,0])
0091f0f8 76c33b68 80004005 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x7a (FPO: [1,0,0])
0091f10c 0097f110 80004005 0091f930 0097f16c kernel32!ExitProcess+0x12 (FPO: [1,0,0])
0091f118 0097f16c 00825b74 80004005 00650044 windbg!ExitDebugger+0x50 (FPO: [2,0,0])
0091f930 0095ae2e 00825b74 00933768 8000ffff windbg!ErrorExit+0x4c (FPO: [2,514,0])
0091f94c 00957a88 00000000 0091f96c 6c038bfa windbg!SessionActive+0x8e (FPO: [0,2,0])
0091f958 6c038bfa 009984f4 00000000 0091fa04 windbg!EventCallbacks::SessionStatus+0x28 (FPO: [2,1,0])
0091f96c 6c03514c 00825b70 6dee69e6 00000000 dbgeng!SessionStatusApcData::Dispatch+0x2a (FPO: [1,1,0])
0091f9a4 6c0353af 00825b70 0091fa04 00000000 dbgeng!ApcDispatch+0x4c (FPO: [SEH])
0091f9f4 6c038b91 0091fa04 00000000 6bf57c54 dbgeng!SendEvent+0xcf (FPO: [2,14,4])
0091fa14 6c048e50 00000000 00000007 0091fa48 dbgeng!NotifySessionStatus+0x21 (FPO: [1,4,0])
0091fa24 6c1b37e8 00000000 00000000 00000000 dbgeng!DiscardedTargets+0x40 (FPO: [1,1,0])
0091fa48 6c1b72a9 00000000 00000000 01bd06a8 dbgeng!TargetInfo::DebuggeeReset+0x128 (FPO: [1,4,0])
0091fa68 6c0bd8c9 00000000 6dee6b42 00000000 dbgeng!ConnLiveKernelTargetInfo::DebuggeeReset+0x99 (FPO: [1,5,0])
0091fb00 6c0bd6c5 6c289d98 6c289e90 00001f3e dbgeng!ConnLiveKernelTargetInfo::WaitStateChange+0x179 (FPO: [5,32,4])
0091fb24 6c0511cf 00000000 ffffffff 00000000 dbgeng!ConnLiveKernelTargetInfo::WaitForEvent+0x65 (FPO: [4,2,0])
0091fb48 6c05159e 00000000 ffffffff 00000001 dbgeng!WaitForAnyTarget+0x5f (FPO: [5,3,0])
0091fb94 6c051830 00825b70 00000000 ffffffff dbgeng!RawWaitForEvent+0x2ae (FPO: [3,12,0])
0091fbac 0095b22f 00825b78 00000000 ffffffff dbgeng!DebugClient::WaitForEvent+0xb0 (FPO: [3,1,0])

Vinod_Mamtani · April 15, 2010, 3:03pm

An update:
I can successfully connect to a different target system using the same host system and firewire cable. Wondering if it’s plausible for some target system setting (Firewire card issue) to crash Windbg on a host system.

OSR_Community_User · April 15, 2010, 3:22pm

It sounds like you already tried this, but just to be sure, did you delete the registry settings for your workspace (HKEY_CURRENT_USER\Software\Microsoft\WinDbg\Workspaces)?

I have no idea of what’s causing your problem specifically, but your definitely not the first to experience the problem of the mysteriously disappearing windbg host.

mm

Scott_Noone_OSR · April 15, 2010, 3:38pm

This looks to be the same problem that many of us were having with the
previous release (see my last couple of posts here:
http://www.osronline.com/ShowThread.cfm?link=143711).

I still see it in the new version myself, it seems to happen if you .reboot
the target machine. When the target boots up again WinDBG will just exit on
the host. I haven’t had a chance to put anything together yet to describe it
and resubmit the bug report.

I haven’t ever had this be sticky though, it always clears up when I start
WinDBG again.

-scott

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

wrote in message news:xxxxx@windbg…
> It sounds like you already tried this, but just to be sure, did you delete
> the registry settings for your workspace
> (HKEY_CURRENT_USER\Software\Microsoft\WinDbg\Workspaces)?
>
> I have no idea of what’s causing your problem specifically, but your
> definitely not the first to experience the problem of the mysteriously
> disappearing windbg host.
>
>
> mm
>

OSR_Community_User · April 15, 2010, 3:46pm

The ‘unsticky’ form of the problem was my experience as well, though I encountered it without using ‘.reboot.’

I too submitted something about this a couple of versions ago; no intention of going through the toruble of submitting it again.

OP: Is your target a VM of some sort?

mm

Scott_Noone_OSR · April 15, 2010, 5:02pm

VirtualKD has a nifty packet logging feature and I just happened to have a
VM target that caused the WinDBG crash…

In the failing case, the target seems to endlessly report the
DbgKdLoadSymbolsStateChange event for the kernel. In the working case, I see
(H = host, T = target):

.reboot
H->T - DbgKdRebootApi

T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
H->T - DbgKdGetVersionApi
T->H - DbgKdGetVersionApi response
H->T - DbgKdReadVirtualMemoryApi
T->H - DbgKdReadVirtualMemoryApi response
Etc…

In the case where the debugger exits, I see:
.reboot
H->T - DbgKdRebootApi

T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
H->T - DbgKdGetVersionApi
T->H - DbgKdGetVersionApi response
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
…

And that repeats until at some point the debugger exits. While the debugger
is exited, the messages keep flooding in over the debug connection. So, it’s
not happy about something but I’m again converging on the fact that there’s
probably no easy way to fix it as an end user.

-scott

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

wrote in message news:xxxxx@windbg…
> The ‘unsticky’ form of the problem was my experience as well, though I
> encountered it without using ‘.reboot.’
>
> I too submitted something about this a couple of versions ago; no
> intention of going through the toruble of submitting it again.
>
> OP: Is your target a VM of some sort?
>
> mm
>

Ken_Johnson · April 15, 2010, 7:21pm

Do you have a dump or !analyze -v output of dbgeng crashing?

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Thursday, April 15, 2010 2:02 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WinDbg Crash

VirtualKD has a nifty packet logging feature and I just happened to have a
VM target that caused the WinDBG crash…

In the failing case, the target seems to endlessly report the
DbgKdLoadSymbolsStateChange event for the kernel. In the working case, I see
(H = host, T = target):

.reboot
H->T - DbgKdRebootApi

T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
H->T - DbgKdGetVersionApi
T->H - DbgKdGetVersionApi response
H->T - DbgKdReadVirtualMemoryApi
T->H - DbgKdReadVirtualMemoryApi response
Etc…

In the case where the debugger exits, I see:
.reboot
H->T - DbgKdRebootApi

T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
H->T - DbgKdGetVersionApi
T->H - DbgKdGetVersionApi response
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
…

And that repeats until at some point the debugger exits. While the debugger
is exited, the messages keep flooding in over the debug connection. So, it’s
not happy about something but I’m again converging on the fact that there’s
probably no easy way to fix it as an end user.

-scott

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

wrote in message news:xxxxx@windbg…
> The ‘unsticky’ form of the problem was my experience as well, though I
> encountered it without using ‘.reboot.’
>
> I too submitted something about this a couple of versions ago; no
> intention of going through the toruble of submitting it again.
>
> OP: Is your target a VM of some sort?
>
> mm
>

—
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 · April 15, 2010, 7:45pm

It doesn’t crash, it’s an explicit call to ExitProcess. The OP’s call stack
matches what I’m seeing:

0:001> kv
ChildEBP RetAddr Args to Child
0091f0e4 772c9134 7729a869 ffffffff 80004005 ntdll!KiFastSystemCallRet (FPO:
[0,0,0])
0091f0e8 7729a869 ffffffff 80004005 0091f10c ntdll!NtTerminateProcess+0xc
(FPO: [2,0,0])
0091f0f8 76c33b68 80004005 77e8f3b0 ffffffff ntdll!RtlExitUserProcess+0x7a
(FPO: [1,0,0])
0091f10c 0097f110 80004005 0091f930 0097f16c kernel32!ExitProcess+0x12 (FPO:
[1,0,0])
0091f118 0097f16c 00825b74 80004005 00650044 windbg!ExitDebugger+0x50 (FPO:
[2,0,0])
0091f930 0095ae2e 00825b74 00933768 8000ffff windbg!ErrorExit+0x4c (FPO:
[2,514,0])
0091f94c 00957a88 00000000 0091f96c 6c038bfa windbg!SessionActive+0x8e (FPO:
[0,2,0])
0091f958 6c038bfa 009984f4 00000000 0091fa04
windbg!EventCallbacks::SessionStatus+0x28 (FPO: [2,1,0])
0091f96c 6c03514c 00825b70 6dee69e6 00000000
dbgeng!SessionStatusApcData::Dispatch+0x2a (FPO: [1,1,0])
0091f9a4 6c0353af 00825b70 0091fa04 00000000 dbgeng!ApcDispatch+0x4c (FPO:
[SEH])
0091f9f4 6c038b91 0091fa04 00000000 6bf57c54 dbgeng!SendEvent+0xcf (FPO:
[2,14,4])
0091fa14 6c048e50 00000000 00000007 0091fa48 dbgeng!NotifySessionStatus+0x21
(FPO: [1,4,0])
0091fa24 6c1b37e8 00000000 00000000 00000000 dbgeng!DiscardedTargets+0x40
(FPO: [1,1,0])
0091fa48 6c1b72a9 00000000 00000000 01bd06a8
dbgeng!TargetInfo::DebuggeeReset+0x128 (FPO: [1,4,0])
0091fa68 6c0bd8c9 00000000 6dee6b42 00000000
dbgeng!ConnLiveKernelTargetInfo::DebuggeeReset+0x99 (FPO: [1,5,0])
0091fb00 6c0bd6c5 6c289d98 6c289e90 00001f3e
dbgeng!ConnLiveKernelTargetInfo::WaitStateChange+0x179 (FPO: [5,32,4])
0091fb24 6c0511cf 00000000 ffffffff 00000000
dbgeng!ConnLiveKernelTargetInfo::WaitForEvent+0x65 (FPO: [4,2,0])
0091fb48 6c05159e 00000000 ffffffff 00000001 dbgeng!WaitForAnyTarget+0x5f
(FPO: [5,3,0])
0091fb94 6c051830 00825b70 00000000 ffffffff dbgeng!RawWaitForEvent+0x2ae
(FPO: [3,12,0])
0091fbac 0095b22f 00825b78 00000000 ffffffff
dbgeng!DebugClient::WaitForEvent+0xb0 (FPO: [3,1,0])

-scott

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

“Skywing” wrote in message
news:xxxxx@windbg…
> Do you have a dump or !analyze -v output of dbgeng crashing?
>
> - S
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
> Sent: Thursday, April 15, 2010 2:02 PM
> To: Kernel Debugging Interest List
> Subject: Re:[windbg] WinDbg Crash
>
> VirtualKD has a nifty packet logging feature and I just happened to have a
> VM target that caused the WinDBG crash…
>
> In the failing case, the target seems to endlessly report the
> DbgKdLoadSymbolsStateChange event for the kernel. In the working case, I
> see
> (H = host, T = target):
>
> .reboot
> H->T - DbgKdRebootApi
>
> T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
> H->T - DbgKdGetVersionApi
> T->H - DbgKdGetVersionApi response
> H->T - DbgKdReadVirtualMemoryApi
> T->H - DbgKdReadVirtualMemoryApi response
> Etc…
>
> In the case where the debugger exits, I see:
> .reboot
> H->T - DbgKdRebootApi
>
> T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
> H->T - DbgKdGetVersionApi
> T->H - DbgKdGetVersionApi response
> T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
> T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
> T->H - DbgKdLoadSymbolsStateChange (\WINDOWS\system32\ntkrnlpa.exe)
> …
>
> And that repeats until at some point the debugger exits. While the
> debugger
> is exited, the messages keep flooding in over the debug connection. So,
> it’s
> not happy about something but I’m again converging on the fact that
> there’s
> probably no easy way to fix it as an end user.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
>
>
> wrote in message news:xxxxx@windbg…
>> The ‘unsticky’ form of the problem was my experience as well, though I
>> encountered it without using ‘.reboot.’
>>
>> I too submitted something about this a couple of versions ago; no
>> intention of going through the toruble of submitting it again.
>>
>> OP: Is your target a VM of some sort?
>>
>> mm
>>
>
> —
> 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
>

Pavel_A1 · April 16, 2010, 11:42am

I’ve seen this behavior often with v. 6.11, but not 6.12.

– pa

“Scott Noone” wrote in message news:xxxxx@windbg…
> This looks to be the same problem that many of us were having with the
> previous release (see my last couple of posts here:
> http://www.osronline.com/ShowThread.cfm?link=143711).
>
> I still see it in the new version myself, it seems to happen if you
> .reboot the target machine. When the target boots up again WinDBG will
> just exit on the host. I haven’t had a chance to put anything together yet
> to describe it and resubmit the bug report.
>
> I haven’t ever had this be sticky though, it always clears up when I start
> WinDBG again.
>
> -scott
>
> –
> Scott Noone
> Consulting Associate
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
> wrote in message news:xxxxx@windbg…
>> It sounds like you already tried this, but just to be sure, did you
>> delete the registry settings for your workspace
>> (HKEY_CURRENT_USER\Software\Microsoft\WinDbg\Workspaces)?
>>
>> I have no idea of what’s causing your problem specifically, but your
>> definitely not the first to experience the problem of the mysteriously
>> disappearing windbg host.
>>
>>
>> mm
>>
>