BugChecks and what to do about them:

Bugchecks with no descriptions are either checked builds
only or very rare.  If you get one of these and a kernel
debugger is available do the following
    kb
    !process 0 7
    !vm
    !errlog

APC_INDEX_MISMATCH               (0x1)
This is a kernel internal error which can occur on a checked build.
The most common reason to see such a bugcheck would occur when a
filesystem had a mismatched number of KeEnterCriticalRegion calls compared
to KeLeaveCriticalRegion calls.

DEVICE_QUEUE_NOT_BUSY            (0x2)

INVALID_AFFINITY_SET             (0x3)

INVALID_DATA_ACCESS_TRAP         (0x4)

INVALID_PROCESS_ATTACH_ATTEMPT   (0x5)

INVALID_PROCESS_DETACH_ATTEMPT   (0x6)

INVALID_SOFTWARE_INTERRUPT       (0x7)

IRQL_NOT_DISPATCH_LEVEL          (0x8)

IRQL_NOT_GREATER_OR_EQUAL        (0x9)

IRQL_NOT_LESS_OR_EQUAL           (0xA)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
        4 - address which referenced memory

An attempt was made to touch pagable memory at a process
internal request level (IRQL) too high.  This is usually
caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.


NO_EXCEPTION_HANDLING_SUPPORT    (0xB)

MAXIMUM_WAIT_OBJECTS_EXCEEDED    (0xC)

MUTEX_LEVEL_NUMBER_VIOLATION     (0xD)
    1 - The current thread's mutex level
    2 - The mutex level that we are attempting to acquire

Try to identify the mutexes using the ntos\ex\exlevels.h header file. This
usually will pinpoint the mutexes that are getting acquired in an incorrect
sequence.

NO_USER_MODE_CONTEXT             (0xE)

SPIN_LOCK_ALREADY_OWNED          (0xF)

SPIN_LOCK_NOT_OWNED              (0x10)

THREAD_NOT_MUTEX_OWNER           (0x11)

TRAP_CAUSE_UNKNOWN               (0x12)

EMPTY_THREAD_REAPER_LIST         (0x13)

CREATE_DELETE_LOCK_NOT_LOCKED    (0x14)

LAST_CHANCE_CALLED_FROM_KMODE    (0x15)

CID_HANDLE_CREATION              (0x16)

CID_HANDLE_DELETION              (0x17)

REFERENCE_BY_POINTER             (0x18)

BAD_POOL_HEADER                  (0x19)

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.

    3 - the pool freelist is corrupt.  parameter 2 is the pool entry being
        checked, 4/5 are the read back flink/blink freelist values.  The values
        are supposed to be the same parameter 2.

    5 - the adjacent pool block headers are corrupt.  parameter 2 and 4 are
        the entries whose headers are not consistent.  parameter 3 is the line
        number inside pool.c (generally not useful).

MEMORY_MANAGEMENT                (0x1A)

    #n, where # denotes the bugcheck parameter

    #1 - The subtype of the bugcheck:

            1 - The fork clone block reference count is corrupt.  Only occurs
                on checked builds.

    # Any other values for parameter 1 must be individually examined.

PFN_SHARE_COUNT                  (0x1B)

PFN_REFERENCE_COUNT              (0x1C)

NO_SPIN_LOCK_AVAILABLE           (0x1D)

KMODE_EXCEPTION_NOT_HANDLED      (0x1E)
    1 - The exception code that was not handled
    2 - The address that the exception occured at
    3 - Parameter 0 of the exception
    4 - Parameter 1 of the exception

This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This should not happen, but I am positive you will see this.
If it happens repeatedly, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.

On MIPs systems if the address of the exception is 0XBFC0304, then bugcheck is
the result of a cache parity error on the CPU.  If the problem reoccurs
frequently, the hardware manufactor should be contacted.

SHARED_RESOURCE_CONV_ERROR       (0x1F)

KERNEL_APC_PENDING_DURING_EXIT   (0x20)
    1 - The address of the APC found pending during exit.
    2 - The thread's APC disable count
    3 - The current IRQL

The key data items are the thread's APC disable count.
If this is non-zero, then this is the source of the problem.
A negative value indicates that a filesystem has called
FsRtlEnterFileSystem more than FsRtlExitFileSystem.  A positive value
indicates that the reverse is true.  If you ever see this, be very very
suspicious of all file systems installed on the machine.  Third party
redirectors (like Novell) are especially suspicious since they do not
receive the heavy duty testing that NTFS, FAT, HPFS, and RDR receive.

This current IRQL should also be 0.  If it is not, that a driver's
cancelation routine can cause this bugcheck by returning at an elevated
IRQL.  Always attempt to not what the customer was doing/closing at the
time of the crash, and note all of the installed drivers at the time of
the crash.  This symptom is usually a severe bug in a third party
driver.

QUOTA_UNDERFLOW                  (0x21)

FILE_SYSTEM                      (0x22)

FAT_FILE_SYSTEM                  (0x23)
    All file system bug checks have encoded in their first ULONG
    the source file and the line within the source file that generated
    the bugcheck.  The high 16-bits contains a number to identify the
    file and low 16-bits is the source line within the file where
    the bug check call occurs.  For example, 0x00020009 indicates
    that the FAT file system bugcheck occurred in source file #2 and
    line #9.

    The file system calls bug check in multiple places and this will
    help us identify the actual source line that generated the bug
    check.  The only thing that can be done right now is to collect
    any bug check information in a database and pass on the output
    to a developer who can look in the sources and hopefully identify
    the cause of the bug check.

NTFS_FILE_SYSTEM                 (0x24)
    See the comment for FAT_FILE_SYSTEM
    If you see NtfsExceptionFilter on the stack then the 2nd and 3rd parameters are the
    exception record and context record. Do a !cxr on the 3rd parameter and then !kb to
    obtain a more informative stack trace.


NPFS_FILE_SYSTEM                 (0x25)
    See the comment for FAT_FILE_SYSTEM

CDFS_FILE_SYSTEM                 (0x26)
    See the comment for FAT_FILE_SYSTEM

RDR_FILE_SYSTEM                  (0x27)

CORRUPT_ACCESS_TOKEN             (0x28)

SECURITY_SYSTEM                  (0x29)

INCONSISTENT_IRP                 (0x2A)
    1 - Address of the IRP that was found to be inconsistent

An IRP was encountered that was in an inconsistent state; i.e., some field
or fields of the IRP were inconsistent w/the remaining state of the IRP.
An example would be an IRP that was being completed, but was still marked
as being queued to a driver's device queue.  This bugcheck code is not
currently being used in the system, but exists for debugging purposes.

PANIC_STACK_SWITCH               (0x2B)
This error indicates that the kernel mode stack was overrun. This normally
occurs when a kernel-mode driver uses too much stack space.  It can also
occur when serious data corruption occurs in the kernel.

PORT_DRIVER_INTERNAL             (0x2C)

SCSI_DISK_DRIVER_INTERNAL        (0x2D)

DATA_BUS_ERROR                   (0x2E)
This bugcheck is normally caused by a parity error in the system memory.
        1. Virtual address that caused the fault
        2. Physical address that caused
        3. Processor status register (PSR)
        4. Faulting instruction register (FIR)
This error can also be caused by a driver accessing a 0x8XXXXXXX address
that does not exist.

INSTRUCTION_BUS_ERROR            (0x2F)

SET_OF_INVALID_CONTEXT           (0x30)

PHASE0_INITIALIZATION_FAILED     (0x31)

    System init failed early on.  Debugger is required to make sense of this
    since the bugcheck tells you almost nothing.

PHASE1_INITIALIZATION_FAILED     (0x32)
    1 - NT Status code that describes why the system thinks initialization failed.
    2 - Indicates location within init.c where phase 1 initialization failure occured

UNEXPECTED_INITIALIZATION_CALL   (0x33)

CACHE_MANAGER                    (0x34)
    See the comment for FAT_FILE_SYSTEM

NO_MORE_IRP_STACK_LOCATIONS      (0x35)
    1 - Address of the IRP

A higher level driver has attempted to call a lower level driver through
the IoCallDriver() interface, but there are no more stack locations in the
packet, hence, the lower level driver would not be able to access its
parameters, as there are no parameters for it.  This is a disasterous
situation, since the higher level driver "thinks" it has filled in the
parameters for the lower level driver (something it MUST do before it calls
it), but since there is no stack location for the latter driver, the former
has written off of the end of the packet.  This means that some other memory
has probably been trashed at this point.

DEVICE_REFERENCE_COUNT_NOT_ZERO  (0x36)
    1 - Address of the device object

A device driver has attempted to delete one of its device objects from the
system but the reference count for that object was non-zero, meaning that
there are still outstanding references to the device.  (The reference count
indicates the number of reasons why this device object cannot be deleted.)
This is a bug in the calling device driver.

FLOPPY_INTERNAL_ERROR            (0x37)

SERIAL_DRIVER_INTERNAL           (0x38)

SYSTEM_EXIT_OWNED_MUTEX          (0x39)

SYSTEM_UNWIND_PREVIOUS_USER      (0x3A)

SYSTEM_SERVICE_EXCEPTION         (0x3B)

INTERRUPT_UNWIND_ATTEMPTED       (0x3C)

INTERRUPT_EXCEPTION_NOT_HANDLED  (0x3D)

MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED (0x3E)
The system has multiple processors, but they are asymmetric in relation
to one another.  In order to be symmetric all processors must be of
the same type and level.  For example, trying to mix a Pentium level
processor with an 80486 would cause this bugcheck.  Additionally, on x86
systems all processors must either have floating point capabilities, or
none should.


NO_MORE_SYSTEM_PTES              (0x3F)
        1 - PTE Type (0 - system expansion, 1 nonpaged pool expansion)
        2 - Requested size
        3 - Total free system PTEs
        4 - Total system PTEs

No System PTEs left.  Usually caused by a driver not cleaning up
properly.  If kernel debugger available get stack trace and
"!sysptes 3".

Set HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Mamagement\TrackPtes to a DWORD 1 value and reboot.  Then the system will save stack traces
so the guilty driver can be identified.  There is no other way to find out
which driver is neglecting to clean up the I/Os.  A bugcheck DRIVER_USED_EXCESSIVE_PTES will then occur if the system runs out of PTEs again and the offending
driver's name will be printed.

TARGET_MDL_TOO_SMALL             (0x40)

