memory dump in windows 2000 server

supesman

Senior member
Feb 11, 2001
714
0
0
I occasionally have memory dumps, like maybe once eveyr 2-3 months. I don't know how to go about debugging them. Also, is it safe to delete the *.dmp file that windows creates? I have once from the most recent dump that's 353mb. How can I find out what the correct method for debugging, thanks
 

NogginBoink

Diamond Member
Feb 17, 2002
5,322
0
0
Yes, you can delete the dump files.

Unless you know the innards of the i386 processor, assembly language, and NT data structs, debugging your own dumps just isn't feasible. Access to the W2K source code sure helps, too.
 

supesman

Senior member
Feb 11, 2001
714
0
0
well, how can i find out what's causing this? is it a bad file? is my memory bad?
 

NogginBoink

Diamond Member
Feb 17, 2002
5,322
0
0
Depends on the STOP code and parameters in parentheses. Post that info.

FWIW, here's a typical debug session. I've edited out a lot of extraneous stuff:



kd> kv
ChildEBP RetAddr Args to Child
bec628c0 80465f1b bec628dc 00000000 bec62930 nt!KiDispatchException+0x30e (FPO: [Non-Fpo]) (CONV: stdcall)
bec62928 80465ecd bec62d38 00000246 80402695 nt!CommonDispatchException+0x4d (FPO: [0,20,0]) (CONV: cdecl)
bec62934 80402695 bec6297c 85902e0c 85902da0 nt!KiUnexpectedInterruptTail+0x1f4
bec62948 8042d75b 00000004 e1e1aee8 85aa8ee8 nt!KiSwapThread+0xd5 (FPO: [EBP 0xbec6297c] [0,0,4])
bec629ec 804924a6 00000001 85a903a0 85b42020 nt!KeWaitForMultipleObjects+0x266 (FPO: [Non-Fpo]) (CONV: stdcall)
00000001 00000000 00000000 00000000 00000000 nt!ExpAllocateHandleTableEntry+0x246 (FPO: [Non-Fpo]) (CONV: stdcall)
kd> .exr bec628dc;.trap bec62930;kv
ExceptionAddress: 804505d9 (nt!NtWaitForMultipleObjects+0x00000275)
ExceptionCode: c0000005
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 42160e66
Attempt to read from address 42160e66
ErrCode = 00000000
eax=42160e1e ebx=85aa8ee8 ecx=e1e1aee8 edx=85b42008 esi=e1e1aee8 edi=00000004
eip=804505d9 esp=bec629a4 ebp=bec62d48 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282
nt!NtWaitForMultipleObjects+275:
804505d9 8b4048 mov eax,[eax+0x48] ds:0023:42160e66=????????
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
bec62d48 80465091 00000002 03c4fe80 00000001 nt!NtWaitForMultipleObjects+0x275 (FPO: [Non-Fpo]) (CONV: stdcall)
bec62d48 77f837b2 00000002 03c4fe80 00000001 nt!_KiSystemService+0xc4 (FPO: [0,0] TrapFrame @ bec62d64) (CONV: cdecl)
03c4fea8 77e12a00 03c4fe80 00000001 00000000 ntdll!LdrpSnapIAT+0xf4 (FPO: [Non-Fpo])
03c4ff04 77e12a77 03c4fed0 77cb41c0 0000ea60 USER32!_GetWindow+0x2 (FPO: [2,0,3])
03c4ff20 77c764ff 00000001 77cb41c0 00000000 USER32!_GetWindow+0x79 (FPO: [2,0,3])
WARNING: Stack unwind information not available. Following frames may be wrong.
03c4ff74 77c78ffd 03c4ffa0 03c4ffa4 03c4ffa8 SHLWAPI+0x64ff
03c4ffac 77c78f85 00000000 77e887dd 00000000 SHLWAPI+0x8ffd
03c4ffec 00000000 77c78f5c 00000000 00000000 SHLWAPI+0x8f85
kd>

You should view the above in a fixed-width font for readability. What we see here is that the system called WaitForMultipleObjects and crashed. Now, the second parameter to NtWaitForMultipleObjects is a list of handles. In this case, the pointer is 03c4fe80. A handle is a kernel mode object and must reside in kernel memory space. Kernel memory space is 80000000 and above. So whatever was passed into NtWaitForMultipleObjects wasn't a list of objects and the machine crashed.

In the information I've given, there's not enough information to tell where that number came from, but that would be the next step in determining the cause of the crash. Sometimes it's just not possible to go back in time from a dump file.
 

supesman

Senior member
Feb 11, 2001
714
0
0
wow i hadn't realized it was that complicated, thanks for your help anyway Noggin.
 

NogginBoink

Diamond Member
Feb 17, 2002
5,322
0
0
Oogle has some valid points. Just don't put too much faith in !analyze -v; it can and will lead you astray on occasion.

In general, though, !analyze -v is reasonably good at diagnosing the most common bugchecks.

Supesman, post your STOP code and the parameters and I'll see if I have any info on it.
 

supesman

Senior member
Feb 11, 2001
714
0
0
ok, thanks Oogle, i'll get those tools from microsoft's website. Noggin, the crash happened again and rather than let the dump go to completion, i just turned off my computer in frustration so the dump file is incomplete. when it happens again i'll let you know, thanks. btw, i think it has to do to kazaa's speed up program or with kazaa itself i'll try to uninstall and reinstall with a new version.
 

supesman

Senior member
Feb 11, 2001
714
0
0
Ok, i ran windbg and here's the result, i don't know what this means:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck parens is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


BUGCHECK_STR: 0x7f_d

TRAP_FRAME: 00000000 -- (.trap 0)

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 00000000 to 80468c9e

STACK_TEXT:
f3be9c44 00000000 00000000 00000000 00000000 nt!KiSystemFatalException+0xe


FOLLOWUP_IP:
nt!KiSystemFatalException+e
80468c9e c3 ret

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!KiSystemFatalException+e

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3d366b8b

STACK_COMMAND: .trap 0 ; kb

BUCKET_ID: ZEROED_STACK

Followup: MachineOwner
 

supesman

Senior member
Feb 11, 2001
714
0
0
Here's the stop code i got:

STOP: 0x0000001E (0x0000001D, 0x80491E04, 0x0000006A, 0x00000072)
KMODE_EXCEPTION_NOT_HANDLED
Address 80491E04 base at 80400000, Datestamp 3d366b8b - ntoskrnl.exe
 

NogginBoink

Diamond Member
Feb 17, 2002
5,322
0
0
Your bugcheck analysis shows you had a STOP 7F. Now you're getting a STOP 1E.

Go to your system event log and filter on "Save Dump." Get us a list of all the STOPs you've had.