This time I’m going to address something that most times is somewhat straight forward to analyze yet many people I deal with don´t know how to proceed when a blue screen appears. In this blog post I assume the server is already configured to generate kernel dumps or mini dumps. (this is something I always advice. Configure your servers to generate memory dumps if something goes wrong) Usually I get emails like “my server just got a BSOD (blue screen of death). I´ve got a minidump and I need to understand what happened”. My approach is always the same (and most of the times it is enough to find the root cause). First Step
Open windbg and make sure the symbol server is properly configured – more info at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx Second Step
Open the memory dump on windbg. Below is the output when opening a kernel memory dump (…)
Loading Kernel Symbols
...............................................................
................................................................
......................
Loading User Symbols
Loading unloaded module list
....................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 50, {d44cdde4, 0, 818ed8b3, 0}
(…) As you can see above the debuggers states “Use !analyze –v to get detailed debugging information”. Let’s follow the expert J (the debugger) and issue !analyze –v 1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: d44cdde4, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 818ed8b3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Read more: Deviations
Open windbg and make sure the symbol server is properly configured – more info at http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx Second Step
Open the memory dump on windbg. Below is the output when opening a kernel memory dump (…)
Loading Kernel Symbols
...............................................................
................................................................
......................
Loading User Symbols
Loading unloaded module list
....................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 50, {d44cdde4, 0, 818ed8b3, 0}
(…) As you can see above the debuggers states “Use !analyze –v to get detailed debugging information”. Let’s follow the expert J (the debugger) and issue !analyze –v 1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: d44cdde4, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 818ed8b3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Read more: Deviations
0 comments:
Post a Comment