Difference between revisions of "Windows BSOD"

From OpenZFS on OS X
Jump to: navigation, search
m (WinDbg.exe in the GUI)
m (WinDbg.exe in the GUI)
Line 29: Line 29:
  
 
Launch WinDbg.exe and set the Symbol path in:
 
Launch WinDbg.exe and set the Symbol path in:
 
+
<nowiki>
 
  File > Symbol File Path:
 
  File > Symbol File Path:
 
  srv*c:\cache*https://msdl.microsoft.com/download/symbols;C:\Program Files (x86)\OpenZFS On Windows\symbols
 
  srv*c:\cache*https://msdl.microsoft.com/download/symbols;C:\Program Files (x86)\OpenZFS On Windows\symbols
 +
</nowiki>
  
 
So that it can load both the symbols from Microsoft, and from the installed Open ZFS directory.  
 
So that it can load both the symbols from Microsoft, and from the installed Open ZFS directory.  

Revision as of 03:21, 6 June 2019

Windows Crash Dumps

If you do managed to get a Blue Screen Of Death (BSOD), Windows should in theory write a crash dump file to:

C:\Windows\MEMORY.DMP

The dump file can be analyzed with WinDbg.exe

Debug builds of ZFSin include debugging symbols to assist in dump analysis which are located at:

C:\Program Files (x86)\OpenZFS On Windows\symbols\

WinDbg.exe at the Command Line

Once installed, WinDbg.exe can be run from a CMD.com or PowerShell terminal with Administrative privileges:

WinDbgX.exe -y ‘C:\Program Files (x86)\OpenZFS On Windows\symbols\’ -z C:\Windows\MEMORY.DMP

This will launch the application and you can perform dump analysis with:

kd> !analyze -v

To run the analysis in a single command:

WinDbgX.exe -y ‘C:\Program Files (x86)\OpenZFS On Windows\symbols\’ -z C:\Windows\MEMORY.DMP -c !analyze -v

WinDbg.exe in the GUI

Launch WinDbg.exe and set the Symbol path in:

 File > Symbol File Path:
 srv*c:\cache*https://msdl.microsoft.com/download/symbols;C:\Program Files (x86)\OpenZFS On Windows\symbols
 

So that it can load both the symbols from Microsoft, and from the installed Open ZFS directory.


Open the crash dump file with:

File: Open crash dump
C:\Windows\MEMORY.DMP

Perform the analysis:

kd> !analyze -v

Should at least show the stack.

Example Crash report

A successful crash dump would look something like:

 	ZFSin!zfs_range_lock_reader+0x290 [c:\src\zfsin\zfsin\zfs\module\zfs\zfs_rlock.c @ 417]	C/C++/ASM
	ZFSin!zfs_range_lock+0x16d [c:\src\zfsin\zfsin\zfs\module\zfs\zfs_rlock.c @ 453]	C/C++/ASM
	ZFSin!zil_lwb_commit+0x99f [c:\src\zfsin\zfsin\zfs\module\zfs\zil.c @ 1570]	C/C++/ASM
	ZFSin!zil_process_commit_list+0x30e [c:\src\zfsin\zfsin\zfs\module\zfs\zil.c @ 2182]	C/C++/ASM
	ZFSin!zil_commit_writer+0x111 [c:\src\zfsin\zfsin\zfs\module\zfs\zil.c @ 2318]	C/C++/ASM

If you get only ZFSin+0x"hex-number" it means it is not reading the debug symbols correctly, to be able to convert the hex-number into a function name.


Debug Print Buffer

Windows features a circular debug print buffer which can also be written to disk:

2: kd> dt ZFSin!cbuf
0xffffe089`f0010000  "FFFFC1072DE87580: SPL: start.FFFFC1072DE87580: SPL: total ncpu 4

Note the first string, i.e. "0xffffe089`f0010000". Write the buffer out with the following:

kd> .writemem C:\Users\<your Windows username>\Desktop\cbuf.txt 0xffffe089`f0010000 L100000

Do not worry if you get a message about short write, it just means you have not yet filled the buffer.

This will include -EB- at the end of the buffer. Do not worry if the rest of the buffer has "@" (nul) symbols, it just means the buffer was not yet full.

Please provide the contents of the dump analysis and cbuf.txt in you ZFSin in your crash-related tickets.