Overview
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.
Details
Length: 5 days
Format: Lecture and Lab ONLINE ONLY
Cost: $4,455 (when paid 6 weeks in advance; $4,950 otherwise)
Other Applicable Discounts:
5% multi-student discount (paid online, same credit card, same order)
Contact OSR for previous student discounts
Current Schedule
ONLINE (content live-streamed via the Internet)
4-8 November 2024
9:00AM – 5:00PM EST (UTC-0500)
(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.
Prerequisites
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 have access to a lab/test system, 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: https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk. We recommend lab/test systems have a minimum of 20GB of free disk space (though this is not a requirement).
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 x64 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 x64 processor architecture, particularly focusing on those features that are used within Windows. The Application Binary Interface (ABI) used by Windows is also discussed, including the Home Space and Unwind Data and their use in debugging, - 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 bug check codes such as IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, and KERNEL_MODE_EXCEPTION_NOT_HANDLED. - 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. - 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.
OSR Open Systems Resources, Inc.