A driver has called the IoBuildPartialMdl() function and passed it an MDL
to map part of a source MDL, but the target MDL is not large enough to map
the entire range of addresses requested.  This is a driver bug.  The source
and target MDLs, as well as the address range length to be mapped are the
arguments to the IoBuildPartialMdl() function, i.e.;

    IoBuildPartialMdl(
        IN PMDL SourceMdl,
        IN OUT PMDL TargetMdl,
        IN PVOID VirtualAddress,
        IN ULONG Length
        )

MUST_SUCCEED_POOL_EMPTY          (0x41)

        1 - size of the request that could not be satisfied
        2 - number of pages used of nonpaged pool
        3 - number of > PAGE_SIZE requests from nonpaged pool
        4 - number of pages available

If debugger available, !vm command lists various sizes.  Then do !poolused 2.

ATDISK_DRIVER_INTERNAL           (0x42)

NO_SUCH_PARTITION                (0x43)

MULTIPLE_IRP_COMPLETE_REQUESTS   (0x44)
    1 - Address of the IRP

A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.  This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened.  Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it.  The
first actually works, and the second fails.  Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second.  However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.

INSUFFICIENT_SYSTEM_MAP_REGS     (0x45)

DEREF_UNKNOWN_LOGON_SESSION      (0x46)

REF_UNKNOWN_LOGON_SESSION        (0x47)

CANCEL_STATE_IN_COMPLETED_IRP    (0x48)
    1 - Pointer to the IRP

This bugcheck indicates that an I/O Request Packet (IRP) that is to be
cancelled, has a cancel routine specified in it -- meaning that the packet
is in a state in which the packet can be cancelled -- however, the packet
no longer belongs to a driver, as it has entered I/O completion.  This is
either a driver bug, or more than one driver is accessing the same packet,
which is not likely and much more difficult to find.

PAGE_FAULT_WITH_INTERRUPTS_OFF   (0x49)

    Means exactly what it says, treat it as a case of 0x0A above.

IRQL_GT_ZERO_AT_SYSTEM_SERVICE   (0x4A)

STREAMS_INTERNAL_ERROR           (0x4B)

FATAL_UNHANDLED_HARD_ERROR       (0x4C)

If a hard error occurs during system booting before windows is up, and
the hard error is a real error, the system will blue screen crash.

Some common cases are:

    x218 - This means a necessary registry hive file could not be
           loaded.  The obvious reason is if it is corrupt or missing.
           In this case, either the Emergency Repair Disk or a
           reinstall is required.

           Some less obvious reasons are that the driver has corrupted
           the registry data while loading into memory, or the memory
           where the registry file was loaded is not actually memory.
           In particular, AST EISA machines with 16MB or more of memory
           must have access to the memory above 16MB ENABLED in the
           Eisa Config Utility, or else a registry file is liable to get
           loaded in this spot, but will return just 0xffffffff when
           we look at the memory.

    x21a - This means that either winlogon, or csrss (windows) died
           unexpectedly.  The exit code tells more information.  Usually
           it is c0000005 meaning that an unhandled exception crashed
           either of these processes.  There is not much you can do
           unless this becomes a persistent problem.

    x221 - This means that a driver is corrupt, or a system DLL was
           detected to be corrupt.  We do our best to integrety check
           drivers and important system DLLs, and if they are corrupt,
           the blue screen the name of the corrupt file.  This prevents
           crashes from occuring when we stumble into the corruption
           later.  Boot an alternate OS, or reinstall if no alternate
           exists.  Make sure the on disk file that is listed as bad
           matches the version on CD and replace if necessary.  In some
           cases, random corruption can mean that there is a hardware
           problem in our I/O path to the file.

NO_PAGES_AVAILABLE               (0x4D)
        1 - Total number of dirty pages
        2 - Number of dirty pages destined for the pagefile(s).
        3 - Nonpaged pool available at time of bugcheck (in pages).
        4 - Number of transition pages that are currently stranded.

No free pages available to continue operations.
If kernel debugger available "!vm" followed by "!poolused 2" and "!process 8 7"

        This bugcheck can occur for the following reasons:

        1.  A driver has blocked, deadlocking the modified or mapped
            page writers.  Examples of this include mutex deadlocks or
            accesses to paged out memory in filesystem drivers, filter
            drivers, etc.  This indicates a driver bug.

            If parameter 1 or 2 is large, then this is a possibility.  Type
            "!process 8 7" in the kernel debugger.
    
        2.  The storage driver(s) are not processing requests.  Examples
            of this are stranded queues, non-responding drives, etc.  This
            indicates a driver bug.
    
            If parameter 1 or 2 is large, then this is a possibility.  Type
            "!process 8 7" in the kernel debugger.
    
        3.  Not enough pool is available for the storage stack to write out
            modified pages.  This indicates a driver bug.
    
            If parameter 3 is small, then this is a possibility.  Type
            "!vm" and "!poolused 2" in the kernel debugger.
    
        4.  A high priority realtime thread has starved the balance set
            manager from trimming pages and/or starved the modified writer
            from writing them out.  This indicates a bug in the component
            that created this thread.

            This one is hard to determine, try "!ready"
    
        5.  All the processes have been trimmed to their minimums and all
            modified pages written, but still no memory is available.  The
            freed memory must be stuck in transition pages with non-zero
            reference counts - thus they cannot be put on the freelist.
            A driver is neglecting to unlock the pages preventing the
            reference counts from going to zero which would free the pages.
            This may be due to transfers that never finish and the driver
            never aborts or other driver bugs.

            If parameter 4 is large, then this is a possibility.  But it
            is very hard to find the driver.  Try "!process 0 1" and look
            for any that have a lot of locked pages.
    
PFN_LIST_CORRUPT                 (0x4E)
        1 - value 1
        2 - ListHead value which was corrupt
        3 - number of pages available
        4 - 0

        1 - value 2
        2 - entry in list being removed
        3 - highest physical page number
        4 - reference count of entry being removed

Caused by corrupting I/O driver structures.  If kernel debugger
available get stack trace.


NDIS_INTERNAL_ERROR              (0x4F)

PAGE_FAULT_IN_NONPAGED_AREA      (0x50)
        1 - memory referenced.
        2 - value 0 = read operation, 1 = write operation.
        3 - If non-zero, the instruction address which referenced the bad memory
            address.
        4 - Mm internal code.

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.

REGISTRY_ERROR                   (0x51)
        1 - value 1 (indicates where we bugchecked)
        2 - value 2 (indicates where we bugchecked)
        3 - depends on where it bugchecked, may be pointer to hive
        4 - depends on where it bugchecked, may be return code of
            HvCheckHive if the hive is corrupt.

Something has gone horribly wrong with the registry.  If a kernel debugger
is available, get a stack trace.

If the stack trace indicates we are in a system worker thread (CmpWorker
will be on the call list) do the following kernel debugger commands:

    dd CmpRegistryMutex+18 L1
    !thread <whatever value the above command printed out>

This will give you the thread and stacktrace that made the registry call.

It can also indicate that the registry got an I/O error while trying to
read one of its files, so it can be caused by hardware problems or
filesystem corruption.

It may occur due to a failure in a refresh operation, which is used only
in by the security system, and then only when resource limits are encountered.
When you see this bugcode, be sure to ask if the machine is a PDC or BDC,
and how many accounts are in its sam, whether it might be a replication target,
and whether the volume where the hive files reside is nearly full.

MAILSLOT_FILE_SYSTEM             (0x52)

NO_BOOT_DEVICE                   (0x53)

LM_SERVER_INTERNAL_ERROR         (0x54)

DATA_COHERENCY_EXCEPTION         (0x55)

INSTRUCTION_COHERENCY_EXCEPTION  (0x56)

XNS_INTERNAL_ERROR               (0x57)

FTDISK_INTERNAL_ERROR            (0x58)

The system was booted from a revived primary partition so
the hives say the mirror is ok, when in fact it is not.
The "real" image of the hives are on the shadow.
The user must boot from the shadow.

PINBALL_FILE_SYSTEM              (0x59)
    See the comment for FAT_FILE_SYSTEM

CRITICAL_SERVICE_FAILED          (0x5A)

SET_ENV_VAR_FAILED               (0x5B)

HAL_INITIALIZATION_FAILED        (0x5C)

UNSUPPORTED_PROCESSOR            (0x5D)
    386 - System failed because the processor is only a 386 or
    compatible.  The system requires a 486 compatible or better processor.

HEAP_INITIALIZATION_FAILED       (0x5D)

OBJECT_INITIALIZATION_FAILED     (0x5E)

SECURITY_INITIALIZATION_FAILED   (0x5F)

PROCESS_INITIALIZATION_FAILED    (0x60)

HAL1_INITIALIZATION_FAILED       (0x61)

OBJECT1_INITIALIZATION_FAILED    (0x62)

SECURITY1_INITIALIZATION_FAILED  (0x63)

SYMBOLIC_INITIALIZATION_FAILED   (0x64)

MEMORY1_INITIALIZATION_FAILED    (0x65)

CACHE_INITIALIZATION_FAILED      (0x66)

CONFIG_INITIALIZATION_FAILED     (0x67)
    1 - 5
    2 - indicates location in ntos\config\cmsysini that failed

This means the registry couldn't allocate the pool needed to contain the
registry files.  This should never happen, since it is early enough in
system initialization that there is always plenty of paged pool available.

FILE_INITIALIZATION_FAILED       (0x68)

IO1_INITIALIZATION_FAILED        (0x69)

Initialization of the I/O system failed for some reason.  There is
practically no other information available.  In general, setup really made
some bad decisions about the installation of the system, or the user has
reconfigured the system.

LPC_INITIALIZATION_FAILED        (0x6A)

PROCESS1_INITIALIZATION_FAILED   (0x6B)
    1 - Indicates the status code that tripped us into thinking that
        initialization failed.
    2 - Indicates the location in ntos\ps\psinit.c where the failure
        was detected.

REFMON_INITIALIZATION_FAILED     (0x6C)

SESSION1_INITIALIZATION_FAILED   (0x6D)
    1 - Indicates the NT status code that tripped us into thinking
        that initialization failed.

The bugcheck code (SESSION1 - SESSION5) indicates the location in
ntos\init\init.c where the failure was detected.

SESSION2_INITIALIZATION_FAILED   (0x6E)
    1 - Indicates the NT status code that tripped us into thinking
        that initialization failed.

The bugcheck code (SESSION1 - SESSION5) indicates the location in
ntos\init\init.c where the failure was detected.

SESSION3_INITIALIZATION_FAILED   (0x6F)
    1 - Indicates the NT status code that tripped us into thinking
        that initialization failed.

