I’ll just save this ….. (Pause click save draft )

Well this takes me neatly onto two things

Firstly

I was lucky enough to see this presentation at Tech-Ed 2008 EMEA from the IT God that is Mark Russinovich called a “case of the unexplained” 

He reminds me of Marvin the Paranoid Android  from hitch hikers guide, well at least the brain the size of a planet bit anyway… 

Secondly

I wanted to have a chance to put what I had learned into practice and also get the opportunity to blog about it, hey every cloud has a silver lining. So..  

I had already downloaded WinDbg so all I needed to do was update the symbols path …

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

and away we go..

So I locate the Crash Dump, I’m running Vista so its c:\windows\MEMORY.DMP

Open CrashDbg and (Ctrl+D) Open Crash Dump

There are two things I can do as a novice

I can click the nice little hyper link to see if this reveals anything

So I click !analyze –v and first of all see this

“KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
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 0×80000003.  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: 97b13949, The address that the exception occurred at
Arg3: beb70034, Trap Frame
Arg4: 00000000”

I look further down the irony is killing me …..

So I mentioned I was new to blogging, I have just set up an account today (well technically yesterday now) and installed Windows Live Writer Beta to write my blog entries

WinDbg
This is a great tool and while I admit I am a complete novice at this I’m sure you’ll agree that this is really useful information it even tells me what to do next …

Followup: MachineOwner

“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.”

As I am using a Beta version of the software I am going to follow the advice to boot my system /DEBUG, save frequently and if it happens again hopefully submit a useful crash dump to Microsoft!

Happy Hunting

Now the last time it crashed was when I pre-viewed my post ….. “pop”