Windows Minidump Error Analysis

Hi All,

I have a mini dump that I am analyzing, but the analysis is just as
cryptic as the minidump. Can you please help? The Minidump is below:

Thanks for you help!

  • Cedric

Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\Symbols\XPSP2

Executable search path is:

Unable to load image ntoskrnl.exe, Win32 error 0n2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86
compatible

Product: WinNt, suite: TerminalServer SingleUserTS

Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c720

Debug session time: Thu May 14 16:47:02.628 2009 (GMT-4)

System Uptime: 0 days 0:27:58.477

Unable to load image ntoskrnl.exe, Win32 error 0n2

*** WARNING: Unable to verify timestamp for ntoskrnl.exe

Loading Kernel Symbols


Loading User Symbols

Loading unloaded module list

Unable to load image nv4_mini.sys, Win32 error 0n2

*** WARNING: Unable to verify timestamp for nv4_mini.sys

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

*
*

* Bugcheck Analysis
*

*
*

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

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, ba016374, b6083c1c, 0}

Probably caused by : nv4_mini.sys ( nv4_mini!DoRegOp+6c4 )

Followup: MachineOwner


1: kd> !analyze -v

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

*
*

* Bugcheck Analysis
*

*
*

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)

This is a very common bugcheck. Usually the exception address pinpoints

the driver/function that caused the problem. Always note this address

as well as the link date of the driver/image that contains this address.

Some common problems are exception code 0x80000003. This means a hard

coded breakpoint or assertion was hit, but this system was booted

/NODEBUG. This is not supposed to happen as developers should never
have

hardcoded breakpoints in retail code, but …

If this happens, make sure a debugger gets connected, and the

system is booted /DEBUG. This will let us see why this breakpoint is

happening.

Arguments:

Arg1: c0000005, The exception code that was not handled

Arg2: ba016374, The address that the exception occurred at

Arg3: b6083c1c, Trap Frame

Arg4: 00000000

Debugging Details:


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

FAULTING_IP:

nv4_mini!DoRegOp+6c4

ba016374 8b4158 mov eax,dword ptr [ecx+58h]

TRAP_FRAME: b6083c1c – (.trap 0xffffffffb6083c1c)

ErrCode = 00000000

eax=00000000 ebx=8a511900 ecx=00000000 edx=00000000 esi=8a404908
edi=00000002

eip=ba016374 esp=b6083c90 ebp=8a534808 iopl=0 nv up ei pl zr na
pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246

nv4_mini!DoRegOp+0x6c4:

ba016374 8b4158 mov eax,dword ptr [ecx+58h]
ds:0023:00000058=???

Resetting default scope

CUSTOMER_CRASH_COUNT: 4

DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: WINWORD.EXE

LAST_CONTROL_TRANSFER: from ba22434b to ba016374

STACK_TEXT:

b6083c8c ba22434b 00000000 00000000 00000000 nv4_mini!DoRegOp+0x6c4

b6083c90 00000000 00000000 00000000 8a511900
nv4_mini!_NULL_IMPORT_DESCRIPTOR (nv4_mini+0x28b34b)

STACK_COMMAND: kb

FOLLOWUP_IP:

nv4_mini!DoRegOp+6c4

