Crash dump analyzis. Help is needed

Vladimir_Chtchetkine · February 4, 2004, 2:08pm

At the bottom there is !analyze -v output (W2KSP4)
How can I make stack looking more informative?

The driver at fault is not mine so I have no idea what it does nor I
have symbs for it. But I suspect that my driver is also somewhere on the
stack and I would like to see where.

TIA,

Vladimir

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or it
is pointing at freed memory.
Arguments:
Arg1: fffffff0, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8044f718, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: fffffff0 Nonpaged pool expansion

FAULTING_IP:
nt!ObfDereferenceObject+f
8044f718 8b73f0 mov esi,[ebx-0x10]

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from f881b2d6 to 8044f718

STACK_TEXT:
ede1fc48 f881b2d6 0166e08c 0166e088 00000000 nt!ObfDereferenceObject+0xf
WARNING: Stack unwind information not available. Following frames may be
wrong.
ede1fc74 e56c6946 81677340 00000001 00000001 DrvAtFault+0x192d6
05018001 00000000 00000000 00000000 00000000 0xe56c6946

FOLLOWUP_IP:
DrvAtFault+192d6
f881b2d6 5f pop edi

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: DrvAtFault+192d6

MODULE_NAME: DrvAtFault

IMAGE_NAME: DrvAtFault.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3f942acf

STACK_COMMAND: kb

BUCKET_ID: 0x50_DrvAtFault+192d6

Followup: MachineOwner

OSR_Community_User · February 4, 2004, 2:28pm

Vladimir,

If you would like, I can take a look at it. In exchange, I would like
to be able to use the dump in my debug class (I’m always looking for
good dumps and I need a good “walk up the stack” example.) In exchange
I’ll write up my analysis and send it to you.

The technique I normally use is to walk back up the stack manually - you
need to find an earlier call frame and then you can use “kv” from that
point (it requires the stack pointer, base pointer and instruction
pointer addresses to continue, which is why I focus on call frames -
return address gives you two of the three and usually you can figure out
the EBP from context in that frame or the next (later) frame.)

Regards,

Tony

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

Hope to see you at the next OSR file systems class in Boston, MA, March
29, 2004!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vladimir Chtchetkine
Sent: Wednesday, February 04, 2004 2:08 PM
To: ntdev redirect
Subject: [ntdev] Crash dump analyzis. Help is needed