Crash Dump Analysis Patterns (Part 69b)

This pattern is a kernel mode counterpart to Self-Diagnosis in user mode. It is just a collection of bugcheck codes where a problem is usually detected before corruption causes a fault, exception or trap. Typical example would be a detection of a failed assertion or corrupt structures such as:

The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of the problem, and then special pool applied to the suspect tags or the driver verifier to a suspect driver.
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 8b79d078, The pool entry we were looking for within the page.
Arg3: 8b79d158, The next pool entry.
Arg4: 8a1c0004, (reserved)

More examples would be added in the forthcoming case studies.

- Dmitry Vostokov @ + -

2 Responses to “Crash Dump Analysis Patterns (Part 69b)”

  1. Dmitry Vostokov Says:

    Another example is this bugcheck:

    This bugcheck is generated when the kernel detects that critical kernel code or
    data have been corrupted. There are generally three causes for a corruption:
    1) A driver has inadvertently or deliberately modified critical kernel code
    or data. See
    2) A developer attempted to set a normal kernel breakpoint using a kernel
    debugger that was not attached when the system was booted. Normal breakpoints,
    “bp”, can only be set if the debugger is attached at boot time. Hardware
    breakpoints, “ba”, can be set at any time.
    3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
    Arg1: […], Reserved
    Arg2: […], Reserved
    Arg3: […], Failure type dependent information
    Arg4: 0000000000000002, Type of corrupted region, can be
    0 : A generic data region
    1 : Modification of a function or .pdata
    2 : A processor IDT
    3 : A processor GDT
    4 : Type 1 process list corruption
    5 : Type 2 process list corruption
    6 : Debug routine modification
    7 : Critical MSR modification

  2. Dmitry Vostokov Says:

    Another example:

    A kernel component has corrupted a critical data structure. The corruption
    could potentially allow a malicious user to gain control of this machine.
    Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
    Arg2: ffffd0002926ff90, Address of the trap frame for the exception that caused the bugcheck
    Arg3: ffffd0002926fee8, Address of the exception record for the exception that caused the bugcheck
    Arg4: 0000000000000000, Reserved

Leave a Reply

You must be logged in to post a comment.