!analyze -v behavior/bug?

I was single-stepping through code to get to trace the behavior leading
up to a bugcheck, and noticed a bug (?) with !analyze -v:
---------------snip-----------------------
kd> p
ati2draa!DrvBitBlt+1890:
bff12d1e 8b4850 mov ecx,[eax+0x50]
kd> p
ati2draa!DrvBitBlt+1893:
bff12d21 f781b807000000000080 test dword ptr [ecx+0x7b8],0x80000000
kd> p

*** Fatal System Error: 0x00000050
(0xF000EEF1,0x00000000,0xBFF12D21,0x00000000)

Driver at fault:
*** ati2draa.dll - Address BFF12D21 base at BFF10000, DateStamp 3b7d92ed

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80579b54 cc int 3
kd> !analyze -v
The debuggee is ready to run
kd> !analyze -v
The debuggee is ready to run
kd> p

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction+1:
80579b55 c20400 ret 0x4
kd> !analyze -v
The debuggee is ready to run

---------------snip-----------------------

Shouldn’t “!analyze -v” be able to dump out the bugcheck analysis at
this point? If I let the system go on to generate the full dump of
physical memory, the debugger will break in after the dump is complete
and then “!analyze -v” works as expected… I don’t need the analysis
(since I know exactly where and how the problem occurs), but I thought
I’d report this anyways…

Both machines are XP Pro…

sean

Try “analyzebugcheck -v”

-----Original Message-----
From: Sean Bullington [mailto:xxxxx@stg.com]
Sent: Wednesday, March 20, 2002 9:46 AM
To: Kernel Debugging Interest List
Subject: [windbg] !analyze -v behavior/bug?

I was single-stepping through code to get to trace the behavior leading
up to a bugcheck, and noticed a bug (?) with !analyze -v:
---------------snip-----------------------
kd> p
ati2draa!DrvBitBlt+1890:
bff12d1e 8b4850 mov ecx,[eax+0x50]
kd> p
ati2draa!DrvBitBlt+1893:
bff12d21 f781b807000000000080 test dword ptr [ecx+0x7b8],0x80000000
kd> p

*** Fatal System Error: 0x00000050
(0xF000EEF1,0x00000000,0xBFF12D21,0x00000000)

Driver at fault:
*** ati2draa.dll - Address BFF12D21 base at BFF10000, DateStamp 3b7d92ed

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80579b54 cc int 3
kd> !analyze -v
The debuggee is ready to run
kd> !analyze -v
The debuggee is ready to run
kd> p

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

*
****************************************************************************
***
Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction+1:
80579b55 c20400 ret 0x4
kd> !analyze -v
The debuggee is ready to run

---------------snip-----------------------

Shouldn’t “!analyze -v” be able to dump out the bugcheck analysis at
this point? If I let the system go on to generate the full dump of
physical memory, the debugger will break in after the dump is complete
and then “!analyze -v” works as expected… I don’t need the analysis
(since I know exactly where and how the problem occurs), but I thought
I’d report this anyways…

Both machines are XP Pro…

sean


You are currently subscribed to windbg as:
xxxxx@exchange.sandiegoca.ncr.com
To unsubscribe send a blank email to %%email.unsub%%

From the docs:

!analyzebugcheck
[This is preliminary documentation and subject to change.]

The !analyzebugcheck extension command is obsolete. Use !analyze instead

sean

Joshi, Venu wrote:

Try “analyzebugcheck -v”

-----Original Message-----
From: Sean Bullington [mailto:xxxxx@stg.com]
Sent: Wednesday, March 20, 2002 9:46 AM
To: Kernel Debugging Interest List
Subject: [windbg] !analyze -v behavior/bug?

I was single-stepping through code to get to trace the behavior leading
up to a bugcheck, and noticed a bug (?) with !analyze -v:
---------------snip-----------------------
kd> p
ati2draa!DrvBitBlt+1890:
bff12d1e 8b4850 mov ecx,[eax+0x50]
kd> p
ati2draa!DrvBitBlt+1893:
bff12d21 f781b807000000000080 test dword ptr [ecx+0x7b8],0x80000000
kd> p

*** Fatal System Error: 0x00000050
(0xF000EEF1,0x00000000,0xBFF12D21,0x00000000)

Driver at fault:
*** ati2draa.dll - Address BFF12D21 base at BFF10000, DateStamp 3b7d92ed

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

*
****************************************************************************
***

Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction:
80579b54 cc int 3
kd> !analyze -v
The debuggee is ready to run
kd> !analyze -v
The debuggee is ready to run
kd> p

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

****************************************************************************
***
*

*
* Bugcheck
Analysis *
*

*
****************************************************************************
***
Use !analyze -v to get detailed debugging information.

BugCheck 50, {f000eef1, 0, bff12d21, 0}

Probably caused by : ati2draa.dll ( ati2draa!DrvBitBlt+1893 )

Followup: MachineOwner

nt!RtlpBreakWithStatusInstruction+1:
80579b55 c20400 ret 0x4
kd> !analyze -v
The debuggee is ready to run

---------------snip-----------------------

Shouldn’t “!analyze -v” be able to dump out the bugcheck analysis at
this point? If I let the system go on to generate the full dump of
physical memory, the debugger will break in after the dump is complete
and then “!analyze -v” works as expected… I don’t need the analysis
(since I know exactly where and how the problem occurs), but I thought
I’d report this anyways…

Both machines are XP Pro…

sean


You are currently subscribed to windbg as:
xxxxx@exchange.sandiegoca.ncr.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to windbg as: xxxxx@stg.com
To unsubscribe send a blank email to %%email.unsub%%