The bugcheck code (SESSION1 - SESSION5) indicates the location in
ntos\init\init.c where the failure was detected.

SESSION4_INITIALIZATION_FAILED   (0x70)
    1 - Indicates the NT status code that tripped us into thinking
        that initialization failed.

The bugcheck code (SESSION1 - SESSION5) indicates the location in
ntos\init\init.c where the failure was detected.

SESSION5_INITIALIZATION_FAILED   (0x71)
    1 - Indicates the NT status code that tripped us into thinking
        that initialization failed.

The bugcheck code (SESSION1 - SESSION5) indicates the location in
ntos\init\init.c where the failure was detected.

ASSIGN_DRIVE_LETTERS_FAILED      (0x72)

CONFIG_LIST_FAILED               (0x73)

        1 - 5
        2 - 2
        3 - index of hive in list
        4 - pointer to UNICODE_STRING containing filename of hive

Indicates that one of the core system hives is corrupt or
unreadable.  This can be either SOFTWARE, SECURITY or SAM.

BAD_SYSTEM_CONFIG_INFO           (0x74)

Can indicate that the SYSTEM hive loaded by the osloader/NTLDR
was corrupt.  This is unlikely, since the osloader will check
a hive to make sure it isn't corrupt after loading it.

It can also indicate that some critical registry keys and values
are not present.  (i.e. somebody used regedt32 to delete something
that they shouldn't have)  Booting from LastKnownGood may fix
the problem, but if someone is persistent enough in mucking with
the registry they will need to reinstall or use the Emergency
Repair Disk.

CANNOT_WRITE_CONFIGURATION       (0x75)

This will result if the SYSTEM hive files (SYSTEM and SYSTEM.ALT)
cannot be grown to accomodate additional data written into it
between registry initialization and phase one initialization
(when the filesystems are available)

It usually means there are 0 bytes of free space available on the
drive.

You cannot store the registry on a read-only device.

PROCESS_HAS_LOCKED_PAGES         (0x76)
        1 - 0
        2 - process address
        3 - number of locked pages
        4 - pointer to driver stacks (if enabled) or 0 if not.

Caused by a driver not cleaning up completely after an I/O.  Set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\TrackLockedPages to a DWORD 1 value and reboot.  Then the system will save stack traces
so the guilty driver can be identified.  There is no other way to find out
which driver is neglecting to clean up the I/Os.  When you enable this flag,
if the driver commits the error again you will see a different
bugcheck - DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS - which can identify the
offending driver(s).

KERNEL_STACK_INPAGE_ERROR        (0x77)
        1 - 0 (page was retrieved from page cache)
        2 - value found in stack where signature should be
        3 - 0
        4 - address of signature on kernel stack

        1 - 1 (page was retrieved from disk)
        2 - value found in stack where signature should be
        3 - 0
        4 - address of signature on kernel stack

        1 - 2 (page was retrieved from disk, storage stack returned SUCCESS,
            but the Status.Information != PAGE_SIZE)
        2 - value found in stack where signature should be
        3 - 0
        4 - address of signature on kernel stack

        1 - status code
        2 - i/o status code
        3 - page file number
        4 - offset into page file

The requested page of kernel data could not be read in.  Caused by
bad block in paging file or disk controller error.

This can also be caused by running out of resources, specifically,
nonpaged pool with status of c0000009a (STATUS_INSUFFICIENT_RESOURCES).
In this case, do !vm to see which pool has been overused, and then do
!poolused x to sort the pool allocators.  Then give the failure to the
component that has the most pool.

In the case when the first and second arguments are 0, the stack signature
in the kernel stack was not found.  Again, bad hardware.

An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED)  normally indicates
the data could not be read from the disk due to a bad
block.  Upon reboot autocheck willl run and attempt to map out the bad
sector.  If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked.  See the knowledge base article on SCSI termination.

PHASE0_EXCEPTION                 (0x78)

MISMATCHED_HAL                   (0x79)
    1 - type of mismatch
        type 1:
            The PRCB release levels mismatch.  (something is out of date)
            2 - Major PRCB level of ntoskrnl.exe
            3 - Major PRCB level of hal.dll

        type 2:
            The build types mismatch.
            2 - Build type of ntoskrnl.exe
            3 - Build type of hal.dll

                Build type
                    0 = Free multiprocessor enabled build
                    1 = Checked multiprocessor enabled build
                    2 = Free uniprocessor build

        type 3:
            Microchannel computers require a micro-channel specific hal.
            This type would means that there is a mis-match.
            2 - Machine type as detected by ntdetect.com
                A value of a 2 would mean the computer is MCA
            3 - Machine type which hal supports:
                A value of a 2 would mean the hal is built for MCA

The HAL revision level and HAL configuration type does not match that
of the kernel or the machine type.  This would probably happen if the
user has manually updated either ntoskrnl.exe or hal.dll and managed to
get a conflict.

You have an MP (multi-processor) Hal and a UP (uni-processor) Kernel,
or the reverse.



KERNEL_DATA_INPAGE_ERROR         (0x7A)
        1 - lock type that was held (value 1,2,3, or PTE address)
        2 - error status (normally i/o status code)
        3 - current process (virtual address for lock type 3, or PTE)
        4 - virtual address that could not be in-paged

The requested page of kernel data could not be read in.  Caused by
bad block in paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.

If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
ntmsd is the best alias to take care of these types of failures.

If the error status is 0xC000009A, then it means the request failed because
memory could not be allocated.  Type !vm and then !poolused 2 in the kernel
debugger to find which tags are leaking memory and then have the owning driver
fix their leaks.




INACCESSIBLE_BOOT_DEVICE         (0x7B)
    1 - Pointer to the device object or Unicode string of ARC name

