So it happened, a serious Windows System Crash aka BSOD (Blue Screen Of Death). There may be hundreds of reasons why your Windows System has crashed but event logs just say that it crashed and wasn’t shut down clean – obvious!

We need to look a bit deeper in order to see what probably caused that behaviour. Let’s start with why it crashes. Windows crash most of time when:

  • a faulty or bad written driver wants to execute code outside its address range or tries to use different IRQ that it suppose to
  • a system service that is using a driver to perform specific tasks fails, thus driver fails. Services like this are often Firewalls and other parts of antivirus software. The work that way in order to avoid being stopped by a virus or user. You can disable it or set it to allow everything but it is working anyway
  • memory error. Faulty RAM can be problematic to narrow down but keep this in mind, that RAM sometimes just fails
  • other hardware error. Most of the parts that would be devices needing dedicated drivers, thus we are going to point 1

Ok so what to do if it crashes?

Mostly, ordinary reset would do the job. Trust me. Windows these days is a bit smarter that in Xp and previous era and can disable problematic drivers and services automatically. If after restart, or sometimes 2 or 3 Windows loads up and some service, software or device isn’t working. That was probably accused by Windows of crashing. Try to find newer/fixed versions.

But this is not the point! We WANT to know what caused this!

So, there are two most used by me and free tools to debug BSOD:

First one is quite easy to use. Just download, open as administrator and it should automatically find crash dumps and point to file that caused this. The thing is, it often blames ntoskrnl.exe which is Windows Kernel… Ok. So Kernel Crashed, and what next?

Next is more advanced tool, but litte harder to use. I personally prefer WinDbg over BlueScreenView but is completely up to you.

First you need to download Windows SDK and install only Debugging Tools for Windows from install options.

Then when you open WinDbg, you need to provided “symbols path” by selecting File->Symbols File Path or by pressing CTRL+S

Paste below code:

srv*https://msdl.microsoft.com/download/symbols

It should look like:

 

Output should look like:

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


Loading Dump File 
[C:\temp\051016-9562-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred srv*https://msdl.microsoft.com/download/symbols Symbol search path is: srv*https://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7601.23392.amd64fre.win7sp1_ldr.160317-0600 Machine Name: Kernel base = 0xfffff800`03055000 PsLoadedModuleList = 0xfffff800`03297730 Debug session time: Tue May 10 07:58:19.785 2016 (UTC + 2:00) System Uptime: 0 days 0:03:15.527 Loading Kernel Symbols . Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. .............................................................. ................................................................ ............................. Loading User Symbols Loading unloaded module list ............... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 3B, {c0000005, fffff800030f8171, fffff88008e64f90, 0} Probably caused by : memory_corruption ( nt!MiGetNextNode+15 ) Followup: MachineOwner ---------

Then, select File->Open Crash Dump or press CTRL+D

Select crash dump, usually located in C:\Windows\MiniDump or in other folder if debugging dumps from other computers.

 

Now, in analyzer window execute command:

!analyze -v

After a couple of seconds we should get output similiar to below:

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

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800030f8171, Address of the instruction which caused the bugcheck
Arg3: fffff88008e64f90, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instrukcja w 0x%p odwo

FAULTING_IP: 
nt!MiGetNextNode+15
fffff800`030f8171 48394808        cmp     qword ptr [rax+8],rcx

CONTEXT:  fffff88008e64f90 -- (.cxr 0xfffff88008e64f90;r)
rax=0000000000000000 rbx=fffffa8007c8a670 rcx=fffff68000000000
rdx=0000000001600000 rsi=fffffa8007ef1060 rdi=0000000000001600
rip=fffff800030f8171 rsp=fffff88008e65978 rbp=fffff88008e65b60
 r8=000000007ffdffff  r9=0000000000000011 r10=0000000000000008
r11=0000000000000000 r12=000000000176ca80 r13=fffffa8007280d28
r14=00000000000002f8 r15=0000000000000000
iopl=0         nv up ei pl nz na po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010207
nt!MiGetNextNode+0x15:
fffff800`030f8171 48394808        cmp     qword ptr [rax+8],rcx ds:002b:00000000`00000008=????????????????
Last set context:
rax=0000000000000000 rbx=fffffa8007c8a670 rcx=fffff68000000000
rdx=0000000001600000 rsi=fffffa8007ef1060 rdi=0000000000001600
rip=fffff800030f8171 rsp=fffff88008e65978 rbp=fffff88008e65b60
 r8=000000007ffdffff  r9=0000000000000011 r10=0000000000000008
r11=0000000000000000 r12=000000000176ca80 r13=fffffa8007280d28
r14=00000000000002f8 r15=0000000000000000
iopl=0         nv up ei pl nz na po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010207
nt!MiGetNextNode+0x15:
fffff800`030f8171 48394808        cmp     qword ptr [rax+8],rcx ds:002b:00000000`00000008=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  TeamViewer_Ser

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff800030f8171

STACK_TEXT:  
fffff880`08e65978 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MiGetNextNode+0x15


FOLLOWUP_IP: 
nt!MiGetNextNode+15
fffff800`030f8171 48394808        cmp     qword ptr [rax+8],rcx

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!MiGetNextNode+15

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  56eb24e6

IMAGE_VERSION:  6.1.7601.23392

STACK_COMMAND:  .cxr 0xfffff88008e64f90 ; kb

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0x3B_nt!MiGetNextNode+15

BUCKET_ID:  X64_0x3B_nt!MiGetNextNode+15

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:x64_0x3b_nt!migetnextnode+15

FAILURE_ID_HASH:  {032213de-b20c-8df8-d1d2-7fcaf6eaafe5}

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

As we can see in above example, driver fault related to TeamViewer Service caused blue screen. This still might be misleading, since it tells us what directly caused BSOD but didn’t tell us WHY. It would be possible when debugging full memory dump, looking at the related memory stack and loaded files but I think it is more kind of a art that really useful knowledge for most people. Of course people who really need that kind of a info already know how to use above tools, so in my opinion explaining it here is unnecessary. In this particular example driver fault might be related to either anti-virus blocking it or RAM error. I would check RAM, run chkdsk to check disk for errors and let anti-virus software to fully update assuming TeamViewer is in newest available version.