WinDbg fails to decode

Hannes

unread,

Apr 16, 2005, 2:29:02 AM4/16/05

to

In my attempt to generate minidumps from kernel crashes (which means I can
NOT use the SDK dbghelp API), I am down to just a few missing pieces:

I can't see call stack, or local+global variables.

Can anyone let me know what piece of information WinDbg is missing in the
dump?

/ Hannes.

PS. The actual crash is intentional - a NULL pointer dereference @ b9267cdd

Loading Dump File [\\134.56.72.93\c$\shout\Public\Crash\kernel_temp-SPM.dmp]
User Mini Dump File: Only registers, stack and portions of memory are
available

WARNING: Minidump contains unknown stream type 0x10000
WARNING: Minidump contains unknown stream type 0x10001
**** AddRegion: Empty region being added.
Windows Server 2003 Version 3790 (Service Pack 1, v.1247) UP Free x86
compatible
Product: Server, suite: Enterprise TerminalServer
Debug session time: Fri Apr 15 16:42:43.000 2005 (GMT-7)
System Uptime: not available
Process Uptime: not available
Symbol search path is:
\\hectori\symbols\win2k3sp1_2;SRV*\\hectori\symbols\web*http://msdl.microsoft.com/download/symbols;f:\projects\dumper\debug
Executable search path is:
\\test38\c$\windows\system32;\\test38\c$\windows\system32\drivers
.........................................................................................................
(4.c54): Access violation - code c0000005 (!!! second chance !!!)
eax=82391872 ebx=00000000 ecx=00000014 edx=82390014 esi=85a0a990 edi=00000000
eip=b9267cdd esp=bad10c60 ebp=bad10cb0 iopl=0 nv up ei pl zr na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
spm!ProcessIpPacket+0x5d:
b9267cdd 0fb60d00000000 movzx ecx,byte ptr [00000000] ds:0023:00000000=??
WARNING: Teb 0 pointer is NULL - defaulting to 7ffde000
WARNING: 7ffde000 does not appear to be a TEB
0:000> !analyze -v
*******************************************************************************
*
*
* Exception Analysis
*
*
*
*******************************************************************************

WARNING: Teb 0 pointer is NULL - defaulting to 7ffde000
WARNING: 7ffde000 does not appear to be a TEB
WARNING: Teb 0 pointer is NULL - defaulting to 7ffde000
WARNING: 7ffde000 does not appear to be a TEB

FAULTING_IP:
+b9267cdd
b9267cdd ?? ???

EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: b9267cdd
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000

DEFAULT_BUCKET_ID: APPLICATION_FAULT

PROCESS_NAME: ntoskrnl.exe

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

READ_ADDRESS: 00000000

BUGCHECK_STR: ACCESS_VIOLATION

THREAD_ATTRIBUTES:
LAST_CONTROL_TRANSFER: from 00000000 to b9267cdd

STACK_TEXT:
bad10cb0 00000000 00000000 00000000 00000000 spm!ProcessIpPacket+0x5d
[f:\projects\shoutdev\spm\spm.c @ 7600]

FOLLOWUP_IP:
spm!ProcessIpPacket+5d [f:\projects\shoutdev\spm\spm.c @ 7600]
b9267cdd 0fb60d00000000 movzx ecx,byte ptr [00000000]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: spm!ProcessIpPacket+5d

MODULE_NAME: spm

IMAGE_NAME: spm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 426051a3

STACK_COMMAND: .ecxr ; kb

FAILURE_BUCKET_ID: ACCESS_VIOLATION_spm!ProcessIpPacket+5d

BUCKET_ID: ACCESS_VIOLATION_spm!ProcessIpPacket+5d

Followup: MachineOwner
---------

0:000> kb
WARNING: Teb 0 pointer is NULL - defaulting to 7ffde000
WARNING: 7ffde000 does not appear to be a TEB
ChildEBP RetAddr Args to Child
bad10cb0 00000000 00000000 00000000 00000000 spm!ProcessIpPacket+0x5d
[f:\projects\dumper\spm\spm.c @ 7600]

Jason Shay [MSFT]

unread,

Apr 17, 2005, 2:44:37 PM4/17/05

to

What did you use to try to create this user-dump from kd? There are all
sorts of problems with doing this and having a workable dump, which is why
the debugger doesn't even try.