During the initialization of the I/O system, it is possible that the driver
for the boot device failed to initialize the device that the system is
attempting to boot from, or it is possible for the file system that is
supposed to read that device to either fail its initialization or to simply
not recognize the data on the boot device as a file system structure that
it recognizes.  In the former case, the argument (#1) is the address of a
Unicode string data structure that is the ARC name of the device from which
the boot was being attempted.  In the latter case, the argument (#1) is the
address of the device object that could not be mounted.

If this is the initial setup of the system, then this error can occur if
the system was installed on an unsupported disk or SCSI controller.  Note
that some controllers are supported only by drivers which are in the Windows
Driver Library (WDL) which requires the user to do a custom install.  See
the Windows Driver Library for more information.

This error can also be caused by the installation of a new SCSI adapter or
disk controller or repartitioning the disk with the system partition.  If
this is the case, on x86 systems the boot.ini file must be edited or on ARC
systems setup must be run.  See the "Advanced Server System Administrator's
User Guide" for information on changing boot.ini.

If the argument is a pointer to an ARC name string, then the format of the
first two (and in this case only) longwords will be:

    USHORT Length;
    USHORT MaximumLength;
    PVOID Buffer;

That is, the first longword will contain something like 00800020 where 20
is the actual length of the Unicode string, and the next longword will
contain the address of buffer.  This address will be in system space, so
the high order bit will be set.

If the argument is a pointer to a device object, then the format of the first
word will be:

    USHORT Type;

That is, the first word will contain a 0003, where the Type code will ALWAYS
be 0003.

Note that this makes it immediately obvious whether the argument is a pointer
to an ARC name string or a device object, since a Unicode string can never
have an odd number of bytes, and a device object will always have a Type
code of 3.

BUGCODE_PSS_MESSAGE              (0x7C)

INSTALL_MORE_MEMORY              (0x7D)
        1 - Number of physical pages found
        2 - Lowest physical page
        3 - Highest physical page
        4 - 0

Not enough memory to boot NT (needs 5mb).

WINDOWS_NT_BANNER                (0x4000007E)

UNEXPECTED_KERNEL_MODE_TRAP      (0x7F)

This means a trap occured in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck parens is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are.

A kb and !trap on the appropriate frame (which will be the ebp that
goes with a procedure named KiTrap...) (at least on x86) will
show where the trap was taken.


NMI_HARDWARE_FAILURE             (0x80)

Hopefully MS PSS will never hear about this.  The HAL is supposed
to report whatever specific data it has, and to tell the user to
call their HARDWARE vendor for support.

SPIN_LOCK_INIT_FAILURE           (0x81)

DFS_FILE_SYSTEM                  (0x82)

SETUP_FAILURE                    (0x85)

(NOTE:  Textmode setup no longer uses bugchecks to bail out of serious
error conditions.  Therefore, you will never encounter a bugcheck 0x85.
All bugchecks have been replaced with friendlier and (where possible)
more descriptive error messages.  Some of the former bugchecks, however,
have simply been replaced by our own bugcheck screen, and the codes for
these error conditions are the same as before.  These are documented below.)

The first extended bugcheck field is a code indicating what the
problem is, and the other fields are used differently depending on
that value.

    1 -
        0:  The oem hal font is not a valid .fon format file, and so setup
            is unable to display text.
            This indicates that vgaxxx.fon on the boot floppy or CD-ROM
            is damaged.

        1:  Video initialization failed.  NO LONGER A BUGCHECK CODE.
            This error now has its own error screen, and the user is only
            presented with the two relevant parameters detailed below.

            This may indicate that the disk containing vga.sys
            (or other video driver appropriate to the machine)
            is damaged or that machine has video hardware that
            we cannot communicate with.

            2 - What failed:
                0: NtCreateFile of \device\video0
                1: IOCTL_VIDEO_QUERY_NUM_AVAIL_MODES
                2: IOCTL_VIDEO_QUERY_AVAIL_MODES
                3: Desired video mode not supported.  This is indicative of
                   an internal setup error.
                4: IOCTL_VIDEO_SET_CURRENT_MODE (unable to set video mode)
                5: IOCTL_VIDEO_MAP_VIDEO_MEMORY
                6: IOCTL_VIDEO_LOAD_AND_SET_FONT

            3 - Status code from NT API call, if appropriate.

        2:  Out of memory.  NO LONGER A BUGCHECK CODE.
            This error now uses a more friendly error screen that works regardless
            of how far along in setup we are.

        3:  Keyboard initialization failed.  NO LONGER A BUGCHECK CODE.
            There are now 2 error screens for the two different possible errors
            we can get here.
            This may indicate that the disk containing the keyboard driver
            (i8042prt.sys or kbdclass.sys) is damaged or that machine has
            keyboard hardware we cannot communicate with.

            It may also mean that the keyboard layout dll could not be loaded.

            2 - What failed:
                0: NtCreateFile of \device\KeyboardClass0 failed.
                   "Setup did not find a keyboard connected to your computer."
                1: Unable to load keyboard layout dll.
                   "Setup could not load the keyboard layout file <filename>."
                   Indicates that the cd or floppy is missing a file (kbdus.dll
                   for us release, other layout dlls for localized ones).

        4:  Setup was unable to resolve the ARC device pathname of
            the device from which setup was started. This is an internal
            Setup error.

        5:  Partitioning sanity check failed.  This indicates a bug in
            a disk driver.  The parameters are meaningful only to the setup
            group.

MBR_CHECKSUM_MISMATCH            (0x8B)

This message occurs during the boot process when the MBR checksum the system
calculates does not match the checksum passed in by the loader. This is usually
an indication of a virus. There are many forms of viruses and not all can be
detected. The newer ones usually can only be detected by a virus scanner that
has recently been upgraded. Boot a write-protected disk containing a virus
scanner and attempt to clean out the infection.

KerBugCheckEx parameters:

    1 - Disk Signature from MBR.
    2 - MBR checksum calculated by osloader.
    3 - MBR checksum calculated by system.

PP0_INITIALIZATION_FAILED        (0x8F)

This message occurs if phase 0 initialization of the kernel-mode Plug and
Play Manager failed.  There's really nothing going on here that could cause
a failure.

PP1_INITIALIZATION_FAILED        (0x90)

This message occurs if phase 1 initialization of the kernel-mode Plug and
Play Manager failed.  This is where we do most of our initialization,
including setting up the environment (registry, etc.) for drivers to
subsequently call during I/O init.


UP_DRIVER_ON_MP_SYSTEM           (0x92)

This message occurs if a UNIPROCESSOR only driver is loaded on a MultiProcessor
system with more than one active processor.

KeBugCheckEx parameters:

    1 - The Base address of the driver.

INVALID_KERNEL_HANDLE           (0x93)

This message occurs if kernel code (server, redirector, other driver, etc.) attempts
to close a handle that is not a valid handle.

    1 - The handle that NtClose was called with.

    2 - 0 means a protected handle was closed.
        1 means an invalid handle was closed.

KERNEL_STACK_LOCKED_AT_EXIT     (0x94)

This message occurs when a thread exits while it's kernel stack is
marked as not swapable

INVALID_WORK_QUEUE_ITEM         (0x96)

This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null.  This is almost always called by code misusing
worker thread work items, but any queue misuse can caus this.  The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink field
is NULL. In order to debug this problem, you need to know the queue being referenced.
If the queue is one of the EX worker queues (ExWorkerQueue), then the item being
removed is a WORK_QUEUE_ITEM (see ex.h). This bugcheck assumes that this is the case.
The bugcheck ex parameters are designed to help identify the driver misusing the queue
item.

BOUND_IMAGE_UNSUPPORTED         (0x97)

MmLoadSystemImage was called to load a bound image.
This is not supported in the kernel.  Make sure bind.exe was not run on the
image.


KeBugCheckEx parameters:

    1 - The address of the queue entry whose flink/blink field is NULL
    2 - The address of the queue being references. Usually this is one
        of the ExWorkerQueues.
    3 - The base address of the ExWorkerQueue array. This will help determine if
        the queue in question is an ExWorkerQueue and if so, the offset from this
        parameter will isolate the queue.
    4 - If this is an ExWorkerQueue (which it usually is), this is the address of the
        worker routine that would have been called if the work item was valid. This
        can be used to isolate the driver that is misusing the work queue.


END_OF_NT_EVALUATION_PERIOD     (0x98)

Your NT System is an evaluation unit with an expiration date. The trial period is over.

KeBugCheckEx parameters:

    1 - The low order 32 bits of your instalation date
    2 - The high order 32 bits of your instalation date
    3 - The trial period in minutes

INVALID_REGION_OR_SEGMENT       (0x99)

ExInitializeRegion or ExInterlockedExtendRegion was called with an invalid
set of parameters.

SYSTEM_LICENSE_VIOLATION        (x9a)

A violation of the software license agreement has occurred. This can be due to either
attempting to change the product type of an offline system, or an attempt to change
the trial period of an evaluation unit of NT.

    1 - 0 means that offline product type changes were attempted
            2 - if 1, product should be LanmanNT or ServerNT. If 0, should be WinNT
            3 - partial serial number
            4 - first two characters of product type from product options.

        1 means that offline changes to the nt evaluation unit time period
            2 - registered evaluation time from source 1
            3 - partial serial number
            4 - registered evaluation time from alternate source


        2 means that the setup key could not be opened
            2 - status code associated with the open failure

        3 - The SetupType value from the setup key is missing so gui setup
            mode could not be detected
            2 - status code associated with the key lookup failure

        4 - The SystemPrefix value from the setup key is missing
            2 - status code associated with the key lookup failure

        4 - The SystemPrefix value from the setup key is missing

        5 - means that offline changes were made to the number of licensed processors
            2 - see setup code
            3 - invalid value found in licensed processors
            4 - officially licensed number of processors

        6 - means that ProductOptions key could not be opened
            2 - status code associated with the open failure

        7 - means that ProductType value could not be read
            2 - status code associated with the read failure

        8 - means that Change Notify on ProductOptions failed
            2 - status code associated with the change notify failure

        9 - means that Change Notify on SystemPrefix failed
            2 - status code associated with the change notify failure

        10 - Looks like an NTW system was converted to an NTS system

        11 - Reference of setup key failed
            2 - status code associated with the change failure

        12 - Reference of product options key failed
            2 - status code associated with the change failure

        13 - Open of ProductOptions in worker thread failed
            2 - status code associated with the failure

        16 - Failure occured in the setup key worker thread
            2 - status code associated with the failure
            3 - 0 means set value failed, 1 means change notify failed

        17 - Failure occured in the product options key worker thread
            2 - status code associated with the failure
            3 - 0 means set value failed, 1 means change notify failed

        18 - Could not open the LicenseInfoSuites key for the suite
            2 - status code associated with the failure

        19 - Could not query the LicenseInfoSuites key for the suite
            2 - status code associated with the failure

        20 - Could not allocate memory
            2 - size of memory alllocation

        21 - Could not re-set the ConcurrentLimit value for the suite key
            2 - status code associated with the failure

        22 - Could not open the license key for a suite product
            2 - status code associated with the failure

        23 - Could not re-set the ConsurrentLimit value for a suite product
            2 - status code associated with the failure

        24 - Could not start the change notify for the LicenseInfoSuites
            2 - status code associated with the open failure

        25 - A suite is running on a system that must be pdc

        26 - Failure occurred when enumerating the suites
            2 - status code associated with the failure


KeBugCheckEx parameters;

    1 - The segment address which must reside on a quadword boundary.
    2 - The segment size which must be greater than the block size plus
        the size of a segment header.
    3 - The block size which must be a multiple of eight and smaller than
        the segment size minus the size of the segment header.

UDFS_FILE_SYSTEM              (0x9B)
    See the comment for FAT_FILE_SYSTEM

MACHINE_CHECK_EXCEPTION         (0x9C)

A fatal Machine Check Exception has occurred.

KeBugCheckEx parameters;

    x86 Processors
        If the processor has ONLY MCE feature available (For example Intel Pentium),
        the parameters are:

        1 - Low  32 bits of P5_MC_TYPE MSR
        2 -
        3 - High 32 bits of P5_MC_ADDR MSR
        4 - Low  32 bits of P5_MC_ADDR MSR

        If the processor also has MCA feature available (For example Intel
        Pentium Pro), the parameters are:

        1 - Bank number
        2 - Address field of MCi_ADDR MSR for the MCA bank that had the error
        3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
        4 - Low  32 bits of MCi_STATUS MSR for the MCA bank that had the error

    Alpha Processors
        1 - Platform-specific data, where available
        2 -
        3 - Pointer to Alpha system Logout Frame, where available.
        4 - Pointer to Uncorrectable Error frame.

DRIVER_POWER_STATE_FAILURE      (0x9F)

The driver lead to an inconsitent power state

Parameters:

     Value 1:
        1   - The device object is being freed which still has an
              outstanding power request which it has not completed

               2 - pointer to the device object


        2   - The device object completed the irp for the system power
              state request, but failed to call PoStartNextPowerIrp

               2 - pointer to the target device object
               3 - pointer to the device object

        3   - The device driver did not properly set the irp pending
              or complete the irp

               2 - pointer to the target device object
               3 - pointer to the device object
               4 - the irp

        100 - The device objects in the devnode were inconsistent
              in their use of DO_POWER_PAGABLE

               2 - pointer to the non-paged device object
               3 - pointer to the target device object
               4 - pointer to the device object to notify

        101 - A parent device object has detected that a child device
              has not set the DO_POWER_PAGABLE bit.
               2 - child device object (FDO)
               3 - child device object (PDO)
               4 - parent device object

PCI_BUS_DRIVER_INTERNAL          (0xA1)

The PCI Bus driver detected (theoretically impossible) inconsistency
problems in its internal structures and could not continue.


MEMORY_IMAGE_CORRUPT            (0xA2)
On a system wake operation, various regions of memory may be CRCed to
gaurd against memory failures.

    Value 1:
        2   - Table page check failure
                2 - the page number in of the table page which failed
                3 - 0

                2 - the page number with the failing page run index
                3 - non-zero, the index which failed to match the run

        3   - The checksum for the range of memory listed is incorrect
                2 - starting physical page # of the range
                3 - length (in pages) of the range
                4 - the page number of the table page containing this run

ACPI_DRIVER_INTERNAL            (0xA3)

The ACPI Driver detected an internal inconsistency. The inconsistency is
so severe that continuing to run would cause serious problems.

The ACPI driver calls this when the state is so inconsistent that proceeding
would actually be dangerous. The problem may or may not be a bios issue, but
we cannot actually tell.

To find the place where the driver died, look at the 2nd parameter. The high
word corresponds to an entry in wdm\acpi\driver\nt\debug.h. The low word
corresponds to a line number.


CNSS_FILE_SYSTEM_FILTER          (0xA4)
    See the comment for FAT_FILE_SYSTEM

ACPI_BIOS_ERROR                 (0xA5)

The ACPI Bios in the system is not fully compliant to the ACPI specification.
The first value indicates where the incompatibility lies:

  Plug & Play and Power Management related incompatibilities:
        
    0x1 --- ACPI_ROOT_RESOURCES_FAILURE
      ACPI cannot find the SCI Interrupt vector in the resources handed
      to it when ACPI is started.
        Argument 0  - ACPI's deviceExtension
        Argument 1  - ACPI's ResourceList
        Argument 2  - 0 <- Means no resource list found
        Argument 2  - 1 <- Means no IRQ resource found in list

    0x2 --- ACPI_ROOT_PCI_RESOURCE_FAILURE
      ACPI could not process the resource list for the PCI root buses
      There is an White Paper on the Web Site about this problem
        Argument 0  - The ACPI Extension for the PCI bus
        Argument 1  - 0
          Argument 2  - Pointer to the QUERY_RESOURCES irp
        Argument 1  - 1
          Argument 2  - Pointer to the QUERY_RESOURCE_REQUIREMENTS irp
        Argument 1  - 2
          Argument 2  - 0 <- Indicates that we found an empty resource list
        Argument 1  - 3 <- Could not find the current bus number in the CRS
          Argument 2  - Pointer to the PNP CRS descriptor
        Argument 1  - Pointer to the Resource List for PCI
          Argument 2  - Number of errors/conflicts found in the resource list

    0x3 --- ACPI_FAILED_MUST_SUCCEED_METHOD
      ACPI tried to run a control method while creating device extensions
      to represent the ACPI namespace, but this control method failed
        Argument 0  - The ACPI Object that was being run
        Argument 1  - return value from the interpreter
        Argument 2  - Name of the control method (in ULONG format)

    0x4 --- ACPI_PRW_PACKAGE_EXPECTED_INTEGER
      ACPI evaluated a _PRW and expected to find an integer as a
      package element
        Argument 0  - The ACPI Extension for which the _PRW belongs to
        Argument 1  - Pointer to the method
        Argument 2  - The DataType returned (see amli.h)

    0x5 --- ACPI_PRW_PACKAGE_TOO_SMALL
      ACPI evaluated a _PRW and the package that came back failed to
      contain at least 2 elements. The ACPI specification requires that
      two elements to always be present in a _PRW.
        Argument 0  - The ACPI Extension for which the _PRW belongs to
        Argument 1  - Pointer to the _PRW
        Argument 2  - Number of elements in the _PRW

    0x6 --- ACPI_PRx_CANNOT_FIND_OBJECT
      ACPI tried to find a named object named, but could not find it.
        Argument 0  - The ACPI Extension for which the _PRx belongs to
        Argument 1  - Pointer to the _PRx
        Argument 2  - Pointer to the name of the object to look for

    0x7 --- ACPI_EXPECTED_BUFFER
      ACPI evaluated a method and expected to receive a Buffer in return.
      However, the method returned some other data type
        Argument 0  - The ACPI Extension for which the method belongs to
        Argument 1  - Pointer to the method
        Argument 2  - The DataType returned (see amli.h)

    0x8 --- ACPI_EXPECTED_INTEGER
      ACPI evaluated a method and expected to receive an Integer in return.
      However, the method returned some other data type
        Argument 0  - The ACPI Extension for which the method belongs to
        Argument 1  - Pointer to the method
        Argument 2  - The DataType returned (see amli.h)

    0x9 --- ACPI_EXPECTED_PACKAGE
      ACPI evaluated a method and expected to receive a Package in return.
      However, the method returned some other data type
        Argument 0  - The ACPI Extension for which the method belongs to
        Argument 1  - Pointer to the method
        Argument 2  - The DataType returned (see amli.h)

    0xA --- ACPI_EXPECTED_STRING
      ACPI evaluated a method and expected to receive a String in return.
      However, the method returned some other data type
        Argument 0  - The ACPI Extension for which the method belongs to
        Argument 1  - Pointer to the method
        Argument 2  - The DataType returned (see amli.h)

    0xB --- ACPI_EJD_CANNOT_FIND_OBJECT
      ACPI cannot find the object referenced to by an _EJD string
        Argument 0  - The ACPI Extension for which which the _EJD belongs to
        Argument 1  - The status returned by the interpreter
        Argument 2  - Name of the object we are trying to find

    0xC --- ACPI_CLAIMS_BOGUS_DOCK_SUPPORT
      ACPI provides faulty/insufficient information for dock support
        Argument 0  - The ACPI Extension for which ACPI found a dock device
        Argument 1  - Pointer to the _EJD method
        Argument 2  - 0 <- Bios does not claim system is dockage
                      1 <- Duplicate device extensions for dock device
                
    0xD --- ACPI_REQUIRED_METHOD_NOT_PRESENT
      ACPI could not find a required method/object in the namespace
      This is the bugcheck that is used if a vendor does not have an
      _HID or _ADR present
         Argument 0  - The ACPI Extension that we need the object for
         Argument 1  - The (ULONG) name of the method we looked for
         Argument 2  - 0 <- Base Case
         Argument 2  - 1 <- Conflict

    0xE --- ACPI_POWER_NODE_REQUIRED_METHOD_NOT_PRESENT
      ACPI could not find a requird method/object in the namespace for
      a power resource (or entity other than a "device"). This is the
      bugcheck used if a vendor does not have an _ON, _OFF, or _STA present
      for a power resource
        Argument 0  - The NS PowerResource that we need the object for
        Argument 1  - The (ULONG) name of the method we looked for
        Argument 2  - 0 <- Base Case

    0xF --- ACPI_PNP_RESOURCE_LIST_BUFFER_TOO_SMALL
      ACPI could not parse the resource descriptor
        Argument 0  - The current buffer that ACPI was parsing
        Argument 1  - The buffer's tag
        Argument 2  - The specified length of the buffer

    0x10 --- ACPI_CANNOT_MAP_SYSTEM_TO_DEVICE_STATES
      ACPI could not map determine the system to device state mapping
      correctly. There is a very long white paper about this topic
        Argument 0  - The ACPI Extension for which are trying to do the mapping
        Argument 1  - 0 The _PRx mapped back to a non-supported S-state
          Argument 2  - The DEVICE_POWER_STATE (ie: x+1)
        Argument 1  - 1 We cannot find a D-state to associate with the S-state
          Argument 2  - The SYSTEM_POWER_STATE that is causing us grief
        Argument 1  - 2 The device claims to support wake from this s-state but
                        the s-state is not supported by the system
          Argument 2  - The SYSTEM_POWER_STATE that is causing us grief

    0x11 --- ACPI_SYSTEM_CANNOT_START_ACPI
      The system could not enter ACPI mode
        Argument 0  - 0 <- System could not initialize AML interpreter
        Argument 0  - 1 <- System could not find RSDT
        Argument 0  - 2 <- System could not allocate critical driver structures
        Argument 0  - 3 <- System could not load RSDT
        Argument 0  - 4 <- System could not load DDBs
        Argument 0  - 5 <- System cannot connect Interrupt vector
        Argument 0  - 6 <- SCI_EN never becomes set in PM1 Control Register
        Argument 0  - 7 <- Table checksum is incorrect
          Argument 1  - Pointer to the table that had a bad checksum
          Argument 2  - Creator Revision
        Argument 0  - 8 <- Failed to load DDB
          Argument 1  - Pointer to the table that we failed to load
          Argument 2  - Creator Revision

  Interrupt Routing Failures/Incompatibilities:

  A _PRT is the ACPI BIOS object that specifies how all the
  PCI devices are connected to the interrupt controllers.  PRT
  stands for PCI Routing Table.  A machine with multiple PCI
  busses may have multiple _PRTs. A _PRT can be displayed using the
  command !acpikd.nsobj <address of _PRT object>

  Report any failures in this section to PatrickF.

    0x2001 --- ACPI_FAILED_PIC_METHOD
      ACPI tried to evaluate the PIC control method and but failed
        Argument 0  - InterruptModel (Integer)
        Argument 1  - return value from interpreter
        Argument 2  - Pointer to the PIC control method

    0x10001 --- ACPI_CANNOT_ROUTE_INTERRUPTS
      ACPI tried to do interrupt routing, but failed
        Argument 0  - Pointer to the device object
        Argument 1  - Pointer to the parent of the device object
        Argument 2  - Pointer to the PRT

    0x10002 --- ACPI_PRT_CANNOT_FIND_LINK_NODE
      ACPI could not find the link node referenced in a _PRT
        Argument 0  - Pointer to the device object
        Argument 1  - Pointer to the string name we are looking for, but
                      could not find.
        Argument 2  - Pointer to the PRT.
                      Dump this with !acpikd.nsobj <argument 2>

    0x10003 --- ACPI_PRT_CANNOT_FIND_DEVICE_ENTRY
      ACPI could not find a mapping in the _PRT package for a device
        Argument 0  - Pointer to the device object
        Argument 1  - The Device ID / Function Number. This DWORD is encoded
                      as follows: Bits 5:0 are the PCI Device Number,
                      Bits 8:6 are the PCI function number.
        Argument 2  - Pointer to the PRT.
                      Dump this with !acpikd.nsobj <argument 2>

    0x10005 --- ACPI_PRT_HAS_INVALID_FUNCTION_NUMBERS
      ACPI found an entry in the _PRT for which the function ID isn't
      all F's. The Win98 behaviour is to bugcheck if it see this condition,
      so we do so all well. The generic format for a _PRT entry is such
      that the device number is specified, but the function number isn't.
      If it isn't done this way, then the machine vendor can introduce
      dangerous ambiguities
        Argument 0  - Pointer to the PRT object.
                      Dump this with !acpikd.nsobj <argument 2>
        Argument 1  - Pointer to the current PRT Element. This is an index into
                      the PRT.
        Argument 2  - The DeviceID/FunctionID of the element. This DWORD is
                      encoded. Bits 15:0 are the PCI Function Number.
                      Bits 31:16 are the PCI Device Number.

    0x10006 --- ACPI_LINK_NODE_CANNOT_BE_DISABLED
      ACPI found a link node, but cannot disable it. Link nodes must
      be disable to allow for reprogramming
        Argument 0  - Pointer to the link node. This device is missing the
                      _DIS method.


    0x10007 ---
      The _PRT contained a reference to a vector not described in the
      I/O APIC entries MAPIC table.
        Argument 0 - The vector that couldn't be found

  Other Failures/Incompatibilities:

    0x20000 ---
      The PM_TMR_BLK entry in the Fixed ACPI Description Table doesn't point
      to a working ACPI timer block.
        Argument 0 - The I/O port in the Fixed Table

BAD_EXHANDLE                    (0xA7)

The kernel mode handle table detected an inconsistent handle table
entry state.

SESSION_HAS_VALID_POOL_ON_EXIT  (0xAB)
        1 - session ID
        2 - number of paged pool bytes that are leaking
        3 - number of nonpaged pool bytes that are leaking
        4 - total number of paged and nonpaged allocations that are leaking.
            paged allocations are in the upper half of this word,
            nonpaged allocations are in the lower half of this word.

Caused by a session driver not freeing its pool allocations prior to a
session unload.  This happens only on Terminal Server systems and usually
indicates a bug in win32k.sys, atmfd.dll, rdpdd.dll or a video driver.

HAL_MEMORY_ALLOCATION           (0xAC)

The HAL was unable to obtain allocate memory (from the system Non Paged
pool) for a system critical requirement.   These allocations are made
early in system initialization and such a failure is not expected.  It
probably indicates some other critical error such as pool corruption or
massive consumption.

        1 - Allocation size.
        2 - 0
        3 - Pointer to string containing file name.
        4 - Line number of call to KeBugCheckEx.

VIDEO_DRIVER_INIT_FAILURE       (0xB4)

The system was not able to go into graphics mode because no display drivers
were able to start.  This usually occurs if no video miniport drivers load
successfully.

ATTEMPTED_SWITCH_FROM_DPC       (0xB8)

A wait operation, attach process, or yield was attempted from a DPC routine.
This is not a legal operation and the stack track will lead to the offending
code and original DPC routine.

CHIPSET_DETECTED_ERROR          (0xB9)
This bug code is normally caused by a parity error in the system memory or buses.
This error can also be caused by a device driver accessing a 0x8XXXXXXX address
that does not exist.
    1 - Platform-specific data, where available
    2 -
    3 - Pointer to Alpha system Logout Frame, where available.
    4 - Pointer to Uncorrectable Error frame.

SESSION_HAS_VALID_VIEWS_ON_EXIT  (0xBA)
        1 - session ID
        2 - number of mapped views that are leaking
        3 - address of this session's mapped views table
        4 - size of this session's mapped views table.

Caused by a session driver not unmapping its mapped views prior to a
session unload.  This happens only on Terminal Server systems and usually
indicates a bug in win32k.sys, atmfd.dll, rdpdd.dll or a video driver.

NETWORK_BOOT_INITIALIZATION_FAILED  (0xBB)
    1 - the part of network initialization that failed
    2 - the failure status
Caused if we are booting off the network, and a critical function fails during
IO initialization. Currently the codes for the first value are:
1 - updating the registry.
2 - starting the network stack - send IOCTLs to the redirector and datagram
    receiver, then wait for the redirector to be ready. If it is not ready
    within a certain period of time, we fail.
3 - failed sending the DHCP IOCTL to TCP - this is how we inform the
    transport of its IP adress.

NETWORK_BOOT_DUPLICATE_ADDRESS  (0xBC)
    1 - the IP address, show as a hex DWORD. So an address aa.bb.cc.dd will
        appear as 0xddccbbaa.
    2/3/4 - the hardware address of the other machine. For ethernet, a MAC address
        of aa-bb-cc-dd-ee-ff will be indicated by the second parameter containing
        0xaabbccdd, the third parameter containing 0xeeff0000, and the fourth
        parameter containing 0x00000000.
This indicates that when TCP/IP sent out an ARP for its IP address, it got
a response from another machine, indicating a duplicate IP address. When we
are booting off the network this is a fatal error.

INVALID_HIBERNATED_STATE    (0xBD)
The hibernated memory image does not match the current hardware configuration.
This bugcheck occurs when a system resumes from hibernate and discovers that the
hardware has been changed while the system was hibernated.
    1 - hardware that was invalid
        1 - Number of installed processors is less than before the hibernation
            2 - number of processors before hibernation
            3 - number of processors after hibernation

ATTEMPTED_WRITE_TO_READONLY_MEMORY    (0xBE)
An attempt was made to write to readonly memory.  The guilty driver is on the stack trace (and is typically the current instruction pointer).

    1 - Virtual address for the attempted write.
    2 - PTE contents.
    3 - Unique internal Mm information.
    4 - Unique internal Mm code.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

MUTEX_ALREADY_OWNED             (0xBF)

This thread is attempting to acquire ownership of a mutex it already owns.

        1 - Address of Mutex
        2 - Thread
        3 - 0
        4 - Unique value to help development isolate the instance.

SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION     (0xC1)

Special pool has detected memory corruption.  Typically the current thread's stack bactrace will reveal the guilty party.

    4 - subclass of driver violation.
        0x30 - caller is trying to allocate pool from an incorrect IRQL level, 1 == current IRQL, 2 == pool type, 3 == number of bytes

        0x20 - caller is trying to free pool which is not allocated, 1 == address trying to free, 2 == Mm internal code, 3 == 0.

        0x31 - caller is trying to free pool from an incorrect IRQL level, 1 == current IRQL, 2 == pool type, 3 == address trying to free

        0x21 - caller is trying to free a bad address, 1 == address trying to free, 2 == bytes requested, 3 == bytes calculated

        0x22 - caller is trying to free a bad address, 1 == address trying to free, 2 == bytes requested, 3 == bytes calculated

        0x23 - caller is freeing an address where nearby bytes within the same page have been corrupted, 1 == address trying to free, 2 == address where bits are corrupted, 3 == unique internal Mm pattern

        0x24 - caller is freeing an address where bytes after the end of the allocation have been overwritten, 1 == address trying to free, 2 == address where bits are corrupted, 3 == unique internal Mm pattern

BAD_POOL_CALLER                             (0xC2)

The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.

    1 - type of pool violation the caller is guilty of.
        6 - the pool address being freed is already free.
        7 - the pool address being freed is already free.
        8 - parameter 2 is the IRQL allocating at, parameter 3 is the pool type
        9 - parameter 2 is the IRQL freeing at, parameter 3 is the pool type

Parameter 1 = 0x1, 0x2, or 0x4 :  Pool header has been corrupted
        Parameter 2 = Pointer to pool header
        Parameter 3 = First part of pool header contents
        Parameter 4 = 0

Parameter 1 = 0x6 :    Attempt to free pool which was already freed
        Parameter 2 = Reserved (__LINE__)
        Parameter 3 = Pointer to pool header
        Parameter 4 = Pool header contents

Parameter 1 = 0x7 :    Attempt to free pool which was already freed
        Parameter 2 = Reserved (__LINE__)
        Parameter 3 = Pointer to pool header
        Parameter 4 = 0

Parameter 1 = 0x8 :    Attempt to allocate pool at invalid IRQL
        Parameter 2 = Current IRQL
        Parameter 3 = Pool type
        Parameter 4 = Size of allocation

Parameter 1 = 0x9 :    Attempt to free pool at invalid IRQL
        Parameter 2 = Current IRQL
        Parameter 3 = Pool type
        Parameter 4 = Address of pool

Parameter 1 = 0x40 :    Attempt to free usermode address to kernel pool
        Parameter 2 = Starting address
        Parameter 3 = Start of system address space
        Parameter 4 = 0

Parameter 1 = 0x41 :    Attempt to free a non-allocated nonpaged pool address
        Parameter 2 = Starting address
        Parameter 3 = physical page frame
        Parameter 4 = highest physical page frame

Parameter 1 = 0x50 :    Attempt to free a non-allocated paged pool address
        Parameter 2 = Starting address
        Parameter 3 = Start offset in pages from beginning of paged pool
        Parameter 4 = Size in bytes of paged pool

Parameter 1 = 0x99 :    Attempt to free pool with invalid address  (or corruption in pool header)
        Parameter 2 = Address being freed
        Parameter 3 = 0
        Parameter 4 = 0

DRIVER_VERIFIER_DETECTED_VIOLATION         (0xC4)

A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be the most commonly seen crashes.

    1 - subclass of driver violation.
        0x00 - caller is trying to allocate zero bytes, 2 == current IRQL, 3 == pool type, 4 == number of bytes

        0x01 - caller is trying to allocate paged pool at DISPATCH_LEVEL or above, 2 == current IRQL, 3 == pool type, 4 == number of bytes

        0x02 - caller is trying to allocate nonpaged pool at an IRQL above DISPATCH_LEVEL, 2 == current IRQL, 3 == pool type, 4 == number of bytes

        0x03 - caller is trying to allocate more than one page of mustsucceed pool, but one page is the maximum allowed by this API.

        0x10 - caller is freeing a bad pool address, 2 == bad pool address

        0x11 - caller is trying to free paged pool at DISPATCH_LEVEL or above, 2 == current IRQL, 3 == pool type, 4 == pool address

        0x12 - caller is trying to free nonpaged pool at an IRQL above DISPATCH_LEVEL, 2 == current IRQL, 3 == pool type, 4 == pool address

        0x13 - the pool the caller is trying to free is already free.  2 == line number, 3 == pool header, 4 == pool header contents

        0x14 - the pool the caller is trying to free is already free.  2 == line number, 3 == pool header, 4 == pool header contents

        0x15 - the pool the caller is trying to free contains an active timer.  2 == timer entry, 3 == pool type, 4 == pool address being freed

        0x16 - the pool the caller is trying to free is a bad address.  2 == line number, 3 == pool address, 4 == 0

        0x17 - the pool the caller is trying to free contains an active ERESOURCE.  2 == resource entry, 3 == pool type, 4 == pool address being freed

        0x30 - raising IRQL to an invalid level, 2 == current IRQL, 3 == new IRQL
        0x31 - lowering IRQL to an invalid level, 2 == current IRQL, 3 == new IRQL
        0x32 - releasing a spinlock when not at DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock address

        0x33 - acquiring a fast mutex when not at APC_LEVEL or below.  2 == current IRQL, 3 == fast mutex address

        0x34 - releasing a fast mutex when not at APC_LEVEL.  2 == current IRQL, 3 == thread APC disable count, 4 == fast mutex address

        0x35 - kernel is releasing a spinlock when not at DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock address, 4 == old irql.

        0x36 - kernel is releasing a queued spinlock when not at DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock number, 4 == old irql.

        0x37 - a resource is being acquired but APCs are not disabled. 2 == current IRQL, 3 == thread APC disable count, 4 == resource.

        0x38 - a resource is being released but APCs are not disabled. 2 == current IRQL, 3 == thread APC disable count, 4 == resource.

        0x39 - a mutex is being acquired unsafe, but irql is not APC_LEVEL on entry. 2 == current IRQL, 3 == thread APC disable count, 4 == mutex.

        0x3A - a mutex is being released unsafe, but irql is not APC_LEVEL on entry. 2 == current IRQL, 3 == thread APC disable count, 4 == mutex.

        0x40 - acquiring a spinlock when not at DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock address

        0x41 - releasing a spinlock when not at DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock address

        0x42 - acquiring a spinlock when caller is already above DISPATCH_LEVEL.  2 == current IRQL, 3 == spinlock address

        0x51 - freeing memory where the caller has written past the end of the allocation overwriting our stored bytecount.  2 == base address of the allocation, 3 == corrupt address, 4 == charged bytes.

        0x52 - freeing memory where the caller has written past the end of the allocation overwriting our stored virtual address.  2 == base address of the allocation, 3 == hash entry, 4 == charged bytes.

        0x53 - freeing memory where the caller has written past the end of the allocation overwriting our stored virtual address.  2 == base address of the allocation, 3 == header, 4 = internal verifier pointer.

        0x54 - freeing memory where the caller has written past the end of the allocation overwriting our stored virtual address.  2 == base address of the allocation, 3 == pool hash size, 4 = listindex.

        0x59 - freeing memory where the caller has written past the end of the allocation overwriting our stored virtual address.  2 == base address of the allocation, 3 == listindex, 4 == internal verifier pointer.

        0x60 - A driver has forgotten to free its pool allocations prior to unloading.  2 == paged bytes, 3 = nonpaged bytes, 4 == total # of (paged+nonpaged) allocations that weren't freed.

            In the kernel debugger, type:
                kd> dc ViBadDriver l1; dc @$p+4 l1; du @$p

                This gives you the name of the driver.
                Then type !verifier 3 drivername.sys for info on the allocations
                that were leaked that caused the bugcheck.

            Assign the bug to the driver owner found above.

        0x61 - A driver is unloading and allocating memory (in another thread) at the same time.  2 == paged bytes, 3 = nonpaged bytes, 4 == total # of (paged+nonpaged) allocations that weren't freed.

            In the kernel debugger, type:
                kd> dc ViBadDriver l1; dc @$p+4 l1; du @$p

                This gives you the name of the driver.
                Then type !verifier 3 drivername.sys for info on the allocations
                that were leaked that caused the bugcheck.

            Assign the bug to the driver owner found above.

        0x70 - MmProbeAndLockPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == access mode

        0x71 - MmProbeAndLockProcessPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == process address

        0x72 - MmProbeAndLockSelectedPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == process address

        0x73 - MmMapIoSpace called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == low 32 bits of the physical address (full 64 on Win64)
               4 == number of bytes

        0x74 - MmMapLockedPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == access mode

        0x75 - MmMapLockedPages called when not at APC_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == access mode

        0x76 - MmMapLockedPagesSpecifyCache called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == access mode

        0x77 - MmMapLockedPagesSpecifyCache called when not at APC_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == access mode

        0x78 - MmUnlockPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == MDL address
               4 == 0

        0x79 - MmUnmapLockedPages called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == virtual address being unmapped
               4 == MDL address

        0x7A - MmUnmapLockedPages called when not at APC_LEVEL or below.
               2 == current IRQL
               3 == virtual address being unmapped
               4 == MDL address

        0x7B - MmUnmapIoSpace called when not at APC_LEVEL or below.
               2 == current IRQL
               3 == virtual address being unmapped
               4 == number of bytes

        0x7C - MmUnlockPages called with an MDL whose pages were never successfully locked.
               2 == MDL address
               3 == MDL flags
               4 == 0

        0x7D - MmUnlockPages called with an MDL whose pages are from nonpaged pool - these should never be unlocked.
               2 == MDL address
               3 == MDL flags
               4 == 0

        0x80 - KeSetEvent called when not at DISPATCH_LEVEL or below.
               2 == current IRQL
               3 == event address
               4 == 0

DRIVER_CORRUPTED_EXPOOL           (0xC5)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
        4 - address which referenced memory

An attempt was made to touch invalid memory at a process
internal request level (IRQL) too high.  This is almost always
caused by drivers that have corrupted the system pool.  Run the driver
verifier against any new (or suspect) drivers, and if that doesn't turn up
the culprit, then use gflags to enable special pool.

DRIVER_CAUGHT_MODIFYING_FREED_POOL           (0xC6)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - previous mode.
        4 - 4.

An attempt was made to access freed pool memory.  The faulty component is
displayed in the current kernel stack.

TIMER_OR_DPC_INVALID                                    (0xC7)

A kernel timer or DPC was found in memory which must not contain such items.
Usually this is memory being freed.  This is usually caused by a device driver
that has not cleaned up properly before freeing memory.

        1 - What kind of object
            0   Timer Object
            1   DPC Object
            2   DPC Routine
        2 - Address of object
        3 - Start of range being checked
        4 - End of range being checked

IRQL_UNEXPECTED_VALUE                                   (0xC8)

The processor's IRQL is not what it should be at this time.  This is
usually caused by a lower level routine changing IRQL for some period
and not restoring IRQL at the end of that period (eg acquires spinlock
but doesn't release it).

        1 - (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue
        if UniqueValue is 0 or 1
            2 - APC->KernelRoutine
            3 - APC
            4 - APC->NormalRoutine

DRIVER_VERIFIER_IOMANAGER_VIOLATION                     (0xC9)
The IO manager has caught a misbehaving driver.
        1 - Code that specifies the violation
            1. Invalid IRP passed to IoFreeIrp
		2 - the IRP passed in
		3/4 - 0 
            2. IRP still associated with a thread at IoFreeIrp
		2 - the IRP passed in
		3/4 - 0 
            3. Invalid IRP passed to IoCallDriver
		2 - the IRP passed in
		3/4 - 0 
            4. Invalid Device object passed to IoCallDriver
		2 - the Device object
		3/4 - 0 
            5. Irql not equal across call to the driver dispatch routine
		2 - the device object associated with the offending driver
		3 - the Irql before the call
		4 - the Irql after the call
            6. IRP passed to IoCompleteRequest contains invalid status
		2 - the status
		3 - the IRP
		4 - 0 
            7. IRP passed to IoCompleteRequest still has cancel routine set
		2 - the cancel routine pointer
		3 - the IRP
		4 - 0 
	    8. Call to IoBuildAsynchronousFsdRequest threw an exception
		2 - the Device object
		3 - the IRP major function
		4 - the exception status
	    9. Call to IoBuildDeviceIoControlRequest threw an exception
		2 - the Device object
		3 - the IoControlCode
		4 - the exception status
	   10. Reinitialization of Device object timer
		2 - the Device object
		3/4 - 0
	   11. Unused
	   12. Invalid IOSB in IRP at APC IopCompleteRequest (appears to be on
		stack that was unwound)
	        2 - the IOSB pointer
		3/4 - 0
	   13. Invalid UserEvent in IRP at APC IopCompleteRequest (appears to be on
		stack that was unwound)
	        2 - the UserEvent pointer
		3/4 - 0
	   14. Irql > DPC at IoCompleteRequest
		2 - the current Irql
		3 - the IRP
		4 - 0 

PNP_DETECTED_FATAL_ERROR                    (0xCA)

PnP encountered a severe error, either as a result of a problem in a driver or
a problem in PnP itself.  The first argument describes the nature of the
problem, the second argument is the address of the PDO.  The other arguments
vary depending on argument 1.

        1 - Type of error.
        2 - Address of PDO.
        3 - Varies depending on argument 1
        4 - Varies depending on argument 1

Argument 1 - defined error types:

        1 - Duplicate PDO

                A specific instance of a driver has enumerated multiple PDOs with
                identical device id and unique ids.

                Arguments:

                2 - Newly reported PDO.

                3 - PDO of which it is a duplicate.

        2 - Invalid PDO

                An API which requires a PDO has been called with either an FDO, a PDO
                which hasn't been initialized yet (returned to PnP in a
                QueryDeviceRelation/BusRelations), or some random piece of memory.

                Arguments:

                2 - Purported PDO.

        3 - Invalid ID

		An enumerator has returned an ID which contains illegal characters or
		isn't properly terminated.  IDs must only contain characters in the
		range 0x20-7F inclusive with the exception of 0x2C (comma) which is
		illegal.

                2 - PDO whose IDs were queried

                3 - Address of ID buffer

                4 - Type of ID

                        1 = DeviceID
                        2 = UniqueID
                        3 = HardwareIDs
                        4 = CompatibleIDs

	4 - Invalid enumeration of deleted PDO

		An enumerator has returned a PDO which it has previously deleted using
		IoDeleteDevice.

		2 - PDO with DOE_DELETE_PENDING set.

	5 - PDO freed while still linked in devnode tree.

		The object manager reference count on a PDO dropped to zero while the
		devnode was still linked in the tree.  This usually indicates that the
		driver is not adding a reference when returning the PDO in a query IRP.

		2 - PDO.



DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS     (0xCB)
        1 - The calling address in the driver that locked the pages.
        2 - The caller of the calling address in the driver that locked the pages.
        3 - A pointer to the MDL containing the locked pages.
        4 - The guilty driver's name (Unicode string).

Caused by a driver not cleaning up completely after an I/O.  The bad driver's
name is printed on the bugcheck screen and is available for re-dumping as
parameter 4 in the bugcheck data.
The broken driver's name is displayed on the screen.

PAGE_FAULT_IN_FREED_SPECIAL_POOL        (0xCC)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - if non-zero, the address which referenced memory.
        4 - Mm internal code.

Memory was referenced after it was freed.
This cannot be protected by try-except.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

PAGE_FAULT_BEYOND_END_OF_ALLOCATION     (0xCD)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - if non-zero, the address which referenced memory.
        4 - Mm internal code.

N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS      (0xCE)

A driver unloaded without cancelling timers, DPCs, worker threads, etc.
The broken driver's name is displayed on the screen.
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - If non-zero, the instruction address which referenced the bad memory
            address.
        4 - Mm internal code.

TERMINAL_SERVER_DRIVER_MADE_INCORRECT_MEMORY_REFERENCE     (0xCF)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - If non-zero, the instruction address which referenced the bad memory
            address.
        4 - Mm internal code.

A driver has been incorrectly ported to Terminal Server.  It is referencing
session space addresses from the system process context.  Probably from
queueing an item to a system worker thread.
The broken driver's name is displayed on the screen.

DRIVER_CORRUPTED_MMPOOL     (0xD0)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
        4 - address which referenced memory

An attempt was made to touch invalid memory at a process
internal request level (IRQL) too high.  This is almost always
caused by drivers that have corrupted the system pool.  Run the driver
verifier against any new (or suspect) drivers, and if that doesn't turn up
the culprit, then use gflags to enable special pool.  You can also set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Mamagement\ProtectNonPagedPool to a DWORD 1 value and reboot.  Then the system will unmap freed nonpaged pool, preventing drivers (although not DMA-hardware) from corrupting
the pool.

DRIVER_IRQL_NOT_LESS_OR_EQUAL           (0xD1)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
        4 - address which referenced memory

An attempt was made to touch pagable memory at a process
internal request level (IRQL) too high.  This is usually
caused by drivers using improper addresses.

If kernel debugger is available get stack backtrace.

DRIVER_PORTION_MUST_BE_NONPAGED         (0xD3)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
            If this value is non-zero and is equal to parameter 1, then
            The bugcheck indicates that a worker routine returned at raised
            IRQL.Parameter 1 and 3 are the address of the work routine, and
            parameter 4 is the workitem
        4 - address which referenced memory

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

An attempt was made to touch pagable memory at a process
internal request level (IRQL) too high.  This is usually
caused by drivers marking code or data as pagable when it should be
marked nonpaged.

If kernel debugger is available get stack backtrace.

SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD    (0xD4)

A driver unloaded without cancelling lookaside lists, DPCs, worker threads, etc.
The broken driver's name is displayed on the screen.

        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
            If this value is non-zero and is equal to parameter 1, then
            The bugcheck indicates that a worker routine returned at raised
            IRQL.Parameter 1 and 3 are the address of the work routine, and
            parameter 4 is the workitem
        4 - address which referenced memory

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

An attempt was made to access the driver at raised IRQL after it unloaded.

If kernel debugger is available get stack backtrace.

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL        (0xD5)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - if non-zero, the address which referenced memory.
        4 - Mm internal code.

Memory was referenced after it was freed.
This cannot be protected by try-except.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION     (0xD6)
        1 - memory referenced
        2 - value 0 = read operation, 1 = write operation
        3 - if non-zero, the address which referenced memory.
        4 - Mm internal code.

N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

DRIVER_UNMAPPING_INVALID_VIEW                  (0xD7)
        1 - virtual address to unmap.
        2 - 1 if system is Terminal Server, 0 if not.
        3 - 0.
        4 - 0.

A driver (usually win32k.sys, but can be determined from the stack trace for
certain) is trying to unmap an address that was not mapped.

DRIVER_USED_EXCESSIVE_PTES                      (0xD8)
        1 - If non-null, the guilty driver's name (Unicode string).
        2 - If parameter 1 non-null, the number of PTEs used by the guilty driver.
        3 - Total free system PTEs
        4 - Total system PTEs

No System PTEs left.  Usually caused by a driver not cleaning up
properly.  If non-null, the second parameter shows the name of the driver
who is consuming the most PTEs.  The calling stack also shows the name of
the driver which bugchecked.  Both drivers need to be fixed and/or the number
of PTEs increased.

When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

LOCKED_PAGES_TRACKER_CORRUPTION                 (0xD9)

        1 - Type of error.
        2 - Varies depending on argument 1.
        3 - Varies depending on argument 1.
        4 - Varies depending on argument 1.

Argument 1 - defined error types:

        1 - The MDL is being inserted twice on the same process list.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Address of memory descriptor list.
                4 - Number of pages locked for the current process.

        2 - The MDL is being inserted twice on the systemwide list.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Address of memory descriptor list.
                4 - Number of pages locked for the current process.

        3 - The MDL was found twice in the process list when being freed.

                Arguments:

                2 - Address of first internal tracking structure found.
                3 - Address of internal lock tracking structure.
                4 - Address of memory descriptor list.


        4 - The MDL was found in the systemwide list on free after it was removed.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Address of memory descriptor list.
                4 - 0.

SYSTEM_PTE_MISUSE                               (0xDA)

The stack trace identifies the guilty driver.

        1 - Type of error.
        2 - Varies depending on argument 1.
        3 - Varies depending on argument 1.
        4 - Varies depending on argument 1.

Argument 1 - defined error types:

        1 - The PTE mapping being freed is a duplicate.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Address of memory descriptor list.
                4 - Address of duplicate internal lock tracking structure.

        2 - The number of PTE mappings being freed is incorrect.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Number of PTEs the system thinks should be freed.
                4 - Number of PTEs the driver is requesting to free.

        3 - The PTE mapping address being freed is incorrect.

                Arguments:

                2 - Address of first internal tracking structure found.
                3 - The PTE address the system thinks should be freed.
                4 - The PTE address the driver is requesting to free.

        4 - The first page of the mapped MDL has changed since the MDL was mapped.

                Arguments:

                2 - Address of internal lock tracking structure.
                3 - Page frame number the system thinks should be first in the MDL.
                4 - Page frame number that is currently first in the MDL.

        5 - The start virtual address in the MDL being freed has changed since
        the MDL was mapped.

                Arguments:

                2 - Address of first internal tracking structure found.
                3 - The virtual address the system thinks should be freed.
                4 - The virtual address the driver is requesting to free.

        6 - The MDL being freed was never (or is currently not) mapped.

                Arguments:

                2 - The MDL specified by the driver.
                3 - The virtual address specified by the driver.
                4 - The number of PTEs to free (specified by the driver).

        7 - The PTE range is being double allocated.

                Arguments:

                2 - Starting PTE.
                3 - Number of PTEs.
                4 - Caller Id (system internal).

        8 - The caller is asking to free an incorrect number of PTEs.

                Arguments:

                2 - Starting PTE.
                3 - Number of PTEs the caller is freeing.
                4 - Number of PTEs the system thinks should be freed.

        9 - The caller is asking to free PTEs where one of them is not allocated.

                Arguments:

                2 - Starting PTE.
                3 - Number of PTEs the caller is freeing.
                4 - PTE index that the system thinks is already free.

        0xA - The caller is asking to allocate 0 PTEs.

                Arguments:

                2 - Bugcheck on failure parameter.
                3 - Number of PTEs the caller is allocating.
                4 - Type of PTE pool requested.

        0xB - The PTE list is already corrupted at the time of this allocation.
          The corrupt PTE is below the lowest possible PTE address.

                Arguments:

                2 - Corrupt PTE.
                3 - Number of PTEs the caller is allocating.
                4 - Type of PTE pool requested.

        0xC - The PTE list is already corrupted at the time of this allocation.
          The corrupt PTE is above the lowest possible PTE address.

                Arguments:

                2 - Corrupt PTE.
                3 - Number of PTEs the caller is allocating.
                4 - Type of PTE pool requested.

        0xD - The caller is trying to free 0 PTEs.

                Arguments:

                2 - Starting PTE.
                3 - Number of PTEs the caller is freeing.
                4 - Type of PTE pool.

        0xE - The caller is trying to free PTEs and the guard PTE has been overwritten.

                Arguments:

                2 - Starting PTE.
                3 - Number of PTEs the caller is freeing.
                4 - Type of PTE pool.

        0xF - The caller is trying to free a bogus PTE.
          The bogus PTE is below the lowest possible PTE address.

                Arguments:

                2 - Bogus PTE.
                3 - Number of PTEs the caller is trying to free.
                4 - Type of PTE pool being freed.

        0x10 - The caller is trying to free a bogus PTE.
           The bogus PTE is above the highest possible PTE address.

                Arguments:

                2 - Bogus PTE.
                3 - Number of PTEs the caller is trying to free.
                4 - Type of PTE pool being freed.

        0x11 - The caller is trying to free a bogus PTE.
           The bogus PTE is at the base of the PTE address space.

                Arguments:

                2 - Bogus PTE.
                3 - Number of PTEs the caller is trying to free.
                4 - Type of PTE pool being freed.

DRIVER_CORRUPTED_SYSPTES           (0xDB)
        1 - memory referenced
        2 - IRQL
        3 - value 0 = read operation, 1 = write operation
        4 - address which referenced memory

An attempt was made to touch invalid memory at a process
internal request level (IRQL) too high.  This is almost always
caused by drivers that have corrupted system PTEs.  Set
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Mamagement\TrackPtes to a DWORD 1 value and reboot.  Then the system will save stack traces and
perform validity checks so the guilty driver can be identified.
There is no other way to find out which driver did this.  When you enable
this flag, if the driver commits the error again you will see a different
bugcheck - SYSTEM_PTE_MISUSE - and the stack trace will identify the offending
driver(s).

DRIVER_INVALID_STACK_ACCESS                   (0xDC)

A driver accessed a stack address that lies below the stack pointer of the
stack's thread.

POOL_CORRUPTION_IN_FILE_AREA                  (0xDE)

A driver corrupted pool memory used for holding pages destined for disk.
This was discovered by the memory manager when dereferencing the file.

WORKER_THREAD_RETURNED_AT_BAD_IRQL            (0xE1)
        1 - address of worker routine (do ln on this to find guilty driver)
        2 - IRQL returned at (should have been 0, but isn't).
        3 - workitem parameter
        4 - workitem address

MANUALLY_INITIATED_CRASH                      (0xE2)

The user manually initiated this crash dump.  

RESOURCE_NOT_OWNED                            (0xE3)

A thread tried to release a resource it did not own.

	1 - Address of resource
	2 - Address of thread
	3 - Address of owner table if there is one

WORKER_INVALID                                (0xE4)

A executive worker item was found in memory which must not contain such
items.  Usually this is memory being freed.  This is usually caused by
a device driver that has not cleaned up properly before freeing memory.

	1 - Code position indicator
	2 - Address of worker item
	3 - Start of pool block
	4 - End of pool block

BUGCHECK C000026C                       (0xC000026C)

A driver image (xxx.sys) is missing or otherwise corrupt.  In many cases
this is a newly hand-copied image where there was operator or media error.
ie: putting an Alpha driver on an x86 machine, etc.

        1 - pointer to a Unicode string containing the bad driver image name.

            In the kernel debugger, type:
                kd> dc KiBugCheckData+4 l1  (dq KiBugCheckData+8 on Win64)
                kd> du $@p l2

                This gives you the filename of the broken driver image.

        2 - actual cause of the error (look this up in ntstatus.h).

            Some common ones are :

                C0000221 == image checksum mismatch
                C000007B == the image format is invalid (bad image header).
                C0000034 == the image was not found
                C000000E == no such device (send mail to ntmsd)

IMPERSONATING_WORKER_THREAD

A workitem forgot to disable impersonation before it completed.

    1 - Worker Routine that caused this bugcheck.
    2 - Parameter passed to this worker routine.
    3 - Pointer to the Workitem.
