Understand why your computer restarted unexpectedly

Many people have experienced unexpected computer restarts. Unexpected restarts can be caused by bugs in Windows Kernel, bugs in critical Windows Services, bugs in drivers, among other things.

When Windows experiences an unexpected restart request, it will create a mini dump capturing the minimum information about the state of the computer. If permitted, it will also try to create a full memory dump. The mini dump is saved to %windir%\Minidump, with the date in the file name. The full memory dump is stored in %windir%, with the name MEMORY.DMP.

C:\Windows>dir /s *.dmp

Volume in drive C is Vista

Volume Serial Number is C84C-2424

Directory of C:\Windows

02/14/2007 03:58 PM 243,826,967 MEMORY.DMP

1 File(s) 243,826,967 bytes

Directory of C:\Windows\Minidump

01/29/2007 11:11 AM 145,256 Mini012907-01.dmp

02/02/2007 11:14 AM 140,448 Mini020207-01.dmp

02/14/2007 03:58 PM 140,448 Mini021407-01.dmp

3 File(s) 426,152 bytes

Total Files Listed:

4 File(s) 244,253,119 bytes

0 Dir(s) 5,589,950,464 bytes free


On restart, Windows will detect that the computer has restarted unexpectedly, and ask the user if they want to submit a report to Microsoft. If the user chooses to do so, Microsoft can analyze the memory dump, inform the user what causes the unexpected restart if enough information can be obtained from the dump, and direct user to solutions if available.

If you are curious what caused the unexpected restart, you can use those memory dumps to figure that out.

First, we need to download Windows Debugger from microsoft.com (http://www.microsoft.com/whdc/devtools/debugging/default.mspx). You can choose where to install Windows Debugger. I usually install it to c:\debuggers, and add it to my PATH environment variable.

Once the debugger is installed, we can use the debugger to analyze the dump.

C:\Windows\Minidump>c:\debuggers\kd -z Mini021407-01.dmp

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

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

Symbol search path is: *** Invalid ***
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *

We need to tell the debugger where to find the symbols for Windows binaries. We can use the Microsoft public symbol server to get the symbols, as documented here http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx.

1: kd> .sympath srv*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*http://msdl.microsoft.com/download/symbols

let's start the analysis.

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

An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arg1: 0462d6d8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8e5fdb69, address which referenced memory

Debugging Details:

READ_ADDRESS: GetPointerFromAddress: unable to read from 819315ac
Unable to read MiSystemVaType memory at 81911780


8e5fdb69 ?? ???





TRAP_FRAME: 89e23aa0 -- (.trap ffffffff89e23aa0)
ErrCode = 00000000
eax=85a15bec ebx=86bfc128 ecx=8c738000 edx=eefdeadb esi=859a1f88 edi=859f7000
eip=8e5fdb69 esp=89e23b14 ebp=86bfc008 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
8e5fdb69 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from 8e5fdb69 to 8188fc44

89e23aa0 8e5fdb69 badb0d00 eefdeadb 86684a90 nt!KiTrap0E+0x2ac
WARNING: Stack unwind information not available. Following frames may be wrong.
89e23b10 89e23b88 89e23b70 86682068 00000000 nvlddmkm+0x35b69
89e23b50 8e2f7f39 859f7000 89e23b88 86655770 0x89e23b88
89e23b70 8e2f76ec 89e23b88 818aeb77 86655000 dxgkrnl!DXGADAPTER::DdiSubmitComman
89e23bec 8e3165ff 00000006 8667a008 851877e8 dxgkrnl!VidSchiSendToExecutionQueue
89e23c68 8e31624e 866558d8 00000001 851877e8 dxgkrnl!VidSchiSendToExecutionQueue
89e23d48 8e3145e7 01fffbf7 84ca0400 89e23d6c dxgkrnl!VidSchiSubmitRenderCommand+
89e23d58 8e31cfc1 851877e8 00000000 8667a008 dxgkrnl!VidSchiSubmitQueueCommand+0
89e23d6c 8e35caf2 8667a008 86684a90 89e23dc0 dxgkrnl!VidSchiRun_PriorityTable+0x
89e23d7c 81a254a8 8667a008 89e28680 00000000 dxgkrnl!VidSchiWorkerThread+0x61
89e23dc0 8189145e 8e35ca91 8667a008 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


8e5fdb69 ?? ???


SYMBOL_NAME: nvlddmkm+35b69


MODULE_NAME: nvlddmkm

IMAGE_NAME: nvlddmkm.sys


FAILURE_BUCKET_ID: 0xD1_nvlddmkm+35b69

BUCKET_ID: 0xD1_nvlddmkm+35b69

Followup: MachineOwner

OK, so the problem is caused by nvlddmkm.sys. Search it on the web reveals that this is part of NVidia's graphics driver.

This problem for me happened in Feburary 2007. NVidia has new driver published in its web site. I installed the new driver. I haven't experienced any unexpected restart since then.

As you can see above, it is fairly easy to figure out why you computer restarted unexpectedly.

Comments (9)

  1. Anonymous Coward says:

    Except when some random corruption goes unnoticed for a random amount of time and then some unsuspecting victim tries to use that data and crashes.

    Just like in user mode, sometimes the cause of the crash is right in front of your eyes, sometimes it takes weeks of painful investigation to figure the root cause out.

  2. Norman Diamond says:

    Your article is 99% helpful, but still…

    > On restart, Windows will detect that the

    > computer has restarted unexpectedly, and ask

    > the user if they want to submit a report to

    > Microsoft.

    I wish that were true more often than it actually is.

    Also, in order to get a full MEMORY.DMP file, you need to have a pagefile on the same partition where Windows is installed, that pagefile has to be larger than the amount of RAM you have, and you need enough additional free space on the same partition where Windows is installed.  (Though even when these conditions are met, there are still a lot of occasions where Windows doesn’t offer to send a crash report.)

  3. Norman,

    You are absolutely right. But as shown from my article, you can get helpful information from the mini dump.

  4. ShayEr says:

    instead of .sympath use .symfix without needing to provide the url.

  5. Frank says:

    So my computer bluescreened and as you described, a memory dmp file was created; however Vista never seems to detect that it happened and doesn’t try to send the report. Is there a way to manually send a problem report with the memory.dmp file?

  6. Open control panel, search for "report", you should be able to see "problem reports and solutions".

  7. James Harrington says:

    My computer restarts again and again consecutively. The moment the Windows desktop appears is the same exact moment it restarts automatically. Sometimes it restarts even BEFORE the desktop has appeared. Hence, it is IMPOSSIBLE for me to even check anything. How do I fix this?

    PS Im writing this in another computer.

  8. You need to press F5 (or F8) during the boot to enter the boot menu. Once you are in the boot menu, select safe mode.

    Now right click on My Computer, Property, Advanced, Startup and Recovery, Click Settings, make sure the automatically restart is not selected.

    Most likely you have install a faulty driver. You probably need to remove the driver in safe mode.  

  9. umeca74 says:

    thanks for the informative article

    Figuring out minidumps (stack traces etc) is going to be essential in vista, now that dr watson is no longer part of the distribution

    I was used to dealing with dr watson crash logs to figure out unexplained crashes of my program on remote (users’) computers. I haven’t got a clue how to get the same info from a minidump.

    Your article goes some way to help, but I find the windbg learning curve too steep 🙂

    is there a simpler tool for this job? I just need to get the stack unwind info where the crash occured



Skip to main content