In any case, I'd guess these warnings are the root cause:

> WARNING: Minidump contains unknown stream type 0x10000
> WARNING: Minidump contains unknown stream type 0x10001
> **** AddRegion: Empty region being added.

.dumpdebug may be helpful here.

--
Jason Shay [MSFT]
js...@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Hannes" <hanne...@nospam.nospam> wrote in message
news:2C09FD45-1D0B-4E34...@microsoft.com...

Hannes

unread,

Apr 18, 2005, 2:15:02 PM4/18/05

to

"Jason Shay [MSFT]" wrote:
> What did you use to try to create this user-dump from kd? There are all
> sorts of problems with doing this and having a workable dump, which is why
> the debugger doesn't even try.

We are writing our own exception handler for our kernel driver, so a
minidump is created based on the SDK documentation of the minidump format.
Currently looking for a good way of troubleshooting this development.

> In any case, I'd guess these warnings are the root cause:
> > WARNING: Minidump contains unknown stream type 0x10000
> > WARNING: Minidump contains unknown stream type 0x10001

These two are OK, we've been using these two extra streams for additional
proprietary exception information in the past, and they do not seem to bother
the debugger. A "good" minidump aqlso has these in it, and they are simply
ignored by WinDbg.

> > **** AddRegion: Empty region being added.

My bad, I added an undefined memory region. Removed it, but my initial issue
still remains.

> ..dumpdebug may be helpful here.
I was not aware of that command. Thanks! It seems, however, to yield the
same output as the 'dumpchk' command line tool.

Any other way to see why WinDbg is unhappy?
Any other tools/programs/commands to further analyze my dump files?

/ Hannes.

Hannes

unread,

Apr 19, 2005, 4:47:03 PM4/19/05

to

It appears that the our minidumps open just fine - including local variables
and stack trace - in Visual Studio .NET 2003, but WinDbg fails to view the
stack.

Can WinDbg be debugged? Does it produce a log file of any sort that could
explain why it's unhappy with the dump file?

Thanks,

/ Hannes.

Jason Shay [MSFT]

unread,

Apr 19, 2005, 9:29:33 PM4/19/05

to

What you are trying to accomplish is not a supported scenario; the user
minidump format is intended for usermode only. You could put kernel-mode
data into the format, but the debugger will be making usermode assumptions,
such as loading user-mode debug extensions, or looking for the TEB, or not
expecting trap frames in the stack traces (the list goes on). Little pieces
may work here and there, but many areas would break because of the umode
assumptions which the debugger is making. It is good that VS properly gets
your stack traces, however that does not change that what you are attempting
is not supported, even if it seems like it kind of works in some places.

There is a kernel minidump formatted, unfortunately it is undocumented. I
normally would say to go the WER route, however you mentioned in a separate
thread that this is not an option due to no swap file being present. For
the longer-term, there is work in LH to support a crash dump in the absence
of a page file.

But as a shot-in-the dark guess, the stack trace is incomplete because of
the TEB errors. The stack trace algorithm is trying to impose a 'valid
stack bounds' based on data in the TEB, which is cutting the trace short.
Since the ebp value of 0xbad10cb0 is beyond the bounds . I'm also going to
take a guess that VS does not use these stack bounds from the TEB, which is
why their stack trace works.

If you'd like, feel free to email me one of the dump files you are
generating at js...@microsoft.com. If it appears to be something trivial
that you can do during your dump creation to get a stack trace, we may be
able to be of some help. But the experience of debugging these dumps will
likely be a painful one, since most debugger commands will likely not work.
Going further down this path is sure to being about many difficulties.

--
Jason Shay [MSFT]
js...@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Hannes" <hanne...@nospam.nospam> wrote in message

news:3DBE0F8A-90DD-4EA4...@microsoft.com...

Hannes

unread,

Apr 20, 2005, 4:48:03 PM4/20/05

to

"Jason Shay [MSFT]" wrote:
> If you'd like, feel free to email me one of the dump files you are
> generating at js...@microsoft.com. If it appears to be something trivial
> that you can do during your dump creation to get a stack trace, we may be
> able to be of some help. But the experience of debugging these dumps will
> likely be a painful one, since most debugger commands will likely not work.
> Going further down this path is sure to being about many difficulties.

I have sent you an email with instructions where to get the minidump, and
accompanying files.

Thanks,

/ Hannes.