How should I approach analysing this Windows crash dump?

0

My Windows Vista x64 is crashing every once in a while. Can somebody tell me what is wrong according to this crashdump?

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\Mini102109-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6001.18145.amd64fre.vistasp1_gdr.080917-1612
Machine Name:
Kernel base = 0xfffff800`01a0c000 PsLoadedModuleList = 0xfffff800`01bd1db0
Debug session time: Wed Oct 21 10:30:41.928 2009 (GMT+2)
System Uptime: 0 days 0:00:16.021
Loading Kernel Symbols
..........................................
Loading User Symbols
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000007E, {ffffffffc0000005, fffff80001cdd46a, fffffa6002a04328, fffffa6002a03d00}

Probably caused by : fileinfo.sys ( fileinfo!FIPfInterfaceClose+48 )

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

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

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80001cdd46a, The address that the exception occurred at
Arg3: fffffa6002a04328, Exception Record Address
Arg4: fffffa6002a03d00, Context Record Address

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - De instructie op 0x%08lx verwijst naar geheugen op 0x%08lx. Een lees- of schrijfbewerking op het geheugen is mislukt: %s.

FAULTING_IP: 
nt!ObpReleaseHandleInfo+4a
fffff800`01cdd46a 418b4908        mov     ecx,dword ptr [r9+8]

EXCEPTION_RECORD:  fffffa6002a04328 -- (.exr 0xfffffa6002a04328)
Cannot read Exception record @ fffffa6002a04328

CONTEXT:  fffffa6002a03d00 -- (.cxr 0xfffffa6002a03d00)
Unable to read context, Win32 error 0n30

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x7E

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80001cdd9cd to fffff80001cdd46a

STACK_TEXT:  
fffffa60`02a04568 fffff800`01cdd9cd : 00000000`00000000 fffffa80`07c75b20 fffff880`000033d0 00000000`00000000 : nt!ObpReleaseHandleInfo+0x4a
fffffa60`02a04570 fffff800`01cddd07 : fffff880`000033e0 fffffa80`00000000 fffffa80`06cc5690 00000000`00000000 : nt!ObpDecr

Chris

Posted 2009-10-21T08:42:21.500

Reputation: 1 093

Not related to DEP. That has to do with trying to execute code from a memory page that had the no-execute flag set. That's not the case here. This would be an attempt to write to a read-only page, or access a v.a. that isn't defined at all. Since the debugger reports "unable to read exception record" and "...context record", it is not possible from this output to see what virtual address was being accessed. – Jamie Hanrahan – 2014-11-29T04:47:11.710

The error message suggest that he tried to read/write from a protected memory...maybe an application problem? I mean, does Vista also crash while you're doing nothing, or does it only crash if you're using a certain program(s)? – Bobby – 2009-10-21T08:52:19.373

Isn't this related to DEP then? – None – 2009-10-21T08:54:31.460

Answers

0

Your clues are:

- SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M
- VISTA_DRIVER_FAULT
- IMAGE_NAME:  fileinfo.sys

user3463

Posted 2009-10-21T08:42:21.500

Reputation:

With ever larger amounts of memory being installed in PCs it is always a good idea to burn it in with Memtest http://www.memtest.org/ for a few days early on. We do this with all our VMware ESX Servers and have caught some dodgy RAM early enough before they get commissioned into production.

– Sim – 2010-02-09T10:45:02.577

Sim - my situation was very odd: four slots, all populated with Kingston RAM. PC kept blue-screening ~40 seconds into boot. Replaced two of them with cheap RAM, problem went away (still going strong 3 years later, and RAM redeployed to another box and working fine too). MemTest found nothing wrong on all counts, and suppliers agreed, so I'm thinking it's one of those things that "just happen". shrug – None – 2010-02-09T13:12:44.813

Well that is just plain weird Randolph, maybe a weird timing issue. At least you got a good workaround in the end. – Sim – 2010-02-10T00:13:24.290

I have 8 gigs of internal memory, obviously one of the 4 modules was faulty, I removed that one, and all was ok again. – Chris – 2009-12-10T11:26:51.903

Good to know. I had a similar problem with some Kingston RAM, which was replaced with cheap no-name and the machine has been fine ever since. Suppliers said original RAM is fine. Go figure. – None – 2009-12-10T13:17:34.083