Windows System Software -- Consulting, Training, Development -- Engineering Excellence, Every Time.

Kernel Debugging and Crash Analysis for Windows

Register Now


When Windows detects an inconsistency within the operating system that’s too big to ignore, it crashes and displays the infamous Blue Screen of Death. Optionally, the system also writes the contents of memory at the time of the crash to a crash dump file.

The successful analysis of a crash dump requires a good background in Windows internals and data structures. But it also lends itself to a rigorous, methodical approach. Crash analysis is a skill that can be taught and learned. And that’s precisely what we do in this intensive 5-day, hands-on seminar.


Length: 5 days

Format: Lecture and Lab

Cost: $4,005 (when paid 6 weeks in advance; $4,450 otherwise)

Other Applicable Discounts: 
5% multi-student discount (paid online, same credit card, same order)
Contact OSR for previous student discounts

Current Schedule

15-19 November 2021
ONLINE (content live-streamed via the web!)
9:00AM – 5:00PM EST (UTC -0500hrs)

***Attention! As part of the continued impact of the COVID-19 virus, OSR is temporarily suspending all in-person offerings of this seminar. Thus, this seminar is currently available for REMOTE ATTTENDANCE ONLY.  See this blog post for more info on attending remotely.  Thank you for your understanding***

Register Now (Click Register Now to Register Online and pay via credit card; OR Register Offline Here)

Target Audience

Driver developers who need to understand how to set up for, use, and analyze OS crash dumps. Support personnel who need to know how to debug Windows system crashes in the lab or at customer sites, in situ or post mortem. Advanced, hands-on, systems administrators who are comfortable with Windows systems internals and need to be able to work through system crashes to identify the proximate reasons for the crashes they are seeing.


This is an intermediate-level seminar offering for active practitioners. This is not a class for beginners. All attendees are expected to understand operating system concepts in general, and the basic concepts of the Windows operating system. Attendees must have previous hands-on experience working with Windows, including some (moderate) applications or driver level development experience. It is a hands-on class intended to give students real, practical experience in using the Windows Debugger (WinDbg) and in understanding the data provided by the various kernel debugger extensions.

Hardware Requirement:  Students are expected to bring their own laptop, with a 32-bit or 64-bit version of WinDbg pre-installed and tested.  The most recent version of the Debugging Tools for Windows is distributed as part of the Windows SDK, and may be downloaded from here: — We recommend laptops have a minimum of 20GB of free space (though this is not a requirement).  If it is impossible for you to provide a suitable laptop, contact our seminar team to discuss your options.

Download the outline in PDF

Seminar Outline

  • Windows Operating System Architecture Overview
    A brief review of the general architecture of the Windows operating system, including topics most relevant to debugging.
  • Introduction to WinDbg
    WinDbg is the Windows Debugger, used primarily for kernel mode debugging although it also can be used to debug applications. This initial section describes the basics of the tool and provides some focused discussions on how to use it for kernel debugging. Note: the goal is not to provide a comprehensive overview of the tool. Students are referred to the WinDbg documentation for a thorough description of the abilities of this tool.
  • Overview of the x86 Processor
    Crashes aren’t random events, even though it might sometimes seem that way! In reality, a series of events occur on the processor that result in Windows deciding to crash the machine. In order to properly reconstruct the series of events leading up to the crash, we must have an understanding of the underlying processor architecture on which Windows is executing. In this section we discuss some basic characteristics of the x86 processor architecture, particularly focusing on those features that are used within Windows. The Application Binary Interface (ABI) used by Windows is also discussed, including calling conventions (CDECL, STDCALL, FASTCALL, and LTCG) and stay frame layouts (EBP and FPO).
  • Organizing Work
    During the normal course operation, the operating system must respond to various events that occur in the system. Some of these events are more important than others, so Windows needs a way to organize the priority of these events. In this section, we discuss the impact of Interrupt Request Levels (IRQLs) on the system and the rules that drivers must always follow. IRQL related system crashes are discussed.
  • Debugging Invalid Memory Access Problems
    No crash is more common in a Windows driver than one due to dereferencing a bad pointer, or referencing a “good” pointer at the wrong IRQL. In this module, we’ll discuss how Windows traps invalid memory references, and the specific differences between the bug check codes IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, and KERNEL_DATA_INPAGE_ERROR, with the goal of making it easier and faster to debug commonly encountered driver problems.
  • Overview of x64 Processor
    This section describes the basics of the x64 processor architecture. The processor architecture itself is a natural evolution from the x86, though the ABI has changed considerably. Windows uses of the Home Space and Unwind Data are discussed, as well as how the ABI can be leveraged in a debugging environment.
  • Windows Data Structures
    This section ties together specific Windows OS data structures together, providing students with a better understanding of how Windows works and then tying those data structures into the process the debugger uses for extracting information. The ultimate goal of this discussion is to further ground students so they can further hone their understanding and skills with the kernel debugger.
  • Fault Isolation
    Discussion of the process of isolating faults and attempting to find the “root cause”. This is a short section striving to tie together the concepts from previous modules as students continue to hone their debugging skills.
  • Handling Deadlock and Livelock
    Defining deadlock and livelock and examining their causes. Techniques for determining what is causing deadlock are discussed.
  • Advanced Debugger Usage
    Cover advanced WinDbg command line syntax, including discussions of the MASM and C++ expression evaluators, as well as the Debugger Object Model (DOM). The methods available for extending WinDbg are discussed, including Javascript and the Debugger Engine Library.
  • Testing and Debugging Best Practices
    A random collection of topics aimed at providing the students with practical, useful tools for streamlining their testing or debugging environments. Creation of Symbol and Source servers is discussed. Using KDFiles to automatically update the driver under test. Providing remote access to a kernel debug session.
  • Virtual Memory
    Most system crashes are software related. Even more so, most of these crashes are caused by some type of invalid memory reference. In order to understand how and why these crashes occur, a clear and complete understanding of the Virtual Memory subsystem is required. In this section students will be introduced to basic virtual memory concepts as well as Windows’ usage of virtual memory.
  • Demonstration (based upon time available)
    Students are invited to bring their own post-mortem or live system crashes for demonstrative analysis. If no student crashes are available, the instructor will have some post-mortem crashes to use for further demonstration.

Note: Individual lab sessions are not provided with any sort of “answer key”. Rather, at the completion of each lab session the instructor will do a live “walk through” of the lab exercise, demonstrating appropriate technique. Logs of those sessions will be taken at that time and made available to students. We do this because the tools are in a constant state of flux and this ensures we provide students with demonstrations that are appropriate to the current state of the tools.