ba016374 8b4158 mov eax,dword ptr [ecx+58h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nv4_mini!DoRegOp+6c4

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nv4_mini

IMAGE_NAME: nv4_mini.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47bedc89

FAILURE_BUCKET_ID: 0x8E_nv4_mini!DoRegOp+6c4

BUCKET_ID: 0x8E_nv4_mini!DoRegOp+6c4

Followup: MachineOwner

---------

Cedric Lee wrote:

Hi All,

I have a mini dump that I am analyzing, but the analysis is just as
cryptic as the minidump. Can you please help? The Minidump is below:

What were you doing at the time? What you have here is an attempt to
dereference an item in a structure using a null pointer, inside the
miniport driver for your nVidia graphics card.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

It sounds like you need to do what it is telling you - reboot with a debugger attached. There isn’t anyway to debug this as it currently stands.

Good luck,

mm

Ignore what I said - it made no sense.

Sorry,

mm

I’d try to upgrade the NVida drivers.

On Fri, May 15, 2009 at 10:51 AM, Cedric Lee wrote:

> Hi All,
>
>
>
> I have a mini dump that I am analyzing, but the analysis is just as cryptic
> as the minidump. Can you please help? The Minidump is below:
>
>
>
> Thanks for you help!
>
>
>
> - Cedric
>
>
>
>
>
> Mini Kernel Dump File: Only registers and stack trace are available
>
>
>
> Symbol search path is: C:\Symbols\XPSP2
>
> Executable search path is:
>
> Unable to load image ntoskrnl.exe, Win32 error 0n2
>
> WARNING: Unable to verify timestamp for ntoskrnl.exe
>
> Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86
> compatible
>
> Product: WinNt, suite: TerminalServer SingleUserTS
>
> Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c720
>
> Debug session time: Thu May 14 16:47:02.628 2009 (GMT-4)
>
> System Uptime: 0 days 0:27:58.477
>
> Unable to load image ntoskrnl.exe, Win32 error 0n2
>
>
WARNING: Unable to verify timestamp for ntoskrnl.exe
>
> Loading Kernel Symbols
>
>
> …
>
> Loading User Symbols
>
> Loading unloaded module list
>
> …
>
> Unable to load image nv4_mini.sys, Win32 error 0n2
>
> WARNING: Unable to verify timestamp for nv4_mini.sys
>
>
>
****************************************************************************
>
> *
> *
>
> * Bugcheck
> Analysis *
>
> *
> *
>
>
>
>
>
>
> Use !analyze -v to get detailed debugging information.
>
>
>
> BugCheck 1000008E, {c0000005, ba016374, b6083c1c, 0}
>
>
>
> Probably caused by : nv4_mini.sys ( nv4_mini!DoRegOp+6c4 )
>
>
>
> Followup: MachineOwner
>
> ---------
>
>
>
> 1: kd> !analyze -v
>
>
>

>
> *
> *
>
> * Bugcheck
> Analysis *
>
> *
> *
>
>
> *******************************************************************************
>
>
>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
>
> This is a very common bugcheck. Usually the exception address pinpoints
>
> the driver/function that caused the problem. Always note this address
>
> as well as the link date of the driver/image that contains this address.
>
> Some common problems are exception code 0x80000003. This means a hard
>
> coded breakpoint or assertion was hit, but this system was booted
>
> /NODEBUG. This is not supposed to happen as developers should never have
>
> hardcoded breakpoints in retail code, but …
>
> If this happens, make sure a debugger gets connected, and the
>
> system is booted /DEBUG. This will let us see why this breakpoint is
>
> happening.
>
> Arguments:
>
> Arg1: c0000005, The exception code that was not handled
>
> Arg2: ba016374, The address that the exception occurred at
>
> Arg3: b6083c1c, Trap Frame
>
> Arg4: 00000000
>
>
>
> Debugging Details:
>
> ------------------
>
>
>
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
> referenced memory at “0x%08lx”. The memory could not be “%s”.
>
>
>
> FAULTING_IP:
>
> nv4_mini!DoRegOp+6c4
>
> ba016374 8b4158 mov eax,dword ptr [ecx+58h]
>
>
>
> TRAP_FRAME: b6083c1c – (.trap 0xffffffffb6083c1c)
>
> ErrCode = 00000000
>
> eax=00000000 ebx=8a511900 ecx=00000000 edx=00000000 esi=8a404908
> edi=00000002
>
> eip=ba016374 esp=b6083c90 ebp=8a534808 iopl=0 nv up ei pl zr na pe
> nc
>
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
>
> nv4_mini!DoRegOp+0x6c4:
>
> ba016374 8b4158 mov eax,dword ptr [ecx+58h]
> ds:0023:00000058=???
>
> Resetting default scope
>
>
>
> CUSTOMER_CRASH_COUNT: 4
>
>
>
> DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
>
>
>
> BUGCHECK_STR: 0x8E
>
>
>
> PROCESS_NAME: WINWORD.EXE
>
>
>
> LAST_CONTROL_TRANSFER: from ba22434b to ba016374
>
>
>
> STACK_TEXT:
>
> b6083c8c ba22434b 00000000 00000000 00000000 nv4_mini!DoRegOp+0x6c4
>
> b6083c90 00000000 00000000 00000000 8a511900
> nv4_mini!_NULL_IMPORT_DESCRIPTOR (nv4_mini+0x28b34b)
>
>
>
>
>
> STACK_COMMAND: kb
>
>
>
> FOLLOWUP_IP:
>
> nv4_mini!DoRegOp+6c4
>
> ba016374 8b4158 mov eax,dword ptr [ecx+58h]
>
>
>
> SYMBOL_STACK_INDEX: 0
>
>
>
> SYMBOL_NAME: nv4_mini!DoRegOp+6c4
>
>
>
> FOLLOWUP_NAME: MachineOwner
>
>
>
> MODULE_NAME: nv4_mini
>
>
>
> IMAGE_NAME: nv4_mini.sys
>
>
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 47bedc89
>
>
>
> FAILURE_BUCKET_ID: 0x8E_nv4_mini!DoRegOp+6c4
>
>
>
> BUCKET_ID: 0x8E_nv4_mini!DoRegOp+6c4
>
>
>
> Followup: MachineOwner
>
> ---------
>
>
>
> —
> 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
>