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 *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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.
Arguments:
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
0462d6d8

CURRENT_IRQL: 2

FAULTING_IP:
nvlddmkm+35b69
8e5fdb69 ?? ???

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_RC

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

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
nvlddmkm+0x35b69:
8e5fdb69 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from 8e5fdb69 to 8188fc44

STACK_TEXT:
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
d+0x39
89e23bec 8e3165ff 00000006 8667a008 851877e8 dxgkrnl!VidSchiSendToExecutionQueue
+0x6ac
89e23c68 8e31624e 866558d8 00000001 851877e8 dxgkrnl!VidSchiSendToExecutionQueue
WithWait+0xca
89e23d48 8e3145e7 01fffbf7 84ca0400 89e23d6c dxgkrnl!VidSchiSubmitRenderCommand+
0x50c
89e23d58 8e31cfc1 851877e8 00000000 8667a008 dxgkrnl!VidSchiSubmitQueueCommand+0
x61
89e23d6c 8e35caf2 8667a008 86684a90 89e23dc0 dxgkrnl!VidSchiRun_PriorityTable+0x
24
89e23d7c 81a254a8 8667a008 89e28680 00000000 dxgkrnl!VidSchiWorkerThread+0x61
89e23dc0 8189145e 8e35ca91 8667a008 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
nvlddmkm+35b69
8e5fdb69 ?? ???

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nvlddmkm+35b69

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nvlddmkm

IMAGE_NAME: nvlddmkm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 452e68ea

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.