You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4209 lines
170 KiB
4209 lines
170 KiB
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
|
|
|
|
Note:
|
|
Please use following format for modifications in this file, it helps
|
|
the debugger to extract the description text from this file:
|
|
<BUGCODE> <value>
|
|
<text>
|
|
PARAMETERS
|
|
<ParamId1> - <text>
|
|
VALUES: - If parameter values are explained.
|
|
<paramId1-value> : <text>
|
|
<ParamId2> - <text>
|
|
<ParamId3> - <text>
|
|
<paramid4> - <text>
|
|
<paramId1-value> : <text>
|
|
<ParamId2> - <text>
|
|
VALUES: - If parameter values are explained.
|
|
<paramId2-value> : <text>
|
|
END_VALUES
|
|
<ParamId3> - <text>
|
|
|
|
<paramid4> - <text>
|
|
DESCRIPTION - if more description text for bugcheck follows
|
|
<text>
|
|
|
|
APC_INDEX_MISMATCH (0x1)
|
|
This is a kernel internal error which can occur only 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. This check is made on exit from a system
|
|
call.
|
|
PARAMETERS
|
|
1 - address of system function (system call)
|
|
2 - Thread->ApcStateIndex << 8 | Previous ApcStateIndex
|
|
3 - Thread->KernelApcDicable
|
|
4 - Previous KernelApcDisable
|
|
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
An attempt was made to access a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is too high. This is usually
|
|
caused by drivers using improper addresses.
|
|
|
|
If a kernel debugger is available get the stack backtrace.
|
|
|
|
|
|
NO_EXCEPTION_HANDLING_SUPPORT (0xB)
|
|
|
|
MAXIMUM_WAIT_OBJECTS_EXCEEDED (0xC)
|
|
|
|
MUTEX_LEVEL_NUMBER_VIOLATION (0xD)
|
|
|
|
NO_USER_MODE_CONTEXT (0xE)
|
|
|
|
SPIN_LOCK_ALREADY_OWNED (0xF)
|
|
|
|
SPIN_LOCK_NOT_OWNED (0x10)
|
|
|
|
THREAD_NOT_MUTEX_OWNER (0x11)
|
|
|
|
TRAP_CAUSE_UNKNOWN (0x12)
|
|
|
|
PARAMETERS
|
|
1 - Unexpected interrupt.
|
|
2 - Unknown floating point exception.
|
|
3 - The enabled and asserted status bits (see processor definition).
|
|
|
|
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.
|
|
PARAMETERS
|
|
1 -
|
|
VALUES:
|
|
3 : the pool freelist is corrupt.
|
|
Parameter 2 - the pool entry being checked.
|
|
Parameter 3 - the read back flink freelist value (should be the same as 2).
|
|
Parameter 4 - the read back blink freelist value (should be the same as 2).
|
|
|
|
5 : the adjacent pool block headers are corrupt.
|
|
Parameter 2 - One entry whose headers are not consistent.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - Another entry whose headers are not consistent.
|
|
|
|
6 : the pool block header previous size is corrupt (too large).
|
|
Parameter 2 - One incorrectly calculated entry.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - The bad entry that caused the miscalculation.
|
|
|
|
7 : the pool block header size is corrupt.
|
|
Parameter 2 - 0.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - The bad pool entry.
|
|
|
|
8 : the pool block header size is corrupt.
|
|
Parameter 2 - 0.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - The bad pool entry (should have nonzero size but doesn't).
|
|
|
|
9 : the pool block header size is corrupt (too large).
|
|
Parameter 2 - One incorrectly calculated entry.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - The bad entry that caused the miscalculation.
|
|
|
|
0xA : a pool block header size is corrupt.
|
|
Parameter 2 - The pool entry we were looking for within the page.
|
|
Parameter 3 - (reserved)
|
|
Parameter 4 - The VA of the page that should have contained the pool entry.
|
|
|
|
END_VALUES
|
|
|
|
MEMORY_MANAGEMENT (0x1A)
|
|
|
|
PARAMETERS
|
|
1 - The subtype of the bugcheck:
|
|
VALUES:
|
|
0x1 : The fork clone block reference count is corrupt. Only occurs
|
|
on checked builds.
|
|
0x777 : The caller is unlocking a system cache address that is not
|
|
currently locked. (This address was either never mapped or
|
|
is being unlocked twice.)
|
|
0x778 : The system is using the very last system cache view address,
|
|
instead of preserving it.
|
|
0x780-781 : The PTEs mapping the argument system cache view have been
|
|
corrupted.
|
|
0x1000 : A caller of MmGetSystemAddressForMdl* tried to map a fully-
|
|
cached physical page as non-cached. This action would cause
|
|
a conflicting hardware translation buffer entry, and so it
|
|
was refused by the operating system. Since the caller
|
|
specified "bugcheck on failure" in the requesting MDL, the
|
|
system had no choice but to bugcheck in this instance.
|
|
0x1010 : The caller is unlocking a pageable section that is not
|
|
currently locked. (This section was either never locked or
|
|
is being unlocked twice.)
|
|
0x1234 : The caller is trying lock a nonexistent pageable section.
|
|
0x1235 : The caller is trying to protect an MDL with an invalid
|
|
mapping.
|
|
0x3451 : The PTEs of an outswapped kernel thread stack are corrupt.
|
|
0x8888-8889 : Internal memory management structures are corrupt.
|
|
0x41283 : The working set index encoded in the PTE is corrupt.
|
|
0x41284 : A PTE or the working set list is corrupt.
|
|
0x41286 : The caller is trying to free an invalid pool address.
|
|
0x41785 : The working set list is corrupt.
|
|
0x61940 : A PDE has been unexpectedly invalidated.
|
|
Other : An unknown memory management error occurred.
|
|
END_VALUES
|
|
|
|
DESCRIPTION
|
|
# 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)
|
|
PARAMETERS
|
|
1 - The exception code that was not handled
|
|
VALUES
|
|
0x80000002: (STATUS_DATATYPE_MISALIGNMENT) An unaligned data reference was encountered.
|
|
The trap frame will supply additional information.
|
|
0x80000003: This means a hard coded breakpoint or assertion was hit, but this system was booted
|
|
/NODEBUG. This is not supposed to happen as developers should never have
|
|
hardcoded breakpoints in retail code, but ...
|
|
If this happens, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
END_VALUES
|
|
2 - The address that the exception occurred at
|
|
3 - Parameter 0 of the exception
|
|
4 - Parameter 1 of the exception
|
|
|
|
DESCRIPTION
|
|
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.
|
|
|
|
SHARED_RESOURCE_CONV_ERROR (0x1F)
|
|
|
|
KERNEL_APC_PENDING_DURING_EXIT (0x20)
|
|
PARAMETERS
|
|
1 - The address of the APC found pending during exit.
|
|
2 - The thread's APC disable count
|
|
3 - The current IRQL
|
|
|
|
DESCRIPTION
|
|
The key data item is the thread's APC disable count.
|
|
If this is non-zero, then this is the source of the problem.
|
|
|
|
The APC disable count is decremented each time a driver calls
|
|
KeEnterCriticalRegion, KeInitializeMutex, or FsRtlEnterFileSystem. The APC
|
|
disable count is incremented each time a driver calls KeLeaveCriticalRegion,
|
|
KeReleaseMutex, or FsRtlExitFileSystem. Since these calls should always be in
|
|
pairs, this value should be zero when a thread exits. A negative value
|
|
indicates that a driver has disabled APC calls without re-enabling them. A
|
|
positive value indicates that the reverse is true.
|
|
|
|
If you ever see this error, be very suspicious of all drivers installed on the
|
|
machine -- especially unusual or non-standard drivers. Third party file
|
|
system redirectors are especially suspicious since they do not generally
|
|
receive the heavy duty testing that NTFS, FAT, RDR, etc 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 note what you were 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)
|
|
|
|
If you see FatExceptionFilter 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.
|
|
|
|
NTFS_FILE_SYSTEM (0x24)
|
|
|
|
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)
|
|
|
|
CDFS_FILE_SYSTEM (0x26)
|
|
|
|
If you see CdExceptionFilter 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.
|
|
|
|
RDR_FILE_SYSTEM (0x27)
|
|
If you see RxExceptionFilter 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.
|
|
|
|
The high 16 bits of the first parameter is the RDBSS bugcheck code, which is defined
|
|
as follows:
|
|
RDBSS_BUG_CHECK_CACHESUP = 0xca550000,
|
|
RDBSS_BUG_CHECK_CLEANUP = 0xc1ee0000,
|
|
RDBSS_BUG_CHECK_CLOSE = 0xc10e0000,
|
|
RDBSS_BUG_CHECK_NTEXCEPT = 0xbaad0000,
|
|
|
|
|
|
CORRUPT_ACCESS_TOKEN (0x28)
|
|
|
|
SECURITY_SYSTEM (0x29)
|
|
|
|
INCONSISTENT_IRP (0x2A)
|
|
PARAMETERS
|
|
1 - Address of the IRP that was found to be inconsistent
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - Trap Frame
|
|
DESCRIPTION
|
|
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.
|
|
PARAMETERS
|
|
1 - Virtual address that caused the fault
|
|
2 - Physical address that caused the fault.
|
|
3 - Processor status register (PSR)
|
|
4 - Faulting instruction register (FIR)
|
|
DESCRIPTION
|
|
This error can also be caused by a driver accessing a bad virtual
|
|
address whose backing physical address does not exist.
|
|
|
|
|
|
INSTRUCTION_BUS_ERROR (0x2F)
|
|
|
|
|
|
SET_OF_INVALID_CONTEXT (0x30)
|
|
|
|
Attempt to set the stack pointer in the trap frame to a lower value than
|
|
the current stack pointer value. This would cause the kernel run with a
|
|
stack pointer pointing to stack which is no longer valid.
|
|
PARAMETERS
|
|
1 - New stack pointer
|
|
2 - Old stack pointer
|
|
3 - TrapFrame address
|
|
4 - 0
|
|
|
|
PHASE0_INITIALIZATION_FAILED (0x31)
|
|
|
|
System init failed early on. A debugger is required to analyze this.
|
|
|
|
PHASE1_INITIALIZATION_FAILED (0x32)
|
|
PARAMETERS
|
|
1 - NT status code that describes why the system initialization failed.
|
|
2 - (reserved)
|
|
|
|
UNEXPECTED_INITIALIZATION_CALL (0x33)
|
|
|
|
CACHE_MANAGER (0x34)
|
|
See the comment for FAT_FILE_SYSTEM (0x23)
|
|
|
|
NO_MORE_IRP_STACK_LOCATIONS (0x35)
|
|
PARAMETERS
|
|
1 - Address of the IRP
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - Address of the device object
|
|
|
|
DESCRIPTION
|
|
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.
|
|
|
|
|
|
NO_MORE_SYSTEM_PTES (0x3F)
|
|
PARAMETERS
|
|
1 - PTE Type (0 - system expansion, 1 nonpaged pool expansion)
|
|
2 - Requested size
|
|
3 - Total free system PTEs
|
|
4 - Total system PTEs
|
|
|
|
DESCRIPTION
|
|
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 Management\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)
|
|
|
|
PARAMETERS
|
|
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
|
|
|
|
DESCRIPTION
|
|
No component should ever ask for must-succeed pool as if there is none left,
|
|
the system crashes. Instead, components should ask for normal pool and
|
|
gracefully handle the scenario where the pool is temporarily empty. This
|
|
bugcheck definitely reveals a bug in the caller (use kb to identify the caller).
|
|
In addition, the fact that the pool is empty may be either a transient condition
|
|
or possibly a leak in another component (distinguish between the 2 cases by
|
|
following the directions below).
|
|
|
|
Type kb to show the calling stack.
|
|
Type !vm 1 to display total pool usage.
|
|
Then type !poolused 2 to display per-tag nonpaged pool usage.
|
|
Then type !poolused 4 to display per-tag paged pool usage.
|
|
The crash should be looked at by the tag owner that is consuming the most pool.
|
|
|
|
ATDISK_DRIVER_INTERNAL (0x42)
|
|
|
|
NO_SUCH_PARTITION (0x43)
|
|
|
|
MULTIPLE_IRP_COMPLETE_REQUESTS (0x44)
|
|
PARAMETERS
|
|
1 - Address of the IRP
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - Pointer to the IRP
|
|
2 - Cancel routine set by the driver.
|
|
|
|
DESCRIPTION
|
|
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. The cancel routine
|
|
parameter will provide a clue as to which driver or stack is the culprit.
|
|
|
|
PAGE_FAULT_WITH_INTERRUPTS_OFF (0x49)
|
|
|
|
IRQL_GT_ZERO_AT_SYSTEM_SERVICE (0x4A)
|
|
|
|
Returning to usermode from a system call at an IRQL > PASSIVE_LEVEL.
|
|
PARAMETERS
|
|
1 - Address of system function (system call routine)
|
|
2 - Current IRQL
|
|
3 - 0
|
|
4 - 0
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
x221 - This means that a driver is corrupt, or a system DLL was
|
|
detected to be corrupt.
|
|
|
|
Safeboot or boot an alternate OS (or reinstall)
|
|
and then 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 the I/O path to the file.
|
|
|
|
NO_PAGES_AVAILABLE (0x4D)
|
|
PARAMETERS
|
|
1 - Total number of dirty pages
|
|
2 - Number of dirty pages destined for the pagefile(s).
|
|
3 - Internal flags.
|
|
4 - Most recent modified write error status.
|
|
|
|
DESCRIPTION
|
|
No free pages available to continue operations.
|
|
If kernel debugger available "!vm 3".
|
|
|
|
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
|
|
"!vm 3" 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 0 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.
|
|
|
|
If the problem cannot be found, then try booting with /DEBUG and a kernel
|
|
debugger attached, so if it reproduces, a debug session can be initiated
|
|
to identify the cause.
|
|
|
|
PFN_LIST_CORRUPT (0x4E)
|
|
PARAMETERS
|
|
1 -
|
|
VALUES:
|
|
1 : A list head was corrupt
|
|
2 - ListHead value which was corrupt
|
|
3 - number of pages available
|
|
4 - 0
|
|
2 : A list entry was corrupt
|
|
2 - entry in list being removed
|
|
3 - highest physical page number
|
|
4 - reference count of entry being removed
|
|
7 : A driver has unlocked a page more times than it locked it
|
|
2 - page frame number
|
|
3 - current share count
|
|
4 - 0
|
|
0x8F : The free or zeroed page listhead is corrupt
|
|
2 - new page
|
|
3 - old page
|
|
4 - 0
|
|
0x99 : A PTE or PFN is corrupt
|
|
2 - page frame number
|
|
3 - current page state
|
|
4 - 0
|
|
END_VALUES
|
|
|
|
|
|
DESCRIPTION
|
|
Typically caused by drivers passing bad memory descriptor lists (ie: calling
|
|
MmUnlockPages twice with the same list, etc). If a kernel debugger is
|
|
available get the stack trace.
|
|
|
|
|
|
NDIS_INTERNAL_ERROR (0x4F)
|
|
|
|
PAGE_FAULT_IN_NONPAGED_AREA (0x50)
|
|
PARAMETERS
|
|
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 - (reserved)
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - (reserved)
|
|
2 - (reserved)
|
|
3 - depends on where Windows bugchecked, may be pointer to hive
|
|
4 - depends on where Windows bugchecked, may be return code of
|
|
HvCheckHive if the hive is corrupt.
|
|
|
|
DESCRIPTION
|
|
Something has gone badly wrong with the registry. If a kernel debugger
|
|
is available, get a stack trace. 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.
|
|
|
|
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 (0x23)
|
|
|
|
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 Pentium (or higher) compatible processor.
|
|
|
|
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)
|
|
|
|
PARAMETERS
|
|
1 - (reserved)
|
|
2 - location selector
|
|
3 - NT status code
|
|
|
|
DESCRIPTION
|
|
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
|
|
very little 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)
|
|
PARAMETERS
|
|
1 - Indicates the NT status code that caused the failure.
|
|
2 - (reserved)
|
|
|
|
REFMON_INITIALIZATION_FAILED (0x6C)
|
|
|
|
SESSION1_INITIALIZATION_FAILED (0x6D)
|
|
1 - Indicates the NT status code that caused the failure.
|
|
|
|
DESCRIPTION
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the point during
|
|
initialization when the failure was detected.
|
|
|
|
SESSION2_INITIALIZATION_FAILED (0x6E)
|
|
PARAMETERS
|
|
1 - Indicates the NT status code that tripped Windows into thinking
|
|
that initialization failed.
|
|
|
|
DESCRIPTION
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the point during
|
|
initialization when the failure was detected.
|
|
|
|
SESSION3_INITIALIZATION_FAILED (0x6F)
|
|
PARAMETERS
|
|
1 - Indicates the NT status code that tripped Windows into thinking
|
|
that initialization failed.
|
|
|
|
DESCRIPTION
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the point during
|
|
initialization when the failure was detected.
|
|
|
|
SESSION4_INITIALIZATION_FAILED (0x70)
|
|
PARAMETERS
|
|
1 - Indicates the NT status code that tripped Windows into thinking
|
|
that initialization failed.
|
|
|
|
DESCRIPTION
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the point during
|
|
initialization when the failure was detected.
|
|
|
|
SESSION5_INITIALIZATION_FAILED (0x71)
|
|
PARAMETERS
|
|
1 - Indicates the NT status code that tripped Windows into thinking
|
|
that initialization failed.
|
|
|
|
DESCRIPTION
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the point during
|
|
initialization when the failure was detected.
|
|
|
|
ASSIGN_DRIVE_LETTERS_FAILED (0x72)
|
|
|
|
CONFIG_LIST_FAILED (0x73)
|
|
Indicates that one of the core system hives cannot be linked in the
|
|
registry tree. The hive is valid, it was loaded OK. Examine the 2nd
|
|
bugcheck argument to see why the hive could not be linked in the
|
|
registry tree.
|
|
|
|
PARAMETERS
|
|
1 - 1
|
|
2 - Indicates the NT status code that tripped Windows into
|
|
thinking that it had failed to load the hive.
|
|
3 - Index of hive in hivelist
|
|
4 - Pointer to UNICODE_STRING containing filename of hive
|
|
|
|
DESCRIPTION
|
|
This can be either SAM, SECURITY, SOFTWARE or DEFAULT. One common reason
|
|
for this to happen is if you are out of disk space on the system drive
|
|
(in which case param 2 is 0xC000017D - STATUS_NO_LOG_SPACE) or an attempt
|
|
to allocate pool has failed (in which case param 2 is 0xC000009A -
|
|
STATUS_INSUFFICIENT_RESOURCES). Other status codes must be individually
|
|
investigated.
|
|
|
|
|
|
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.
|
|
|
|
PARAMETERS
|
|
1 - (reserved)
|
|
2 - (reserved)
|
|
3 - (reserved)
|
|
4 - usually the NT status code.
|
|
|
|
CANNOT_WRITE_CONFIGURATION (0x75)
|
|
|
|
This will result if the SYSTEM hive file cannot be converted to a
|
|
mapped file. This usually happens if the system is out of pool and
|
|
we cannot reopen the hive.
|
|
|
|
PARAMETERS
|
|
1 - 1
|
|
2 - Indicates the NT status code that tripped Windows into
|
|
thinking that it had failed to convert the hive.
|
|
|
|
DESCRIPTION
|
|
Normally you shouldn't see this as the conversion happens at early
|
|
during system initialization, so enough pool should be available.
|
|
|
|
PROCESS_HAS_LOCKED_PAGES (0x76)
|
|
PARAMETERS
|
|
1 - 0
|
|
2 - process address
|
|
3 - number of locked pages
|
|
4 - pointer to driver stacks (if enabled) or 0 if not.
|
|
|
|
DESCRIPTION
|
|
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 (0xCB) - which can identify the
|
|
offending driver(s).
|
|
|
|
KERNEL_STACK_INPAGE_ERROR (0x77)
|
|
PARAMETERS
|
|
1 - status code
|
|
2 - i/o status code
|
|
3 - page file number
|
|
4 - offset into page file
|
|
|
|
1 - status code
|
|
VALUES:
|
|
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 : (page was retrieved from disk)
|
|
2 - value found in stack where signature should be
|
|
3 - 0
|
|
4 - address of signature on kernel stack
|
|
|
|
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
|
|
END_VALUES
|
|
|
|
|
|
DESCRIPTION
|
|
The requested page of kernel data could not be read in. Caused by
|
|
bad block in paging file or disk controller error.
|
|
|
|
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)
|
|
PARAMETERS
|
|
1 - type of mismatch
|
|
VALUES:
|
|
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
|
|
|
|
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
|
|
|
|
3:
|
|
The loader (ntldr) and hal versions mismatch.
|
|
2 - Size of the loader parameter extension
|
|
3 - MajorVersion of the loader parameter extension
|
|
4 - MinorVersion of the loader parameter extension
|
|
|
|
END_VALUES
|
|
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
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
|
|
|
|
DESCRIPTION
|
|
The requested page of kernel data could not be read in. Typically caused by
|
|
a bad block in the 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.
|
|
|
|
If the error status is 0xC000009A, then it means the request failed because
|
|
a filesystem failed to make forward progress.
|
|
|
|
|
|
|
|
|
|
INACCESSIBLE_BOOT_DEVICE (0x7B)
|
|
PARAMETERS
|
|
1 - Pointer to the device object or Unicode string of ARC name
|
|
|
|
DESCRIPTION
|
|
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;
|
|
PWSTR 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_NDIS_DRIVER (0x7C)
|
|
|
|
This is the NDIS Driver Bugcheck for Windows Server 2003 and later.
|
|
For Windows 2000 and Windows XP, see 0xD2, BUGCODE_ID_DRIVER.
|
|
|
|
PARAMETERS
|
|
1 - NDIS BugCheck Code
|
|
VALUES:
|
|
1 : Driver called NdisMAllocateSharedMemory at raised IRQL
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The length of the requested shared memory
|
|
4 - The current IRQL
|
|
2 : During a call to NdisMAllocateSharedMemory, NDIS detected
|
|
that a previously allocated shared memory page has been
|
|
corrupted.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The shared memory page that was corrupted.
|
|
4 - A pointer to a NDIS_WRAPPER_CONTEXT that keeps
|
|
track of shared memory allocations by the driver.
|
|
3 : A Driver called NdisMFreeSharedMemory(Async) with a shared
|
|
memory pointer that has already been freed.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The page that this shared was allocated from.
|
|
4 - The virtual address of the shared memory.
|
|
4 : [Only enabled on special instrumented NDIS.] AddDevice was
|
|
called with a driver that is not on the list of drivers
|
|
that are registered with NDIS.
|
|
2 - A pointer to NDIS_M_DRIVER_BLOCK.
|
|
3 - The driver object. (A pointer to DRIVER_OBJECT)
|
|
4 - Not used
|
|
5 : An Ethernet driver indicated receiving a packet using a
|
|
packet descriptor that is currently in use by protocol
|
|
stack. (Caught by checking stack packet location)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The packet descriptor used by the driver. Use
|
|
!ndiskd.pkt on this pointer for more info.
|
|
4 - A pointer to the packet array that contained this
|
|
packet descriptor. (not much of a use)
|
|
6 : An Ethernet driver indicated receiving a packet using a
|
|
packet descriptor that is currently in use by protocol
|
|
stack. (caught by checking packet reference count)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The packet descriptor used by the driver. Use
|
|
!ndiskd.pkt on this pointer for more info.
|
|
4 - A pointer to the packet array that contained this
|
|
packet descriptor. (not much of a use)
|
|
7 : A FDDI driver indicated receiving a packet using a packet
|
|
descriptor that is currently in use by protocol stack.
|
|
(caught by checking packet reference count)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The packet descriptor used by the driver. Use
|
|
!ndiskd.pkt on this pointer for more info.
|
|
4 - A pointer to the packet array that contained this
|
|
packet descriptor. (not much of a use)
|
|
8 : A Miniport did not deregister its interrupt during the halt
|
|
process.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to NDIS_MINIPORT_INTERRUP.
|
|
4 - Not used.
|
|
9 : A Miniport halted without successfully canceling all its
|
|
timers.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to miniport's timer queue. type:
|
|
NDIS_MINIPORT_TIMER.
|
|
4 - Not used.
|
|
0xA : A miniport driver is getting unloaded prematurely.
|
|
2 - A pointer to NDIS_M_DRIVER_BLOCK.
|
|
3 - The driver object. (A pointer to DRIVER_OBJECT).
|
|
4 - The ref count for the miniport driver.
|
|
0xB : A Miniport failed initialization without deregistering
|
|
its interrupt.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to NDIS_MINIPORT_INTERRUP.
|
|
4 - Not used.
|
|
0xC : A Miniport failed initialization without successfully
|
|
canceling all its timers.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to miniport's timer queue. type:
|
|
NDIS_MINIPORT_TIMER.
|
|
4 - Not used.
|
|
0xD : A Miniport did not deregister its interrupt during the
|
|
halt process. (halt called from initialize routine after
|
|
miniport returned success from its initialize handler)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to NDIS_MINIPORT_INTERRUP.
|
|
4 - Not used.
|
|
0xE : A Miniport halted without successfully canceling all its
|
|
timers. (halt called from initialize routine after
|
|
miniport returned success from its initialize handler)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to miniport's timer queue. type:
|
|
NDIS_MINIPORT_TIMER.
|
|
4 - Not used.
|
|
0xF : A Miniport driver is calling NdisMResetComplete without
|
|
any pending reset request.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - Reset status.
|
|
4 - AddressingReset BOOLEAN. (not much of a use).
|
|
0x10 : After resuming from a low power state, a Miniport failed
|
|
initialization without deregistering its interrupt.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to NDIS_MINIPORT_INTERRUP.
|
|
4 - Not used.
|
|
0x11 : After resuming from a low power state, a Miniport failed
|
|
initialization without successfully canceling all its
|
|
timers.
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - A pointer to miniport's timer queue. type:
|
|
NDIS_MINIPORT_TIMER.
|
|
4 - Not used.
|
|
0x12 : A miniport driver indicated receiving a packet using a
|
|
packet descriptor that is currently in use by protocol
|
|
stack. (caught by checking packet reference count)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The packet descriptor used by the driver. Use
|
|
!ndiskd.pkt on this pointer for more info.
|
|
4 - A pointer to the packet array that contained this
|
|
packet descriptor. (not much of a use)
|
|
0x13 : A Token-Ring miniport driver indicated receiving a
|
|
packet using a packet descriptor that is currently in
|
|
use by protocol stack. (caught by checking packet
|
|
reference count)
|
|
2 - A pointer to Miniport block. !ndiskd.miniport on
|
|
this pointer for more info.
|
|
3 - The packet descriptor used by the driver. Use
|
|
!ndiskd.pkt on this pointer for more info.
|
|
4 - A pointer to the packet array that contained this
|
|
packet descriptor. (not much of a use)
|
|
END_VALUES
|
|
|
|
|
|
INSTALL_MORE_MEMORY (0x7D)
|
|
PARAMETERS
|
|
1 - Number of physical pages found
|
|
2 - Lowest physical page
|
|
3 - Highest physical page
|
|
4 - 0
|
|
|
|
DESCRIPTION
|
|
Not enough memory to boot Windows.
|
|
|
|
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E)
|
|
PARAMETERS
|
|
1 - The exception code that was not handled
|
|
VALUES
|
|
0x80000002: (STATUS_DATATYPE_MISALIGNMENT) An unaligned data reference was encountered.
|
|
The trap frame will supply additional information.
|
|
0x80000003: This means a hard coded breakpoint or assertion was hit, but this system was booted
|
|
/NODEBUG. This is not supposed to happen as developers should never have
|
|
hardcoded breakpoints in retail code, but ...
|
|
If this happens, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
END_VALUES
|
|
2 - The address that the exception occurred at
|
|
3 - Exception Record Address
|
|
4 - Context Record Address
|
|
|
|
DESCRIPTION
|
|
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.
|
|
|
|
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (0x1000007E)
|
|
PARAMETERS
|
|
1 - The exception code that was not handled
|
|
2 - The address that the exception occurred at
|
|
3 - Exception Record Address
|
|
4 - Context Record Address
|
|
|
|
DESCRIPTION
|
|
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 is not supposed to happen as developers should never have
|
|
hardcoded breakpoints in retail code, but ...
|
|
If this happens, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
|
|
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
|
|
that an unaligned data reference was encountered. The trap frame will
|
|
supply additional information.
|
|
|
|
UNEXPECTED_KERNEL_MODE_TRAP (0x7F)
|
|
|
|
This means a trap occurred 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. Here is a *portion* of those codes:
|
|
|
|
PARAMETERS
|
|
1 - x86 trap number
|
|
VALUES:
|
|
0: EXCEPTION_DIVIDED_BY_ZERO
|
|
1: EXCEPTION_DEBUG
|
|
2: EXCEPTION_NMI
|
|
3: EXCEPTION_INT3
|
|
5: EXCEPTION_BOUND_CHECK
|
|
6: EXCEPTION_INVALID_OPCODE
|
|
7: EXCEPTION_NPX_NOT_AVAILABLE
|
|
8: EXCEPTION_DOUBLE_FAULT
|
|
9: EXCEPTION_NPX_OVERRUN
|
|
A: EXCEPTION_INVALID_TSS
|
|
B: EXCEPTION_SEGMENT_NOT_PRESENT
|
|
C: EXCEPTION_STACK_FAULT
|
|
D: EXCEPTION_GP_FAULT
|
|
F: EXCEPTION_RESERVED_TRAP
|
|
10: EXCEPTION_NPX_ERROR
|
|
11: EXCEPTION_ALIGNMENT_CHECK
|
|
END_VALUES
|
|
|
|
DESCRIPTION
|
|
If kv shows a taskGate
|
|
use .tss on the part before the colon, then kv.
|
|
Else if kv shows a trapframe
|
|
use .trap on that value
|
|
Else
|
|
.trap on the appropriate frame will show where the trap was taken
|
|
(on x86, this will be the ebp that goes with the procedure KiTrap)
|
|
Endif
|
|
|
|
kb will then show the corrected stack.
|
|
|
|
|
|
|
|
UNEXPECTED_KERNEL_MODE_TRAP_M (0x1000007F)
|
|
|
|
This means a trap occurred 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. Here is a *portion* of those codes:
|
|
|
|
PARAMETERS
|
|
1 - x86 trap number
|
|
VALUES:
|
|
0: EXCEPTION_DIVIDED_BY_ZERO
|
|
1: EXCEPTION_DEBUG
|
|
2: EXCEPTION_NMI
|
|
3: EXCEPTION_INT3
|
|
5: EXCEPTION_BOUND_CHECK
|
|
6: EXCEPTION_INVALID_OPCODE
|
|
7: EXCEPTION_NPX_NOT_AVAILABLE
|
|
8: EXCEPTION_DOUBLE_FAULT
|
|
9: EXCEPTION_NPX_OVERRUN
|
|
A: EXCEPTION_INVALID_TSS
|
|
B: EXCEPTION_SEGMENT_NOT_PRESENT
|
|
C: EXCEPTION_STACK_FAULT
|
|
D: EXCEPTION_GP_FAULT
|
|
F: EXCEPTION_RESERVED_TRAP
|
|
10: EXCEPTION_NPX_ERROR
|
|
11: EXCEPTION_ALIGNMENT_CHECK
|
|
END_VALUES
|
|
|
|
DESCRIPTION
|
|
If kv shows a taskGate
|
|
use .tss on the part before the colon, then kv.
|
|
Else if kv shows a trapframe
|
|
use .trap on that value
|
|
Else
|
|
.trap on the appropriate frame will show where the trap was taken
|
|
(on x86, this will be the ebp that goes with the procedure KiTrap)
|
|
Endif
|
|
|
|
kb will then show the corrected stack.
|
|
|
|
|
|
NMI_HARDWARE_FAILURE (0x80)
|
|
|
|
This is typically due to a hardware malfunction. The hardware supplier should
|
|
be called.
|
|
|
|
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.
|
|
PARAMETERS
|
|
1 -
|
|
VALUES:
|
|
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
|
|
Windows cannot communicate with.
|
|
|
|
3 - Status code from NT API call, if appropriate.
|
|
|
|
2 - What failed:
|
|
VALUES:
|
|
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
|
|
END_VALUES
|
|
|
|
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 Windows is.
|
|
|
|
3: Keyboard initialization failed. NO LONGER A BUGCHECK CODE.
|
|
There are now 2 error screens for the two different possible errors
|
|
that can occur here.
|
|
This may indicate that the disk containing the keyboard driver
|
|
(i8042prt.sys or kbdclass.sys) is damaged, or that the machine has
|
|
keyboard hardware Windows cannot communicate with.
|
|
|
|
It may also mean that the keyboard layout dll could not be loaded.
|
|
|
|
2 - What failed:
|
|
VALUES:
|
|
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).
|
|
END_VALUES
|
|
|
|
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.
|
|
|
|
END_VALUES
|
|
|
|
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.
|
|
|
|
PARAMETERS
|
|
|
|
1 - Disk Signature from MBR.
|
|
2 - MBR checksum calculated by osloader.
|
|
3 - MBR checksum calculated by system.
|
|
|
|
KERNEL_MODE_EXCEPTION_NOT_HANDLED (0x8E)
|
|
PARAMETERS
|
|
1 - The exception code that was not handled
|
|
2 - The address that the exception occurred at
|
|
3 - Trap Frame
|
|
|
|
DESCRIPTION
|
|
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 is not supposed to happen as developers should never have
|
|
hardcoded breakpoints in retail code, but ...
|
|
If this happens, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
|
|
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
|
|
that an unaligned data reference was encountered. The trap frame will
|
|
supply additional information.
|
|
|
|
|
|
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (0x1000008E)
|
|
PARAMETERS
|
|
1 - The exception code that was not handled
|
|
2 - The address that the exception occurred at
|
|
3 - Trap Frame
|
|
|
|
DESCRIPTION
|
|
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 is not supposed to happen as developers should never have
|
|
hardcoded breakpoints in retail code, but ...
|
|
If this happens, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
|
|
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
|
|
that an unaligned data reference was encountered. The trap frame will
|
|
supply additional information.
|
|
|
|
|
|
PP0_INITIALIZATION_FAILED (0x8F)
|
|
|
|
This message occurs if phase 0 initialization of the kernel-mode Plug and
|
|
Play Manager failed.
|
|
|
|
PP1_INITIALIZATION_FAILED (0x90)
|
|
|
|
This message occurs if phase 1 initialization of the kernel-mode Plug and
|
|
Play Manager failed. This is where most of the initialization is done,
|
|
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.
|
|
|
|
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.
|
|
|
|
PARAMETERS
|
|
|
|
1 - The handle that NtClose was called with.
|
|
|
|
2 -
|
|
VALUES
|
|
0 : means a protected handle was closed.
|
|
1 : means an invalid handle was closed.
|
|
END_VALUES
|
|
|
|
KERNEL_STACK_LOCKED_AT_EXIT (0x94)
|
|
|
|
This message occurs when a thread exits while its 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 cause 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.
|
|
|
|
In an attempt to help identify the guilty driver, this bugcheck assumes the
|
|
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
|
|
parameter 4 below.
|
|
|
|
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.
|
|
|
|
|
|
BOUND_IMAGE_UNSUPPORTED (0x97)
|
|
|
|
END_OF_NT_EVALUATION_PERIOD (0x98)
|
|
|
|
Your Windows System is an evaluation unit with an expiration date. The trial
|
|
period is over.
|
|
|
|
PARAMETERS
|
|
|
|
1 - The low order 32 bits of your installation date
|
|
2 - The high order 32 bits of your installation 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 (0x9A)
|
|
|
|
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 Windows.
|
|
|
|
PARAMETERS
|
|
1 - Violation type
|
|
VALUES:
|
|
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
|
|
|
|
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
|
|
|
|
0xA : An NTW system was converted to an NTS system
|
|
|
|
0xB : Reference of setup key failed
|
|
2 - status code associated with the change failure
|
|
|
|
0xC : Reference of product options key failed
|
|
2 - status code associated with the change failure
|
|
|
|
0xD : Open of ProductOptions in worker thread failed
|
|
2 - status code associated with the failure
|
|
|
|
0xF : Open of setup key failed
|
|
2 - status code associated with the failure
|
|
|
|
0x10 : Failure occurred in the setup key worker thread
|
|
2 - status code associated with the failure
|
|
3 - 0 means set value failed, 1 means change notify failed
|
|
|
|
0x11 : Failure occurred 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
|
|
|
|
0x12 : Could not open the LicenseInfoSuites key for the suite
|
|
2 - status code associated with the failure
|
|
|
|
0x13 : Could not query the LicenseInfoSuites key for the suite
|
|
2 - status code associated with the failure
|
|
|
|
0x14 : Could not allocate memory
|
|
2 - size of memory alllocation
|
|
|
|
0x15 : Could not re-set the ConcurrentLimit value for the suite key
|
|
2 - status code associated with the failure
|
|
|
|
0x16 : Could not open the license key for a suite product
|
|
2 - status code associated with the failure
|
|
|
|
0x17 : Could not re-set the ConcurrentLimit value for a suite product
|
|
2 - status code associated with the failure
|
|
|
|
0x18 : Could not start the change notify for the LicenseInfoSuites
|
|
2 - status code associated with the open failure
|
|
|
|
0x19 : A suite is running on a system that must be pdc
|
|
|
|
0x20 : Failure occurred when enumerating the suites
|
|
2 - status code associated with the failure
|
|
|
|
END_VALUES
|
|
|
|
|
|
UDFS_FILE_SYSTEM (0x9B)
|
|
|
|
If you see UdfExceptionFilter 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 helpful stack
|
|
trace.
|
|
|
|
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 - Address of MCA_EXCEPTION structure
|
|
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 of MCA_EXCEPTION structure
|
|
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
|
|
|
|
IA64 Processors
|
|
|
|
1 - Bugcheck Type
|
|
1 - MCA_ASSERT
|
|
2 - MCA_GET_STATEINFO
|
|
SAL returned an error for SAL_GET_STATEINFO while processing MCA.
|
|
3 - MCA_CLEAR_STATEINFO
|
|
SAL returned an error for SAL_CLEAR_STATEINFO while processing MCA.
|
|
4 - MCA_FATAL
|
|
FW reported a fatal MCA.
|
|
5 - MCA_NONFATAL
|
|
SAL reported a recoverable MCA and we don't support currently
|
|
support recovery or SAL generated an MCA and then couldn't
|
|
produce an error record.
|
|
0xB - INIT_ASSERT
|
|
0xC - INIT_GET_STATEINFO
|
|
SAL returned an error for SAL_GET_STATEINFO while processing INIT event.
|
|
0xD - INIT_CLEAR_STATEINFO
|
|
SAL returned an error for SAL_CLEAR_STATEINFO while processing INIT event.
|
|
0xE - INIT_FATAL
|
|
Not used.
|
|
2 - Address of log
|
|
3 - Size of log
|
|
4 - Error code in the case of x_GET_STATEINFO or x_CLEAR_STATEINFO
|
|
|
|
USER_MODE_HEALTH_MONITOR (0x9E)
|
|
|
|
One or more critical user mode components failed to satisfy a health check.
|
|
|
|
Hardware mechanisms such as watchdog timers can detect that basic kernel
|
|
services are not executing. However, resource starvation issues, including
|
|
memory leaks, lock contention, and scheduling priority misconfiguration,
|
|
may block critical user mode components without blocking DPCs or
|
|
draining the nonpaged pool.
|
|
|
|
Kernel components can extend watchdog timer functionality to user mode
|
|
by periodically monitoring critical applications. This bugcheck indicates
|
|
that a user mode health check failed in a manner such that graceful
|
|
shutdown is unlikely to succeed. It restores critical services by
|
|
rebooting and/or allowing application failover to other servers.
|
|
|
|
PARAMETERS
|
|
1 - Process that failed to satisfy a health check within the
|
|
configured timeout
|
|
2 - Health monitoring timeout (seconds)
|
|
|
|
DRIVER_POWER_STATE_FAILURE (0x9F)
|
|
|
|
A driver is causing an inconsistent power state.
|
|
|
|
PARAMETERS
|
|
|
|
1 - SubCode
|
|
VALUES:
|
|
1 : The device object is being freed which still has an
|
|
outstanding power request which it has not completed
|
|
2 - DeviceObject
|
|
2 : The device object completed the irp for the system power
|
|
state request, but failed to call PoStartNextPowerIrp
|
|
2 - Optional Target device's DEVICE_OBJECT
|
|
3 - DeviceObject
|
|
4 - Optional DriverObject
|
|
0x500 : The device object completed the irp for the system power
|
|
state request, but failed to call PoStartNextPowerIrp.
|
|
3 - Optional Target device's DEVICE_OBJECT
|
|
4 - DeviceObject
|
|
END_VALUES
|
|
|
|
|
|
INTERNAL_POWER_ERROR (0xA0)
|
|
|
|
The power policy manager experienced a fatal error.
|
|
|
|
PARAMETERS:
|
|
|
|
1 -
|
|
VALUES:
|
|
1 : Error Handling power IRP.
|
|
2 -
|
|
VALUES:
|
|
1 : A device has overrun its maximum number of reference counts.
|
|
3 - maximum number of references allowed.
|
|
2 : Too many inrush power irps have been queue.
|
|
3 - maximum number of pending irps allowed.
|
|
3 : Too many inrush power irps have been queue.
|
|
3 - maximum number of pending irps allowed.
|
|
4 : Too many inrush power irps have been queue.
|
|
3 - maximum number of pending irps allowed.
|
|
5 : Power IRP has been sent to a passive level deviceobject.
|
|
END_VALUES
|
|
2 : (POP_INTERNAL) An internal failure has occurred while attempting to process
|
|
a power event. To debug this, dump the stack and look for the
|
|
function ntoskrnl!_PopInternalError. The first argument is
|
|
(error_code << 16) | __LINE__. If the caller is PopExceptionFilter, then
|
|
the first argument to this function is of type PEXCEPTION_POINTERS.
|
|
In the debugger, type 'dt nt!_EXCEPTION_POINTERS <argument>'.
|
|
Then type '.cxr <value of context record from the previous command>'.
|
|
All subsequent debugger commands will show you the actual
|
|
source of the error. Start with a stack trace by typing 'kb'.
|
|
3 : The checksum for a hibernation context page does not match.
|
|
2 - Expected checksum
|
|
3 - Actual checksum
|
|
4 - Linenumber of the failure.
|
|
4 : The checksum for a page about to be written to the hibernation file
|
|
does not match its expected checksum.
|
|
2 - Expected checksum
|
|
3 - Actual checksum
|
|
4 - Linenumber of the failure.
|
|
5 : An unknown shutdown code has been sent to the system shutdown handler.
|
|
|
|
7 : (POP_MISC) Unhandled exception. To debug this, dump the stack. Look
|
|
for the function ntoskrnl!PopExceptionFilter. The first
|
|
argument to this function is of type PEXCEPTION_POINTERS.
|
|
In the debugger, type 'dt nt!_EXCEPTION_POINTERS <argument>'.
|
|
Then type '.cxr <value of context record from the previous command>'.
|
|
All subsequent debugger commands will show you the actual
|
|
source of the error. Start with a stack trace by typing 'kb'.
|
|
8 : (POP_SYS) A fatal error has occured while processing a system power event.
|
|
2 -
|
|
VALUES:
|
|
0x100 : An unknown device type is being processed.
|
|
3 - DEVICE_OBJECT
|
|
4 - POWER_CHANNEL_SUMMARY
|
|
END_VALUES
|
|
|
|
0x101 : Unhandled exception occured while processing a system power event.
|
|
3 - ExceptionPointer. To debug this, in the debugger type:
|
|
'dt nt!_EXCEPTION_POINTERS <argument>'. Then type:
|
|
'.cxr <value of context record from the previous command>'.
|
|
All subsequent debugger commands will show you the actual
|
|
source of the error. Start with a stack trace by typing 'kb'.
|
|
|
|
|
|
0x102 : Hibernation orking buffer size is not page aligned
|
|
3 - DUMP_INITIALIZATION_CONTEXT
|
|
4 - POP_HIBER_CONTEXT
|
|
0x103 : All working pages have failed to be accounted for during the hibernation process.
|
|
3 - POP_HIBER_CONTEXT
|
|
0x104 : An attempt was made to map internal hibernate memory while
|
|
the internal memory structures were locked.
|
|
3 - POP_HIBER_CONTEXT
|
|
0x105 : An attempt was made to map internal hibernate memory with
|
|
an unsupported memory type flag.
|
|
3 - POP_HIBER_CONTEXT
|
|
0x106 : A memory descriptor list was created during the hibernation process which
|
|
describes memory that is not paged-aligned.
|
|
3 - MDL
|
|
0x107 : A data mismatch has occurred in the internal hibernation data
|
|
structures.
|
|
3 - POP_HIBER_CONTEXT
|
|
4 - PO_MEMORY_RANGE_ARRAY
|
|
0x108 : The disk subsystem failed to properly write part of the hibernation
|
|
file.
|
|
3 - POP_HIBER_CONTEXT
|
|
0x109 : The checksum for the processor state data does not match its
|
|
expected checksum.
|
|
3 - Expected checksum
|
|
4 - Actual checksum
|
|
0x10A : The disk subsystem failed to properly write part of the hibernation
|
|
file.
|
|
3 - POP_HIBER_CONTEXT
|
|
4 - NTSTATUS failure code
|
|
0x200 : An unknown device type is being checked for an idle state.
|
|
3 - DEVICE_OBJECT
|
|
4 - DEVICE_OBJECT_POWER_EXTENSION
|
|
0x300 : An unknown status was returned from a battery power IRP.
|
|
3 - DEVICE_OBJECT
|
|
4 - IRP
|
|
0x301 : The battery has entered an unknown state..
|
|
3 - DEVICE_OBJECT
|
|
4 - IRP
|
|
0x400 : A device has overrun its maximum number of reference counts.
|
|
3 - IO_STACK_LOCATION
|
|
4 - DEVICE_OBJECT
|
|
0x401 : Too many inrush power irps have been queue.
|
|
3 - Pending IRP list.
|
|
4 - DEVICE_OBJECT
|
|
0x402 : Too many inrush power irps have been queue.
|
|
3 - Pending IRP list.
|
|
4 - DEVICE_OBJECT
|
|
0x403 : Too many inrush power irps have been queue.
|
|
3 - Pending IRP list.
|
|
4 - DEVICE_OBJECT
|
|
0x404 : Power IRP has been sent to a passive level deviceobject.
|
|
3 - IO_STACK_LOCATION.
|
|
4 - DEVICE_OBJECT
|
|
0x500 : An unknown status was returned from a thermal power IRP.
|
|
3 - IRP
|
|
4 - DEVICE_OBJECT
|
|
|
|
END_VALUES
|
|
|
|
|
|
PCI_BUS_DRIVER_INTERNAL (0xA1)
|
|
|
|
The PCI Bus driver detected 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
|
|
guard against memory failures.
|
|
|
|
PARAMETERS
|
|
|
|
1 -
|
|
VALUES:
|
|
2 : Table page check failure
|
|
2 - IF PARAMETER 3 IS ZERO:
|
|
the page number in of the table page which failed
|
|
IF PARAMETER 3 IS NONZERO:
|
|
the page number with the failing page run index
|
|
3 - the index which failed to match the run (or zero)
|
|
|
|
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
|
|
END_VALUES
|
|
|
|
|
|
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
|
|
there is no way to tell.
|
|
|
|
|
|
|
|
CNSS_FILE_SYSTEM_FILTER (0xA4)
|
|
See the comment for FAT_FILE_SYSTEM (0x23)
|
|
|
|
ACPI_BIOS_ERROR (0xA5)
|
|
|
|
The ACPI Bios in the system is not fully compliant with the ACPI specification.
|
|
The first value indicates where the incompatibility lies:
|
|
|
|
PARAMETERS
|
|
|
|
1 -
|
|
VALUES:
|
|
|
|
1 : ACPI_ROOT_RESOURCES_FAILURE.
|
|
ACPI cannot find the SCI Interrupt vector in the resources handed
|
|
to it when ACPI is started.
|
|
|
|
2 - ACPI's deviceExtension
|
|
3 - ACPI's ResourceList
|
|
4 -
|
|
VALUES:
|
|
0 : No resource list found
|
|
1 : No IRQ resource found in list
|
|
END_VALUES
|
|
|
|
2 : ACPI_ROOT_PCI_RESOURCE_FAILURE
|
|
ACPI could not process the resource list for the PCI root buses
|
|
|
|
2 - The ACPI Extension for the PCI bus.
|
|
3 -
|
|
VALUES:
|
|
0 : ACPI cannot convert the BIOS' resource list into the proper
|
|
format. This probably represents a flaw in the BIOS' list
|
|
encoding procedure.
|
|
4 - Pointer to the QUERY_RESOURCES irp
|
|
1 : ACPI cannot convert the BIOS' resource list into the proper
|
|
format. This probably represents a flaw in the BIOS' list
|
|
encoding procedure.
|
|
4 - Pointer to the QUERY_RESOURCE_REQUIREMENTS irp
|
|
2 : ACPI found an empty resource list.
|
|
4 - 0
|
|
3 : ACPI could not find the current bus number in the CRS.
|
|
4 - Pointer to the PNP CRS descriptor
|
|
Other : Any other value is a pointer to the Resource List for PCI.
|
|
This indicates that there is an overlap between the list of
|
|
resources that PCI claims to decode and the list of memory
|
|
regions reported by the E820 BIOS interface.
|
|
4 - Pointer to the E820 Memory Table
|
|
END_VALUES
|
|
|
|
3 : 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.
|
|
|
|
2 - The ACPI Object that was being run
|
|
3 - return value from the interpreter
|
|
4 - Name of the control method (in ULONG format)
|
|
|
|
4 : ACPI_PRW_PACKAGE_EXPECTED_INTEGER
|
|
ACPI evaluated a _PRW and expected to find an integer as a
|
|
package element.
|
|
|
|
2 - The ACPI Extension for which the _PRW belongs to
|
|
3 - Pointer to the method
|
|
4 - The DataType returned (see amli.h)
|
|
|
|
5 : 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.
|
|
|
|
2 - The ACPI Extension for which the _PRW belongs to
|
|
3 - Pointer to the _PRW
|
|
4 - Number of elements in the _PRW
|
|
|
|
6 : ACPI_PRx_CANNOT_FIND_OBJECT
|
|
ACPI tried to find a named object named, but could not find it.
|
|
|
|
2 - The ACPI Extension for which the _PRx belongs to
|
|
3 - Pointer to the _PRx
|
|
4 - Pointer to the name of the object to look for
|
|
|
|
7 : ACPI_EXPECTED_BUFFER
|
|
ACPI evaluated a method and expected to receive a Buffer in return.
|
|
However, the method returned some other data type
|
|
|
|
2 - The ACPI Extension for which the method belongs to
|
|
3 - Pointer to the method
|
|
4 - The DataType returned (see amli.h)
|
|
|
|
8 : ACPI_EXPECTED_INTEGER
|
|
ACPI evaluated a method and expected to receive an Integer in return.
|
|
However, the method returned some other data type
|
|
|
|
2 - The ACPI Extension for which the method belongs to
|
|
3 - Pointer to the method
|
|
4 - The DataType returned (see amli.h)
|
|
|
|
9 : ACPI_EXPECTED_PACKAGE
|
|
ACPI evaluated a method and expected to receive a Package in return.
|
|
However, the method returned some other data type
|
|
|
|
2 - The ACPI Extension for which the method belongs to
|
|
3 - Pointer to the method
|
|
4 - 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
|
|
|
|
2 - The ACPI Extension for which the method belongs to
|
|
3 - Pointer to the method
|
|
4 - The DataType returned (see amli.h)
|
|
|
|
0xB : ACPI_EJD_CANNOT_FIND_OBJECT
|
|
ACPI cannot find the object referenced to by an _EJD string
|
|
|
|
2 - The ACPI Extension for which which the _EJD belongs to
|
|
3 - The status returned by the interpreter
|
|
4 - Name of the object ACPI is trying to find
|
|
|
|
0xC : ACPI_CLAIMS_BOGUS_DOCK_SUPPORT
|
|
ACPI provides faulty/insufficient information for dock support
|
|
|
|
2 - The ACPI Extension for which ACPI found a dock device
|
|
3 - Pointer to the _EJD method
|
|
4 -
|
|
VALUES:
|
|
0: Bios does not claim system is dockage
|
|
1: Duplicate device extensions for dock device
|
|
END_VALUES
|
|
|
|
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
|
|
|
|
2 - The ACPI Extension that ACPI needs the object for
|
|
3 - The (ULONG) name of the method ACPI looked for
|
|
4 -
|
|
VALUES:
|
|
0: Base Case
|
|
1: Conflict
|
|
END_VALUES
|
|
|
|
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
|
|
|
|
2 - The NS PowerResource that ACPI needs the object for
|
|
3 - The (ULONG) name of the method ACPI looked for
|
|
4 -
|
|
VALUES:
|
|
0: Base Case
|
|
END_VALUES
|
|
|
|
0xF : ACPI_PNP_RESOURCE_LIST_BUFFER_TOO_SMALL
|
|
ACPI could not parse the resource descriptor
|
|
2 - The current buffer that ACPI was parsing
|
|
3 - The buffer's tag
|
|
4 - 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.
|
|
2 - The ACPI Extension for which ACPI is trying to do the mapping
|
|
3 -
|
|
VALUES:
|
|
0 : The _PRx mapped back to a non-supported S-state
|
|
4 - The DEVICE_POWER_STATE (ie: x+1)
|
|
1 : ACPI cannot find a D-state to associate with the S-state
|
|
4 - The SYSTEM_POWER_STATE that is causing the problem
|
|
2 : The device claims to be able to wake the system when the
|
|
system is in this S-state, but the system doesn't actually
|
|
support this S-state.
|
|
4 - The SYSTEM_POWER_STATE that is causing the problem
|
|
END_VALUES
|
|
|
|
0x11 : ACPI_SYSTEM_CANNOT_START_ACPI
|
|
The system could not enter ACPI mode
|
|
|
|
2 -
|
|
VALUES:
|
|
0 : System could not initialize AML interpreter
|
|
1 : System could not find RSDT
|
|
2 : System could not allocate critical driver structures
|
|
3 : System could not load RSDT
|
|
4 : System could not load DDBs
|
|
5 : System cannot connect Interrupt vector
|
|
6 : SCI_EN never becomes set in PM1 Control Register
|
|
7 : Table checksum is incorrect
|
|
3 - Pointer to the table that had a bad checksum
|
|
4 - Creator Revision
|
|
8 : Failed to load DDB
|
|
3 - Pointer to the table that ACPI failed to load
|
|
4 - Creator Revision
|
|
9 : Unsupported Firmware Version
|
|
3 - FADT Version
|
|
0xA : System could not find MADT
|
|
0xB : System could not find any valid Local SAPIC structures in
|
|
the MADT
|
|
END_VALUES
|
|
|
|
0x14 : ACPI_PNP_RESOURCE_LIST_LENGTH_TOO_LARGE
|
|
ACPI could not parse the resource descriptor, the length exceeds
|
|
MAXULONG.
|
|
2 - The current buffer that ACPI was parsing
|
|
3 - The buffer's tag
|
|
4 - Pointer to a variable containing ULONGLONG length of the buffer
|
|
|
|
|
|
0x2001 : ACPI_FAILED_PIC_METHOD
|
|
ACPI tried to evaluate the PIC control method and but failed
|
|
|
|
2 - InterruptModel (Integer)
|
|
3 - return value from interpreter
|
|
4 - Pointer to the PIC control method
|
|
|
|
0x10001 : ACPI_CANNOT_ROUTE_INTERRUPTS
|
|
ACPI tried to do interrupt routing, but failed
|
|
|
|
2 - Pointer to the device object
|
|
3 - Pointer to the parent of the device object
|
|
4 - Pointer to the PRT
|
|
|
|
0x10002 : ACPI_PRT_CANNOT_FIND_LINK_NODE
|
|
ACPI could not find the link node referenced in a _PRT
|
|
(This code exists in Windows 2000, but is obsolete in XP)
|
|
|
|
2 - Pointer to the device object
|
|
3 - Pointer to the string name ACPI is looking for, but could not find.
|
|
4 - Pointer to the PRT. Dump this with !acpikd.nsobj <argument 4>
|
|
|
|
0x10003 : ACPI_PRT_CANNOT_FIND_DEVICE_ENTRY
|
|
ACPI could not find a mapping in the _PRT package for a device
|
|
(This code exists in Windows 2000, but is obsolete in XP)
|
|
|
|
2 - Pointer to the device object
|
|
3 - 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.
|
|
4 - Pointer to the PRT. Dump this with !acpikd.nsobj <argument 4>
|
|
|
|
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 generic format for a _PRT entry is 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.
|
|
(This code exists in Windows 2000, but is obsolete in XP)
|
|
|
|
2 - Pointer to the PRT object. Dump this with !acpikd.nsobj <argument 2>
|
|
3 - Pointer to the current PRT Element. This is an index into the PRT.
|
|
4 - 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
|
|
|
|
2 - 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.
|
|
2 - The vector that couldn't be found
|
|
|
|
0x20000 :
|
|
The PM_TMR_BLK entry in the Fixed ACPI Description Table doesn't
|
|
point to a working ACPI timer block.
|
|
2 - The I/O port in the Fixed Table
|
|
|
|
END_VALUES
|
|
|
|
DESCRIPTION
|
|
This bug check covers a great variety of ACPI problems. If a kernel debugger
|
|
is attached, use "!analyze -v". This command will analyze the precise problem,
|
|
and display whatever information is most useful for debugging the specific
|
|
error.
|
|
|
|
BAD_EXHANDLE (0xA7)
|
|
|
|
The kernel mode handle table detected an inconsistent handle table
|
|
entry state.
|
|
|
|
SESSION_HAS_VALID_POOL_ON_EXIT (0xAB)
|
|
PARAMETERS
|
|
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.
|
|
nonpaged allocations are in the upper half of this word,
|
|
paged allocations are in the lower half of this word.
|
|
|
|
DESCRIPTION
|
|
Caused by a session driver not freeing its pool allocations prior to a
|
|
session unload. This indicates a bug in win32k.sys, atmfd.dll,
|
|
rdpdd.dll or a video driver.
|
|
|
|
HAL_MEMORY_ALLOCATION (0xAC)
|
|
|
|
The HAL was unable to obtain memory 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.
|
|
|
|
PARAMETERS
|
|
1 - Allocation size.
|
|
2 - 0
|
|
3 - Pointer to string containing file name.
|
|
4 - (reserved)
|
|
|
|
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 an illegal operation and the stack track will lead to the offending
|
|
code and original DPC routine.
|
|
|
|
CHIPSET_DETECTED_ERROR (0xB9)
|
|
|
|
SESSION_HAS_VALID_VIEWS_ON_EXIT (0xBA)
|
|
PARAMETERS
|
|
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.
|
|
|
|
DESCRIPTION
|
|
Caused by a session driver not unmapping its mapped views prior to a
|
|
session unload. This indicates a bug in win32k.sys, atmfd.dll,
|
|
rdpdd.dll or a video driver.
|
|
|
|
NETWORK_BOOT_INITIALIZATION_FAILED (0xBB)
|
|
PARAMETERS
|
|
1 - the part of network initialization that failed
|
|
2 - the failure status
|
|
DESCRIPTION
|
|
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 - Windows sends IOCTLs to the redirector and
|
|
datagram receiver, then waits for the redirector to be ready. If it is not
|
|
ready within a certain period of time, initialization fails.
|
|
3 - failed sending the DHCP IOCTL to TCP - this is how Windows informs the
|
|
transport of its IP adress.
|
|
|
|
NETWORK_BOOT_DUPLICATE_ADDRESS (0xBC)
|
|
PARAMETERS
|
|
1 - the IP address, show as a hex DWORD. So an address aa.bb.cc.dd will
|
|
appear as 0xddccbbaa.
|
|
2 - the hardware address of the other machine.
|
|
3 - the hardware address of the other machine.
|
|
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.
|
|
DESCRIPTION
|
|
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.
|
|
|
|
Note: This bug check no longer exists in any version of Windows.
|
|
|
|
PARAMETERS
|
|
1 - hardware that was invalid
|
|
VALUES:
|
|
1 : Number of installed processors is less than before the hibernation
|
|
2 - number of processors before hibernation
|
|
3 - number of processors after hibernation
|
|
END_VALUES
|
|
|
|
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).
|
|
|
|
PARAMETERS
|
|
1 - Virtual address for the attempted write.
|
|
2 - PTE contents.
|
|
3 - (reserved)
|
|
4 - (reserved)
|
|
|
|
DESCRIPTION
|
|
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.
|
|
|
|
PARAMETERS
|
|
1 - Address of Mutex
|
|
2 - Thread
|
|
3 - 0
|
|
4 - (reserved)
|
|
|
|
SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (0xC1)
|
|
|
|
Special pool has detected memory corruption. Typically the current thread's
|
|
stack backtrace will reveal the guilty party.
|
|
|
|
PARAMETERS
|
|
4 - subclass of driver violation.
|
|
VALUES:
|
|
0x20 : caller is trying to free pool which is not allocated
|
|
1 - address trying to free
|
|
2 - (reserved)
|
|
3 - 0.
|
|
|
|
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 - (reserved)
|
|
|
|
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 - (reserved)
|
|
|
|
0x30 : caller is trying to allocate pool from an incorrect IRQL level
|
|
1 - current IRQL
|
|
2 - pool type
|
|
3 - number of bytes
|
|
|
|
0x31 : caller is trying to free pool from an incorrect IRQL level
|
|
1 - current IRQL
|
|
2 - pool type
|
|
3 - address trying to free
|
|
|
|
END_VALUES
|
|
|
|
|
|
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.
|
|
|
|
PARAMETERS
|
|
1 - type of pool violation the caller is guilty of.
|
|
VALUES:
|
|
|
|
0x0 : The caller is requesting a zero byte pool allocation.
|
|
Parameter 2 - zero.
|
|
Parameter 3 - the pool type being allocated.
|
|
Parameter 4 - the pool tag being used.
|
|
|
|
0x1 : Pool header has been corrupted
|
|
Parameter 2 - Pointer to pool header
|
|
Parameter 3 - First part of pool header contents
|
|
Parameter 4 - 0
|
|
|
|
0x2 : Pool header has been corrupted
|
|
Parameter 2 - Pointer to pool header
|
|
Parameter 3 - First part of pool header contents
|
|
Parameter 4 - 0
|
|
|
|
0x4 : Pool header has been corrupted
|
|
Parameter 2 - Pointer to pool header
|
|
Parameter 3 - First part of pool header contents
|
|
Parameter 4 - 0
|
|
|
|
0x6 : Attempt to free pool which was already freed
|
|
Parameter 2 - (reserved)
|
|
Parameter 3 - Pointer to pool header
|
|
Parameter 4 - Pool header contents
|
|
|
|
0x7 : Attempt to free pool which was already freed
|
|
Parameter 2 - (reserved)
|
|
Parameter 3 - Memory contents of the pool block
|
|
Parameter 4 - Pointer to pool header
|
|
|
|
0x8 : Attempt to allocate pool at invalid IRQL
|
|
Parameter 2 - Current IRQL
|
|
Parameter 3 - Pool type
|
|
Parameter 4 - Size of allocation
|
|
|
|
0x9 : Attempt to free pool at invalid IRQL
|
|
Parameter 2 - Current IRQL
|
|
Parameter 3 - Pool type
|
|
Parameter 4 - Address of pool
|
|
|
|
0xA : Attempt to free some other component's protected pool.
|
|
Parameter 2 - Address of pool
|
|
Parameter 3 - Allocator's tag
|
|
Parameter 4 - Tag being used in the attempted free.
|
|
|
|
0xB/0xC/0xD : Attempt to release quota on a corrupted pool allocation.
|
|
Parameter 2 - Address of pool
|
|
Parameter 3 - Pool allocation's tag
|
|
Parameter 4 - Quota process pointer (bad).
|
|
|
|
0x40 : Attempt to free usermode address to kernel pool
|
|
Parameter 2 - Starting address
|
|
Parameter 3 - Start of system address space
|
|
Parameter 4 - 0
|
|
|
|
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
|
|
|
|
0x42 : Attempt to free a virtual address which was never in any pool
|
|
Parameter 2 - Address being freed.
|
|
Parameter 3 - 0
|
|
Parameter 4 - 0
|
|
|
|
0x43 : Attempt to free a virtual address which was never in any pool
|
|
Parameter 2 - Address being freed.
|
|
Parameter 3 - 0
|
|
Parameter 4 - 0
|
|
|
|
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
|
|
|
|
0x60 : Attempt to free an invalid contiguous memory address (ie: caller of MmFreeContiguousMemory is passing a bad pointer).
|
|
Parameter 2 - Starting address
|
|
Parameter 3 - 0
|
|
Parameter 4 - 0
|
|
|
|
0x99 : Attempt to free pool with invalid address (or corruption in pool header)
|
|
Parameter 2 - Address being freed
|
|
Parameter 3 - 0
|
|
Parameter 4 - 0
|
|
|
|
0x9A : Attempt to allocate must-succeed pool (this pool type has been deprecated)
|
|
Parameter 2 - Pool type
|
|
Parameter 3 - Size of allocation in bytes
|
|
Parameter 4 - Allocation's pool tag
|
|
|
|
0x9B : Attempt to allocate pool with a tag of zero. This would make the pool untrackable and worse, corrupt the existing tag tables.
|
|
Parameter 2 - Pool type
|
|
Parameter 3 - Size of allocation in bytes
|
|
Parameter 4 - Caller's address.
|
|
|
|
0x9C : Attempt to allocate pool with a tag of BIG. This would make the pool untrackable and worse, corrupt the existing tag tables.
|
|
Parameter 2 - Pool type
|
|
Parameter 3 - Size of allocation in bytes
|
|
Parameter 4 - Caller's address.
|
|
|
|
END_VALUES
|
|
|
|
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 among the most commonly seen crashes.
|
|
|
|
PARAMETERS
|
|
1 - subclass of driver violation.
|
|
VALUES
|
|
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 - (reserved)
|
|
3 - pool header
|
|
4 - pool header contents
|
|
|
|
0x14 : the pool the caller is trying to free is already free.
|
|
2 - (reserved)
|
|
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
|
|
4 - 0 means the new IRQL is bad, 1 means the IRQL is invalid inside a DPC routine
|
|
|
|
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.
|
|
|
|
0x3B : KeWaitXxx routine is being called at DISPATCH_LEVEL or higher.
|
|
2 - current irql,
|
|
3 - object to wait on,
|
|
4 - time out parameter.
|
|
|
|
0x3C : ObReferenceObjectByHandle is being called with a bad handle.
|
|
2 - bad handle passed in,
|
|
3 - object type,
|
|
4 - 0.
|
|
|
|
0x3D : ExAcquireResourceExclusive is being called with a bad (unaligned) resource.
|
|
2 - 0
|
|
3 - 0
|
|
4 - bad resource address passed in.
|
|
|
|
0x3E : KeLeaveCriticalRegion is being called for a thread that never entered a critical region.
|
|
2 - 0
|
|
3 - 0
|
|
4 - 0
|
|
|
|
0x3F : ObReferenceObject is being called on an object that has a reference count of zero or
|
|
ObDereferenceObject is being called on an object with a reference count of zero
|
|
2 - Object address
|
|
3 - new object reference count -1 = dereference case, 1 = reference case
|
|
4 - 0
|
|
|
|
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 - (reserved)
|
|
|
|
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 - (reserved)
|
|
|
|
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.
|
|
|
|
To get the name of the driver at fault, type
|
|
dp ViBadDriver l1; dS @$p
|
|
|
|
Then type !verifier 3 drivername.sys for info on the allocations
|
|
that were leaked that caused the bugcheck.
|
|
|
|
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.
|
|
|
|
To get the name of the driver at fault, type
|
|
dp ViBadDriver l1; dS @$p
|
|
|
|
Then type !verifier 3 drivername.sys for info on the allocations
|
|
that were leaked that caused the bugcheck.
|
|
|
|
0x6F : MmProbeAndLockPages called on pages not in PFN database. This
|
|
is typically a driver calling this routine to lock its own
|
|
private dualport RAM. Not only is this not needed, it can also
|
|
corrupt memory on machines with noncontiguous physical RAM.
|
|
2 - MDL address
|
|
3 - physical page being locked
|
|
4 - highest physical page in the system
|
|
|
|
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
|
|
|
|
0x81 : MmMapLockedPages called without MDL_MAPPING_CAN_FAIL
|
|
2 - MDL address
|
|
3 - MDL flags
|
|
4 - 0
|
|
|
|
0x82 : MmMapLockedPagesSpecifyCache called without MDL_MAPPING_CAN_FAIL
|
|
2 - MDL address
|
|
3 - MDL flags
|
|
4 - Whether to bugcheck on failure
|
|
|
|
0x83 : MmMapIoSpace called to map, but the caller hasn't locked down the MDL pages.
|
|
2 - Starting physical address to map.
|
|
3 - Number of bytes to map.
|
|
4 - The first page frame number that isn't locked down.
|
|
|
|
0x84 : MmMapIoSpace called to map, but the caller hasn't locked down the MDL pages.
|
|
2 - Starting physical address to map.
|
|
3 - Number of bytes to map.
|
|
4 - The first page frame number that is on the free list.
|
|
|
|
0x85 : MmMapLockedPages called to map, but the caller hasn't locked down the MDL pages.
|
|
2 - MDL address.
|
|
3 - Number of pages to map.
|
|
4 - The first page frame number that isn't locked down.
|
|
|
|
0x86 : MmMapLockedPages called to map, but the caller hasn't locked down the MDL pages.
|
|
2 - MDL address.
|
|
3 - Number of pages to map.
|
|
4 - The first page frame number that is on the free list.
|
|
|
|
0x87 : MmMapIoSpace called to map, but the caller's cachetype conflicts with an already existing mapping.
|
|
2 - Base physical page (shift left for physical address) of the existing (conflicting) mapping.
|
|
3 - Number of pages already mapped in the existing (conflicting) mapping.
|
|
4 - MEMORY_CACHING_TYPE of the existing (conflicting mapping).
|
|
|
|
0x88 : MmMapIoSpace called to map a physical range as noncached or writecombined, but the caller's physical range already has an existing cached mapping.
|
|
2 - Base physical page (shift left for physical address) of the requested mapping.
|
|
3 - Number of pages in the requested mapping.
|
|
4 - MEMORY_CACHING_TYPE of the requested mapping.
|
|
|
|
0x89 : An MDL is not marked as I/O but contains non-memory page addresses.
|
|
2 - MDL address.
|
|
3 - Pointer to the non-memory page in the MDL.
|
|
4 - The non-memory page number in the MDL.
|
|
|
|
0x8A : MmMapLockedPages* called to map a physical range as noncached or writecombined, but the caller's physical range already has an existing cached mapping.
|
|
2 - MDL address.
|
|
3 - Conflicting physical page (shift left for physical address) of the requested mapping.
|
|
4 - MEMORY_CACHING_TYPE of the requested mapping.
|
|
|
|
0x90 : A driver switched stacks. The current stack is neither a thread
|
|
stack nor a DPC stack. Typically the driver doing this should be
|
|
on the stack obtained from `kb' command.
|
|
|
|
0xA0 : A CRC error was detected on the sector (synchronously).
|
|
2 - Request Irp.
|
|
3 - Device object of the lower device.
|
|
4 - Sector number on which the CRC error was detected.
|
|
|
|
0xA1 : A CRC error was detected on the sector (asynchronously).
|
|
2 - *COPY* of original Irp (actual irp has been completed)
|
|
3 - Device object of the lower device.
|
|
4 - Sector number on which the CRC error was detected.
|
|
|
|
0xA2 : CRCDISK checksum copies don't match (possible paging error)
|
|
2 - Request Irp or copy.
|
|
3 - Device object of the lower device.
|
|
4 - Sector number on which the CRC error was detected.
|
|
|
|
END_VALUES
|
|
|
|
DESCRIPTION
|
|
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error codes.
|
|
Typically the code is 0x1001 (deadlock detected) and you can
|
|
issue a '!deadlock' KD command to get more information.
|
|
|
|
DRIVER_CORRUPTED_EXPOOL (0xC5)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
An attempt was made to access a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is too high. This is
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - value 0 = read operation, 1 = write operation
|
|
3 - previous mode.
|
|
4 - 4.
|
|
|
|
DESCRIPTION
|
|
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.
|
|
|
|
PARAMETERS
|
|
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).
|
|
|
|
PARAMETERS
|
|
1 - (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue
|
|
DESCRIPTION
|
|
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.
|
|
PARAMETERS
|
|
1 - Code that specifies the violation
|
|
VALUES:
|
|
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
|
|
0xA : Reinitialization of Device object timer
|
|
2 - the Device object , 3/4 - 0
|
|
0xB : Unused
|
|
0xC : Invalid IOSB in IRP at APC IopCompleteRequest (appears to be on
|
|
stack that was unwound)
|
|
2 - the IOSB pointer , 3/4 - 0
|
|
0xD : Invalid UserEvent in IRP at APC IopCompleteRequest (appears to
|
|
be on stack that was unwound)
|
|
2 - the UserEvent pointer , 3/4 - 0
|
|
0xE : Irql > DPC at IoCompleteRequest
|
|
2 - the current Irql
|
|
3 - the IRP
|
|
4 - 0
|
|
0xF : Driver sent an create request with fileobject that's been closed or had its open cancelled.
|
|
1 - Device Object to which the IRP is being sent
|
|
2 - Pointer to IRP
|
|
3 - Pointer to FileObject
|
|
|
|
|
|
0x200 : (Unknown) This code covers all unknown I/O Verification errors.
|
|
2 - The address in the driver's code where the error was detected.
|
|
3 - A pointer to the IRP.
|
|
4 - A pointer to the DeviceObject.
|
|
0x201 : (Fatal error) A device is deleting itself while there is another device
|
|
beneath it in the driver stack. This may be because the caller has forgotten to call
|
|
IoDetachDevice first, or the lower driver may have incorrectly deleted itself.
|
|
|
|
0x202 : (Fatal error) A driver has attempted to detach from a device object that
|
|
is not attached to anything. This may occur if detach was called twice on the same
|
|
device object. (Device object specified.)
|
|
|
|
0x203 : (Fatal error) A driver has called IoCallDriver without setting the
|
|
CancelRoutine in the IRP to NULL. (IRP specified.)
|
|
|
|
0x204 : (Fatal error) The caller has passed in NULL as a DeviceObject. This
|
|
is fatal. (IRP specified.)
|
|
|
|
0x205 : (Fatal error) The caller is forwarding an IRP that is currently queued beneath
|
|
it. The code handling IRPs returning STATUS_PENDING in this driver appears to be
|
|
broken. (IRP specified.)
|
|
|
|
0x206 : (Fatal error) The caller has incorrectly forwarded an IRP (control field
|
|
not zeroed). The driver should use IoCopyCurrentIrpStackLocationToNext or
|
|
IoSkipCurrentIrpStackLocation. (IRP specified.)
|
|
|
|
0x207 : (Fatal error) The caller has manually copied the stack and has inadvertently
|
|
copied the upper layer's completion routine. Please use
|
|
IoCopyCurrentIrpStackLocationToNext. (IRP specified.)
|
|
|
|
0x208 : (Fatal error) This IRP is about to run out of stack locations. Someone
|
|
may have forwarded this IRP from another stack. (IRP specified.)
|
|
|
|
0x209 : (Fatal error) The caller is completing an IRP that is currently queued
|
|
beneath it. The code handling IRPs returning STATUS_PENDING in this driver appears
|
|
to be broken. (IRP specified.)
|
|
|
|
0x20A : (Fatal error) The caller of IoFreeIrp is freeing an IRP that is still
|
|
in use. (Original IRP and IRP in use specified.)
|
|
|
|
0x20B : (Fatal error) The caller of IoFreeIrp is freeing an IRP that is still
|
|
in use. (IRP specified.)
|
|
|
|
0x20C : (Fatal error) The caller of IoFreeIrp is freeing an IRP that is still
|
|
queued against a thread. (IRP specified.)
|
|
|
|
0x20D : (Fatal error) The caller of IoInitializeIrp has passed an IRP that was
|
|
allocated with IoAllocateIrp. This is illegal and unnecessary, and has caused
|
|
a quota leak. Check the documentation for IoReuseIrp if this IRP is being recycled.
|
|
|
|
0x20E : (Non-fatal error) A PNP IRP has an invalid status. (Any PNP IRP must
|
|
have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
|
|
|
|
0x20F : (Non-fatal error) A Power IRP has an invalid status. (Any Power IRP
|
|
must have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
|
|
|
|
0x210 : (Non-fatal error) A WMI IRP has an invalid status. (Any WMI IRP must
|
|
have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
|
|
|
|
0x211 : (Non-fatal error) The caller has forwarded an IRP while skipping a device
|
|
object in the stack. The caller is probably sending IRPs to the PDO instead of
|
|
to the device returned by IoAttachDeviceToDeviceStack. (IRP specified.)
|
|
|
|
0x212 : (Non-fatal error) The caller has trashed or has not properly copied the
|
|
IRP's stack. (IRP specified.)
|
|
|
|
0x213 : (Non-fatal error) The caller has changed the status field of an IRP it
|
|
does not understand. (IRP specified.)
|
|
|
|
0x214 : (Non-fatal error) The caller has changed the information field of an
|
|
IRP it does not understand. (IRP specified.)
|
|
|
|
0x215 : (Non-fatal error) A non-successful non-STATUS_NOT_SUPPORTED IRP status
|
|
for IRP_MJ_PNP is being passed down stack. (IRP specified.) Failed PNP IRPs
|
|
must be completed.
|
|
|
|
0x216 : (Non-fatal error) The previously-set IRP_MJ_PNP status has been converted
|
|
to STATUS_NOT_SUPPORTED. (IRP specified.)
|
|
|
|
0x217 : (Non-fatal error) The driver has not handled a required IRP. The driver must
|
|
update the status of the IRP to indicate whether or not it has been handled.
|
|
(IRP specified.)
|
|
|
|
0x218 : (Non-fatal error) The driver has responded to an IRP that is reserved for
|
|
other device objects elsewhere in the stack. (IRP specified.)
|
|
|
|
0x219 : (Non-fatal error) A non-successful non-STATUS_NOT_SUPPORTED IRP status for
|
|
IRP_MJ_POWER is being passed down stack. (IRP specified.) Failed POWER IRPs must be
|
|
completed.
|
|
|
|
0x21A : (Non-fatal error) The previously-set IRP_MJ_POWER status has been converted
|
|
to STATUS_NOT_SUPPORTED. (IRP specified.)
|
|
|
|
0x21B : (Non-fatal error) A driver has returned a suspicious status. This is probably
|
|
due to an uninitialized variable bug in the driver. (IRP specified.)
|
|
|
|
0x21C : (Warning) The caller has copied the IRP stack but not set a completion routine.
|
|
This is inefficient -- use IoSkipCurrentIrpStackLocation instead. (IRP specified.)
|
|
|
|
0x21D : (Fatal error) An IRP dispatch handler has not properly detached from the
|
|
stack below it upon receiving a remove IRP. (DeviceObject, Dispatch
|
|
Routine, and IRP specified.)
|
|
|
|
0x21E : (Fatal error) An IRP dispatch handler has not properly deleted its device object
|
|
upon receiving a remove IRP. (DeviceObject, Dispatch Routine, and IRP specified.)
|
|
|
|
0x21F : (Non-fatal error) A driver has not filled out a dispatch routine for a required
|
|
IRP major function. (IRP specified.)
|
|
|
|
0x220 : (Non-fatal error) IRP_MJ_SYSTEM_CONTROL has been completed by someone other than
|
|
the ProviderId. This IRP should either have been completed earlier or should have
|
|
been passed down. (IRP specified, along with the DeviceObject where it was targeted.)
|
|
|
|
0x221 : (Fatal error) An IRP dispatch handler for a PDO has deleted its device object,
|
|
but the hardware has not been reported as missing in a bus relations query.
|
|
(DeviceObject, Dispatch Routine, and IRP specified.)
|
|
|
|
0x222 : (Fatal error) A Bus Filter's IRP dispatch handler has detached upon receiving
|
|
a remove IRP when the PDO is still alive. Bus Filters must clean up in
|
|
FastIoDetach callbacks. (DeviceObject, Dispatch Routine, and IRP specified.)
|
|
|
|
0x223 : (Fatal error) An IRP dispatch handler for a bus filter has deleted its device
|
|
object, but the PDO is still present. Bus filters must clean up in
|
|
FastIoDetach callbacks. (DeviceObject, Dispatch Routine, and IRP specified.)
|
|
|
|
0x224 : (Fatal error) An IRP dispatch handler has returned a status that is inconsistent
|
|
with the IRP's IoStatus.Status field. (Dispatch handler routine, IRP, IRP's
|
|
IoStatus.Status, and returned Status specified.)
|
|
|
|
0x225 : (Non-fatal error) An IRP dispatch handler has returned a status that is illegal
|
|
(0xFFFFFFFF). This is probably due to an uninitialized stack variable. To debug
|
|
this, execute an LN command on the specified address.
|
|
|
|
0x226 : (Fatal error) An IRP dispatch handler has returned without passing down or
|
|
completing this IRP, or someone forgot to return STATUS_PENDING. (IRP specified.)
|
|
|
|
0x227 : (Fatal error) An IRP completion routine is in pageable code. (This is never
|
|
permitted.) (Routine and IRP specified.)
|
|
|
|
0x228 : (Non-fatal error) A driver's completion routine has not marked the IRP pending if
|
|
the PendingReturned field was set in the IRP passed to it. This may cause the
|
|
OS to hang, especially if an error is returned by the stack. (Routine and IRP specified.)
|
|
|
|
0x229 : (Fatal error) A cancel routine has been set for an IRP that is currently being
|
|
processed by drivers lower in the stack, possibly stomping their cancel routine.
|
|
(Routine and IRP specified.)
|
|
|
|
0x22A : (Non-fatal error) The physical device object (PDO) has not responded to a
|
|
required IRP. (IRP specified.)
|
|
|
|
0x22B : (Non-fatal error) The physical device object (PDO) has forgotten to fill out the
|
|
device relation list with the PDO for the TargetDeviceRelation query. (IRP specified.)
|
|
|
|
0x22C : (Fatal error) The code implementing the TargetDeviceRelation query has not called
|
|
ObReferenceObject on the PDO. (IRP specified.)
|
|
|
|
0x22D : (Non-fatal error) The caller has completed a IRP_MJ_PNP it didn't understand
|
|
instead of passing it down. (IRP specified.)
|
|
|
|
0x22E : (Non-fatal error) The caller has completed a successful IRP_MJ_PNP instead of
|
|
passing it down. (IRP specified.)
|
|
|
|
0x22F : (Non-fatal error) The caller has completed an untouched IRP_MJ_PNP (instead of
|
|
passing the IRP down), or non-PDO has failed the IRP using illegal value of
|
|
STATUS_NOT_SUPPORTED. (IRP specified.)
|
|
|
|
0x230 : (Non-fatal error) The caller has completed an IRP_MJ_POWER it didn't understand
|
|
instead of passing it down. (IRP specified.)
|
|
|
|
0x231 : (Fatal error) The caller has completed a successful IRP_MJ_POWER instead of passing
|
|
it down. (IRP specified.)
|
|
|
|
0x232 : (Non-fatal error) The caller has completed an untouched IRP_MJ_POWER (instead of
|
|
passing the IRP down), or non-PDO has failed the IRP using illegal value of
|
|
STATUS_NOT_SUPPORTED. (IRP specified.)
|
|
|
|
0x233 : (Non-fatal error) The version field of the query capabilities structure in a query
|
|
capabilities IRP was not properly initialized. (IRP specified.)
|
|
|
|
0x234 : (Non-fatal error) The size field of the query capabilities structure in a query
|
|
capabilities IRP was not properly initialized. (IRP specified.)
|
|
|
|
0x235 : (Non-fatal error) The address field of the query capabilities structure in a query
|
|
capabilities IRP was not properly initialized to -1. (IRP specified.)
|
|
|
|
0x236 : (Non-fatal error) The UI Number field of the query capabilities structure in a
|
|
query capabilities IRP was not properly initialized to -1. (IRP specified.)
|
|
|
|
0x237 : (Fatal error) A driver has sent an IRP that is restricted for system use only. (IRP specified.)
|
|
|
|
0x238 : (Warning) The caller of IoInitializeIrp has passed an IRP that was allocated with
|
|
IoAllocateIrp. This is illegal, unnecessary, and negatively impacts performance in normal
|
|
use. Check the documentation for IoReuseIrp if this IRP is being recycled.
|
|
|
|
0x239 : (Warning) The caller of IoCompleteRequest is completing an IRP that has never
|
|
been forwarded via a call to IoCallDriver or PoCallDriver. This may be
|
|
a bug. (IRP specified.)
|
|
|
|
0x23A : (Fatal error) A driver has forwarded an IRP at an IRQL that is illegal for
|
|
this major code. (IRP specified.)
|
|
|
|
0x23B : (Non-fatal error) The caller has changed the status field of an IRP it does not
|
|
understand. (IRP specified.)
|
|
|
|
|
|
0x23C : (Fatal error) A driver has completed an IRP without setting the cancel
|
|
routine in the IRP to NULL. (IRP specified.)
|
|
|
|
0x23D : (Non-fatal error) A driver has returned STATUS_PENDING but did not mark the IRP
|
|
pending via a call to IoMarkIrpPending. (IRP specified.)
|
|
|
|
0x23E : (Non-fatal error) A driver has marked an IRP pending but didn't return
|
|
STATUS_PENDING. (IRP specified.)
|
|
|
|
0x23F : (Fatal error) A driver has not inherited the DO_POWER_PAGABLE bit from the
|
|
stack it has attached to. (DeviceObject specified.)
|
|
|
|
0x240 : (Fatal error) A driver is attempting to delete a device object that has already
|
|
been deleted via a prior call to IoDeleteDevice.
|
|
|
|
0x241 : (Fatal error) A driver has detached its device object during a surprise remove
|
|
IRP. (IRP and DeviceObject specified.)
|
|
|
|
0x242 : (Fatal error) A driver has deleted its device object during a surprise remove
|
|
IRP. (IRP and DeviceObject specified.)
|
|
|
|
0x243 : (Fatal error) A driver has failed to clear the DO_DEVICE_INITIALIZING flag at
|
|
the end of AddDevice. (DeviceObject specified.)
|
|
|
|
0x244 : (Fatal error) A driver has not copied either the DO_BUFFERED_IO or the
|
|
DO_DIRECT_IO flag from the device object it is attaching
|
|
to. (DeviceObject specified.)
|
|
|
|
0x245 : (Fatal error) A driver has set both the DO_BUFFERED_IO and the DO_DIRECT_IO
|
|
flags. These flags are mutually exclusive. (DeviceObject specified.)
|
|
|
|
0x246 : (Fatal error) A driver has failed to copy the DeviceType field from the device
|
|
object it is attaching to. (DeviceObject specified.)
|
|
|
|
0x247 : (Fatal error) A driver has failed an IRP that cannot legally be failed. (IRP specified.)
|
|
|
|
0x248 : (Fatal error) A driver has added a device object that is not a PDO to a device
|
|
relations query. (IRP and DeviceObject specified.)
|
|
|
|
0x249 : (Non-fatal error) A driver has enumerated two child PDOs that returned identical
|
|
Device IDs. (Both DeviceObjects specified.)
|
|
|
|
0x24A : (Fatal error) A driver has mistakenly called a file I/O function at an IRQL
|
|
other than PASSIVE_LEVEL.
|
|
|
|
0x24B : (Fatal error) A driver has succeeded IRP_MJ_PNP.IRP_MN_QUERY_DEVICE_RELATIONS(TargetRelations)
|
|
but did not properly fill out the request or forward the IRP to the underlying
|
|
hardware stack. (DeviceObject specified.)
|
|
|
|
0x24C : (Non-fatal error) A driver has returned STATUS_PENDING but did not mark the
|
|
IRP pending via a call to IoMarkIrpPending. (IRP specified.)
|
|
|
|
0x24D : (Fatal error) A driver has passed an invalid device object to a function that
|
|
requires a PDO. (DeviceObject specified.)
|
|
|
|
END_VALUES
|
|
|
|
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.
|
|
|
|
PARAMETERS
|
|
Argument 1 -
|
|
VALUES:
|
|
1 : Duplicate PDO
|
|
|
|
A specific instance of a driver has enumerated multiple PDOs with
|
|
identical device id and unique ids.
|
|
|
|
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.
|
|
|
|
2 - Purported PDO.
|
|
|
|
3 - Driver object
|
|
|
|
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
|
|
VALUES
|
|
1 : DeviceID
|
|
2 : UniqueID
|
|
3 : HardwareIDs
|
|
4 : CompatibleIDs
|
|
END_VALUES
|
|
|
|
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.
|
|
END_VALUES
|
|
|
|
|
|
|
|
DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS (0xCB)
|
|
PARAMETERS
|
|
1 - The calling address in the driver that locked the pages or if the
|
|
IO manager locked the pages this points to the dispatch routine of
|
|
the top driver on the stack to which the IRP was sent.
|
|
2 - The caller of the calling address in the driver that locked the
|
|
pages. If the IO manager locked the pages this points to the device
|
|
object of the top driver on the stack to which the IRP was sent.
|
|
3 - A pointer to the MDL containing the locked pages.
|
|
4 - The number of locked pages.
|
|
|
|
DESCRIPTION
|
|
Caused by a driver not cleaning up completely after an I/O.
|
|
|
|
When possible, the guilty driver's name (Unicode string) is printed on
|
|
the bugcheck screen and saved in KiBugCheckDriver.
|
|
|
|
PAGE_FAULT_IN_FREED_SPECIAL_POOL (0xCC)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - value 0 = read operation, 1 = write operation
|
|
3 - if non-zero, the address which referenced memory.
|
|
4 - Mm internal code.
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - value 0 = read operation, 1 = write operation
|
|
3 - if non-zero, the address which referenced memory.
|
|
4 - Mm internal code.
|
|
|
|
DESCRIPTION
|
|
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.
|
|
PARAMETERS
|
|
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)
|
|
PARAMETERS
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
An attempt was made to access a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is too high. This is
|
|
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 Management\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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
An attempt was made to access a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is too high. This is usually
|
|
caused by drivers using improper addresses.
|
|
|
|
If kernel debugger is available get stack backtrace.
|
|
|
|
BUGCODE_ID_DRIVER (0xD2)
|
|
|
|
This is the NDIS Driver Bugcheck for Windows 2000 and Windows XP.
|
|
For Windows Server 2003 and later, see 0x7C, BUGCODE_NDIS_DRIVER.
|
|
|
|
DESCRIPTION
|
|
The meaning of the bug check parameters cannot be determined by examining the
|
|
parameters alone. You must also examine the text of a DbgPrint message.
|
|
|
|
For details, see either the debugger documentation or the DDK documentation.
|
|
|
|
|
|
DRIVER_PORTION_MUST_BE_NONPAGED (0xD3)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
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 a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is 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.
|
|
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - value 0 = read operation, 1 = write operation
|
|
3 - if non-zero, the address which referenced memory.
|
|
4 - (reserved)
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - value 0 = read operation, 1 = write operation
|
|
3 - if non-zero, the address which referenced memory.
|
|
4 - (reserved)
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
1 - virtual address to unmap.
|
|
2 - 1 if the view is being unmapped, 2 if the view is being committed.
|
|
3 - 0.
|
|
4 - 0.
|
|
|
|
DESCRIPTION
|
|
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)
|
|
PARAMETERS
|
|
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
|
|
|
|
DESCRIPTION
|
|
No System PTEs left. Usually caused by a driver not cleaning up
|
|
properly. If non-null, Parameter 1 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)
|
|
|
|
PARAMETERS
|
|
1 - Type of error.
|
|
VALUES:
|
|
1 : The MDL is being inserted twice on the same process list.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
2 - Address of internal lock tracking structure.
|
|
3 - Address of memory descriptor list.
|
|
4 - 0.
|
|
END_VALUES
|
|
|
|
SYSTEM_PTE_MISUSE (0xDA)
|
|
|
|
The stack trace identifies the guilty driver.
|
|
|
|
PARAMETERS
|
|
1 - Type of error.
|
|
VALUES:
|
|
1 : The PTE mapping being freed is a duplicate.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
2 - Starting PTE.
|
|
3 - Number of PTEs.
|
|
4 - Caller Id (system internal).
|
|
|
|
8 : The caller is asking to free an incorrect number of PTEs.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
2 - Whether the driver requested "bugcheck on failure" in the MDL.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
2 - Bogus PTE.
|
|
3 - Number of PTEs the caller is trying to free.
|
|
4 - Type of PTE pool being freed.
|
|
END_VALUES
|
|
|
|
DRIVER_CORRUPTED_SYSPTES (0xDB)
|
|
PARAMETERS
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
4 - address which referenced memory
|
|
|
|
DESCRIPTION
|
|
An attempt was made to access a pagable (or completely invalid) address at an
|
|
interrupt request level (IRQL) that is too high. This is
|
|
caused by drivers that have corrupted system PTEs. Set
|
|
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\TrackPtes
|
|
to a DWORD 3 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.
|
|
|
|
IMPERSONATING_WORKER_THREAD (0xDF)
|
|
|
|
A workitem forgot to disable impersonation before it completed.
|
|
|
|
PARAMETERS
|
|
1 - Worker Routine that caused this bugcheck.
|
|
2 - Parameter passed to this worker routine.
|
|
3 - Pointer to the Workitem.
|
|
|
|
ACPI_BIOS_FATAL_ERROR (0xE0)
|
|
|
|
Your computer (BIOS) has reported that a component in your system is too faulty
|
|
for Windows to be able to run.
|
|
|
|
You can determine which component is faulty by running the diagnostic disk or
|
|
tool that came with your computer.
|
|
|
|
If you do not have this tool, you must contact your system vendor and report
|
|
this error message to them. They will be able to assist you in correcting this
|
|
hardware problem, thereby allowing Windows to operate. Microsoft cannot assist
|
|
in the debugging of this problem -- only the hardware vendor can interpret the
|
|
bug check parameters and debug this error.
|
|
|
|
WORKER_THREAD_RETURNED_AT_BAD_IRQL (0xE1)
|
|
PARAMETERS
|
|
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.
|
|
|
|
PARAMETERS
|
|
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.
|
|
|
|
PARAMETERS
|
|
1 - Code position indicator
|
|
2 - Address of worker item
|
|
3 - Start of pool block
|
|
4 - End of pool block
|
|
|
|
|
|
DRIVER_VERIFIER_DMA_VIOLATION (0xE6)
|
|
|
|
An illegal DMA operation was attempted by a driver being verified.
|
|
PARAMETERS
|
|
1- Violation code.
|
|
VALUES:
|
|
0x03 : Double-freed DMA common buffer.
|
|
0x04 : Double-freed DMA adapter channel.
|
|
0x05 : Double-freed DMA map register.
|
|
0x06 : Double-freed DMA scatter-gather list.
|
|
0x0E : Buffer not locked. DMA transfer has been
|
|
attempted with a PAGED buffer.
|
|
0x0F : Boundary overrun. Driver or DMA hardware has
|
|
written outside of its allocation.
|
|
0x18 : Adapter already released. A DMA operation has been
|
|
attempted using an adapter that no longer exists.
|
|
0x19 : The driver passed a null DMA_ADAPTER value to a
|
|
HAL routine.
|
|
0x1B : The driver passed an address and an MDL to a HAL
|
|
routine, but this address is not contained in
|
|
this MDL.
|
|
0x1D : The driver attempted to map an address that was
|
|
already mapped.
|
|
END_VALUES
|
|
|
|
|
|
INVALID_FLOATING_POINT_STATE (0xE7)
|
|
|
|
While restoring the previously saved floating point state for a thread,
|
|
the state was found to be invalid. The first argument indicates which
|
|
validity check failed.
|
|
PARAMETERS
|
|
1 - indicates which validity check failed.
|
|
VALUES:
|
|
0 : Saved context flags field is invalid, either FLOAT_SAVE_VALID
|
|
is not set or some of the reserved bits are non-zero. Second
|
|
argument is the flags field.
|
|
|
|
1 : The current processor interrupt priority level (IRQL) is not
|
|
the same as when the floating point context was saved.
|
|
Second argument is saved IRQL, third is current IRQL.
|
|
|
|
2 : The saved context does not belong to the current thread.
|
|
Second argument is the saved address of the thread this
|
|
floating point context belongs to, third argument is the
|
|
current thread.
|
|
END_VALUES
|
|
|
|
|
|
INVALID_CANCEL_OF_FILE_OPEN (0xE8)
|
|
|
|
The fileobject passed to IoCancelFileOpen is invalid. It should have reference
|
|
of 1. The driver that called IoCancelFileOpen is at fault.
|
|
|
|
PARAMETERS
|
|
1 - FileObject passed to IoCancelFileOpen
|
|
2 - DeviceObject passed to IoCancelFileOpen
|
|
|
|
ACTIVE_EX_WORKER_THREAD_TERMINATION (0xE9)
|
|
|
|
An executive worker thread is being terminated without having gone through
|
|
the worker thread rundown code. A stack trace should indicate the cause.
|
|
|
|
PARAMETERS
|
|
1 - The exiting ETHREAD.
|
|
|
|
THREAD_STUCK_IN_DEVICE_DRIVER (0xEA)
|
|
|
|
The device driver is spinning in an infinite loop, most likely waiting for
|
|
hardware to become idle. This usually indicates problem with the hardware
|
|
itself or with the device driver programming the hardware incorrectly.
|
|
|
|
PARAMETERS
|
|
1 - Pointer to a stuck thread object. Do .thread then kb on it to find
|
|
the hung location.
|
|
2 - Pointer to a DEFERRED_WATCHDOG object.
|
|
3 - Pointer to offending driver name.
|
|
4 - Number of times this error occurred. If a debugger is attached,
|
|
this error is not always fatal -- see DESCRIPTION below. On the
|
|
blue screen, this will always equal 1.
|
|
|
|
DESCRIPTION
|
|
|
|
If the kernel debugger is connected and running when watchdog detects a
|
|
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
|
|
and detailed message including bugcheck arguments will be printed to the
|
|
debugger. This way we can identify an offending thread, set breakpoints in it,
|
|
and hit go to return to the spinning code to debug it further. Because
|
|
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
|
|
information in this case. The arguments are already printed out to the kernel
|
|
debugger. You can also retrieve them from a global variable via
|
|
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
|
|
|
|
On MP machines it is possible to hit a timeout when the spinning thread is
|
|
interrupted by hardware interrupt and ISR or DPC routine is running at the time
|
|
of the bugcheck (this is because the timeout's work item can be delivered and
|
|
handled on the second CPU and the same time). If this is the case you will have
|
|
to look deeper at the offending thread's stack (e.g. using dds) to determine
|
|
spinning code which caused the timeout to occur.
|
|
|
|
|
|
THREAD_STUCK_IN_DEVICE_DRIVER_M (0x100000EA)
|
|
|
|
The device driver is spinning in an infinite loop, most likely waiting for
|
|
hardware to become idle. This usually indicates problem with the hardware
|
|
itself or with the device driver programming the hardware incorrectly.
|
|
|
|
PARAMETERS
|
|
1 - Pointer to a stuck thread object. Do .thread then kb on it to find
|
|
the hung location.
|
|
2 - Pointer to a DEFERRED_WATCHDOG object.
|
|
3 - Pointer to offending driver name.
|
|
4 - Number of times "intercepted" bugcheck 0xEA was hit (see notes).
|
|
|
|
DESCRIPTION
|
|
|
|
If the kernel debugger is connected and running when watchdog detects a
|
|
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
|
|
and detailed message including bugcheck arguments will be printed to the
|
|
debugger. This way we can identify an offending thread, set breakpoints in it,
|
|
and hit go to return to the spinning code to debug it further. Because
|
|
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
|
|
information in this case. The arguments are already printed out to the kernel
|
|
debugger. You can also retrieve them from a global variable via
|
|
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
|
|
|
|
On MP machines it is possible to hit a timeout when the spinning thread is
|
|
interrupted by hardware interrupt and ISR or DPC routine is running at the time
|
|
of the bugcheck (this is because the timeout's work item can be delivered and
|
|
handled on the second CPU and the same time). If this is the case you will have
|
|
to look deeper at the offending thread's stack (e.g. using dds) to determine
|
|
spinning code which caused the timeout to occur.
|
|
|
|
|
|
|
|
DIRTY_MAPPED_PAGES_CONGESTION (0xEB)
|
|
PARAMETERS
|
|
1 - Total number of dirty pages
|
|
2 - Number of dirty pages destined for the pagefile(s).
|
|
3 - Internal flags.
|
|
4 - Most recent modified write error status.
|
|
|
|
DESCRIPTION
|
|
No free pages available to continue operations.
|
|
|
|
If kernel debugger available, type "!vm 3".
|
|
|
|
This bugcheck usually occurs 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
|
|
"!vm 3" 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 0 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.
|
|
|
|
SESSION_HAS_VALID_SPECIAL_POOL_ON_EXIT (0xEC)
|
|
PARAMETERS
|
|
1 - session ID
|
|
2 - number of special pool pages that are leaking
|
|
|
|
DESCRIPTION
|
|
Caused by a session driver not freeing its pool allocations prior to a
|
|
session unload. This indicates a bug in win32k.sys, atmfd.dll,
|
|
rdpdd.dll or a video driver.
|
|
|
|
|
|
UNMOUNTABLE_BOOT_VOLUME (0xED)
|
|
|
|
The IO subsystem attempted to mount the boot volume and it failed.
|
|
|
|
PARAMETERS
|
|
1 - Device object of the boot volume
|
|
2 - Status code from the filesystem on why it failed to mount the volume
|
|
|
|
CRITICAL_PROCESS_DIED (0xEF)
|
|
|
|
A critical system process died
|
|
|
|
PARAMETERS
|
|
1 - Process object
|
|
|
|
SCSI_VERIFIER_DETECTED_VIOLATION (0xF1)
|
|
PARAMETERS
|
|
1 - Error code:
|
|
VALUES
|
|
1000 : Miniport passed bad params to ScsiPortInitialize
|
|
|
|
2 - First argument to ScsiPortInitialize
|
|
3 - Second argument to ScsiPortInitialize
|
|
|
|
1001 : Miniport stalled processor too long
|
|
|
|
2 - Delay in microseconds supplied by miniport
|
|
|
|
1002 : Miniport routine executed too long
|
|
|
|
2 - Address of routine that ran too long
|
|
3 - Address of miniport's HwDeviceExtension
|
|
4 - Duration of the routine in microseconds
|
|
|
|
1003 : Miniport completed a request multiple times
|
|
|
|
2 - Address of miniport's HwDeviceExtension
|
|
3 - Address of SRB of multiply completed request
|
|
|
|
1004 : Miniport has completed request with bad status
|
|
|
|
2 - Address of SRB
|
|
3 - Address of miniport's HwDeviceExtension
|
|
|
|
1005 : Miniport has asked for the next LU request while
|
|
an untagged request is active
|
|
|
|
2 - Address of miniport's HwDeviceExtension
|
|
3 - Address of logical unit extension
|
|
|
|
1006 : Miniport called ScsiportGetPhysicalAddress with a bad VA
|
|
|
|
2 - Address of miniport's HwDeviceExtension
|
|
3 - VA supplied by the miniport
|
|
|
|
1007 : Miniport had outstanding requests at the end of a bus reset period
|
|
|
|
2 - Address of adapter extension
|
|
3 - Address of miniport's HwDeviceExtension
|
|
END_VALUES
|
|
|
|
|
|
DESCRIPTION
|
|
The SCSI verifier has detected an error in a SCSI miniport driver being verified.
|
|
|
|
HARDWARE_INTERRUPT_STORM (0xF2)
|
|
|
|
Note: This bug check no longer exists in any version of Windows.
|
|
|
|
PARAMETERS
|
|
1 - address of the ISR (or first ISR in the chain) connected to the storming interrupt vector
|
|
2 - ISR context value
|
|
3 - address of the interrupt object for the storming interrupt vector
|
|
4 - 0x1 if the ISR is not chained, 0x2 if the ISR is chained
|
|
|
|
DESCRIPTION
|
|
This bugcheck will show up on the screen when the kernel
|
|
detects an interrupt "storm". An interrupt storm is defined as a level
|
|
triggered interrupt signal staying in the asserted state. This is fatal
|
|
to the system in the manner that the system will hard hang, or "bus lock".
|
|
|
|
This can happen because of the following:
|
|
|
|
- A piece of hardware does not release its interrupt signal after being told
|
|
to do so by the device driver
|
|
- A device driver does not instruct its hardware to release the interrupt
|
|
signal because it does not believe the interrupt was initiated from its
|
|
hardware
|
|
- A device driver claims the interrupt even though the interrupt was not
|
|
initiated from its hardware. Note that this can only occur when multiple
|
|
devices are sharing the same IRQ.
|
|
- The ELCR (edge level control register) is set incorrectly.
|
|
- Edge and Level interrupt triggered devices share an IRQ (e.g. COM port and
|
|
PCI SCSI controller).
|
|
|
|
All of these cases will instantly hard hang your system. Instead of hard
|
|
hanging the system, this bugcheck is initiated since in many cases it can
|
|
identify the culprit.
|
|
|
|
When the bugcheck occurs, the module containing the ISR (interrupt service
|
|
routine) of the storming IRQ is displayed on the screen. This is an
|
|
example of what you would see:
|
|
|
|
*** STOP: 0x000000F2 (0xFCA7C55C, 0x817B9B28, 0x817D2AA0, 0x00000002)
|
|
|
|
An interrupt storm has caused the system to hang.
|
|
|
|
*** Address FCA7C55C base at FCA72000, Datestamp 3A72BDEF - ACPI.sys
|
|
|
|
In the event the fourth parameter is a 0x00000001, the module pointed to
|
|
is very likely the culprit. Either the driver is broken, or the hardware
|
|
is malfunctioning.
|
|
|
|
In the event the fourth parameter is a 0x00000002, the module pointed to
|
|
is the first ISR in the chain, and is never guaranteed to be the culprit.
|
|
A user experiencing this bugcheck repeatedly should try to isolate the
|
|
problem by looking for devices that are on the same IRQ as the one for
|
|
which the module is a driver for (in this case, the same IRQ that ACPI
|
|
is using). In the future, we may be able to list all devices on a
|
|
chained ISR.
|
|
|
|
|
|
DISORDERLY_SHUTDOWN (0xF3)
|
|
|
|
No free pages available to continue operations.
|
|
|
|
Because applications are not terminated and drivers are
|
|
not unloaded, they can continue to access pages even after
|
|
the modified writer has terminated. This can cause the
|
|
system to run out of pages since the pagefile(s) cannot be used.
|
|
|
|
PARAMETERS
|
|
1 - Total number of dirty pages
|
|
2 - Number of dirty pages destined for the pagefile(s).
|
|
3 - Internal flags.
|
|
4 - Most recent modified write error status.
|
|
|
|
|
|
CRITICAL_OBJECT_TERMINATION (0xF4)
|
|
|
|
A process or thread crucial to system operation has unexpectedly exited or been
|
|
terminated.
|
|
|
|
Several processes and threads are necessary for the operation of the
|
|
system; when they are terminated (for any reason), the system can no
|
|
longer function.
|
|
|
|
PARAMETERS
|
|
1 - Terminating object type
|
|
VALUES:
|
|
3 : Process
|
|
6 : Thread
|
|
END_VALUES
|
|
2 - Terminating object
|
|
3 - Process image file name
|
|
4 - Explanatory message (ascii)
|
|
|
|
|
|
PCI_VERIFIER_DETECTED_VIOLATION (0xF6)
|
|
|
|
The PCI driver detected an error in a device or BIOS being verified.
|
|
|
|
PARAMETERS
|
|
1 - Failure detected
|
|
VALUES:
|
|
1 : An active bridge was reprogrammed by the BIOS during a docking event
|
|
2 : The PMCSR register was not updated within the spec mandated time
|
|
3 : A driver has written to OS controlled portions of a PCI device's config space
|
|
END_VALUES
|
|
|
|
|
|
DRIVER_OVERRAN_STACK_BUFFER (0xF7)
|
|
|
|
A driver has overrun a stack-based buffer. This overrun could potentially
|
|
allow a malicious user to gain control of this machine.
|
|
|
|
DESCRIPTION
|
|
|
|
A driver overran a stack-based buffer (or local variable) in a way that would
|
|
have overwritten the function's return address and jumped back to an arbitrary
|
|
address when the function returned. This is the classic "buffer overrun"
|
|
hacking attack and the system has been brought down to prevent a malicious user
|
|
from gaining complete control of it.
|
|
|
|
Do a kb to get a stack backtrace -- the last routine on the stack before the
|
|
buffer overrun handlers and bugcheck call is the one that overran its local
|
|
variable(s).
|
|
|
|
RAMDISK_BOOT_INITIALIZATION_FAILED (0xF8)
|
|
|
|
An initialization failure occurred while attempting to boot from the RAM disk.
|
|
|
|
PARAMETERS
|
|
1 - Action that failed
|
|
VALUES:
|
|
1 : No LoaderXIPRom descriptor was found in the loader memory list
|
|
2 : Unable to open the RAM disk driver (ramdisk.sys, \Device\Ramdisk)
|
|
3 : FSCTL_CREATE_RAM_DISK failed
|
|
4 : Unable to create GUID string from binary GUID
|
|
5 : Unable to create symbolic link pointing to RAM disk device
|
|
END_VALUES
|
|
2 - NT status code
|
|
|
|
DRIVER_RETURNED_STATUS_REPARSE_FOR_VOLUME_OPEN (0xF9)
|
|
|
|
A driver returned STATUS_REPARSE to a Create request with no trailing names.
|
|
STATUS_REPARSE should be returned only for Create requests with trailing names
|
|
as that indicates the driver is supporting name spaces.
|
|
|
|
PARAMETERS
|
|
1 - Device object that was opened.
|
|
2 - Device object to which the Create IRP was issued.
|
|
3 - New name of the file (to be reparsed) (UNICODE string)
|
|
4 - Information returned by the driver for the Create IRP
|
|
|
|
HTTP_DRIVER_CORRUPTED (0xFA)
|
|
|
|
The HTTP kernel driver (http.sys) reached a corrupted state and can not
|
|
recover.
|
|
|
|
PARAMETERS
|
|
1 - State identifier
|
|
VALUES:
|
|
1 : A work item is invalid. This will eventually result in
|
|
corruption of the thread pool and an access violation.
|
|
2 - Address of work item
|
|
3 - Name of file containing work item check, __FILE__
|
|
4 - Line number in file, __LINE__
|
|
END_VALUES
|
|
|
|
BUGCODE_PSS_MESSAGE (0x4000007C)
|
|
|
|
Generic bugcode message.
|
|
|
|
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (0xFC)
|
|
An attempt was made to execute to non-executable memory. The guilty driver
|
|
is on the stack trace (and is typically the current instruction pointer).
|
|
|
|
PARAMETERS
|
|
1 - Virtual address for the attempted execute.
|
|
2 - PTE contents.
|
|
3 - (reserved)
|
|
4 - (reserved)
|
|
|
|
DESCRIPTION
|
|
When possible, the guilty driver's name (Unicode string) is printed on
|
|
the bugcheck screen and saved in KiBugCheckDriver.
|
|
|
|
DIRTY_NOWRITE_PAGES_CONGESTION (0xFD)
|
|
PARAMETERS
|
|
1 - Total number of dirty pages
|
|
2 - Number of nowrite dirty pages.
|
|
3 - Internal flags.
|
|
4 - Most recent modified write error status.
|
|
|
|
DESCRIPTION
|
|
No free pages available to continue operations.
|
|
|
|
If kernel debugger available, type "!vm 3 and !memusage 1".
|
|
|
|
This bugcheck usually occurs because the component owning the
|
|
modified nowrite pages failed to write out these pages after
|
|
marking the relevant files as dont-write to memory management.
|
|
This indicates a driver bug.
|
|
|
|
BUGCODE_USB_DRIVER (0xFE)
|
|
PARAMETERS
|
|
1 - USB Bugcheck Code:
|
|
VALUES
|
|
1 : INTERNAL_ERROR An internal error has occured in the USB stack
|
|
|
|
2 : BAD_URB The USB client driver has submitted a URB that is
|
|
still attached to another IRP still pending in the bus
|
|
driver.
|
|
|
|
2 - Address of pending IRP.
|
|
3 - Address of IRP passed in.
|
|
4 - Address URB that caused the error.
|
|
|
|
3 : MINIPORT_ERROR The USB miniport driver has generated a
|
|
bugcheck. This is usually in response to catastrophic
|
|
hardware failure.
|
|
|
|
4 : IRP_URB_DOUBLE_SUBMIT The caller has submitted an irp
|
|
that is already pending in the USB bus driver.
|
|
|
|
2 - Address of IRP
|
|
3 - Address of URB
|
|
|
|
|
|
DESCRIPTION
|
|
USB Driver bugcheck, first parameter is USB bugcheck code.
|
|
|
|
|
|
WINLOGON_FATAL_ERROR (0xC000021A)
|
|
|
|
The Winlogon process terminated unexpectedly.
|
|
|
|
MANUALLY_INITIATED_CRASH1 (0xDEADDEAD)
|
|
|
|
The user manually initiated this crash dump.
|
|
|
|
|