mirror of https://github.com/lianthony/NT4.0
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.
1022 lines
38 KiB
1022 lines
38 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
|
|
|
|
APC_INDEX_MISMATCH (0x1)
|
|
This is a kernel internal error which can occur on a checked build.
|
|
The most common reason to see such a bugcheck would occur when a
|
|
filesystem had a mismatched number of KeEnterCricticalRegion compared
|
|
to KeLeaveCriticalRegion.
|
|
|
|
DEVICE_QUEUE_NOT_BUSY (0x2)
|
|
|
|
INVALID_AFFINITY_SET (0x3)
|
|
|
|
INVALID_DATA_ACCESS_TRAP (0x4)
|
|
|
|
INVALID_PROCESS_ATTACH_ATTEMPT (0x5)
|
|
|
|
INVALID_PROCESS_DETACH_ATTEMPT (0x6)
|
|
|
|
INVALID_SOFTWARE_INTERRUPT (0x7)
|
|
|
|
IRQL_NOT_DISPATCH_LEVEL (0x8)
|
|
|
|
IRQL_NOT_GREATER_OR_EQUAL (0x9)
|
|
|
|
IRQL_NOT_LESS_OR_EQUAL (0xA)
|
|
1 - memory referenced
|
|
2 - IRQL
|
|
3 - value 0 = read operation, 1 = write operation
|
|
If this value is non-zero and is equal to parameter 1, then
|
|
The bugcheck indicates that a worker routine returned at raised
|
|
IRQL.Parameter 1 and 3 are the address of the work routine, and
|
|
parameter 4 is the workitem
|
|
4 - address which referened memory
|
|
|
|
An attempt was made to touch pagable memory at a process
|
|
internal request level (IRQL) too high. This is usally
|
|
caused by drivers using improper addresses.
|
|
|
|
If kernel debugger is available get stack backtrace.
|
|
|
|
|
|
NO_EXCEPTION_HANDLING_SUPPORT (0xB)
|
|
|
|
MAXIMUM_WAIT_OBJECTS_EXCEEDED (0xC)
|
|
|
|
MUTEX_LEVEL_NUMBER_VIOLATION (0xD)
|
|
1 - The current thread's mutex level
|
|
2 - The mutex level that we are attempting to acquire
|
|
|
|
Try to identify the mutexes using the ntos\ex\exlevels.h header file. This
|
|
usually will pinpoint the mutexes that are getting acquired in an incorrect
|
|
sequence.
|
|
|
|
NO_USER_MODE_CONTEXT (0xE)
|
|
|
|
SPIN_LOCK_ALREADY_OWNED (0xF)
|
|
|
|
SPIN_LOCK_NOT_OWNED (0x10)
|
|
|
|
THREAD_NOT_MUTEX_OWNER (0x11)
|
|
|
|
TRAP_CAUSE_UNKNOWN (0x12)
|
|
|
|
EMPTY_THREAD_REAPER_LIST (0x13)
|
|
|
|
CREATE_DELETE_LOCK_NOT_LOCKED (0x14)
|
|
|
|
LAST_CHANCE_CALLED_FROM_KMODE (0x15)
|
|
|
|
CID_HANDLE_CREATION (0x16)
|
|
|
|
CID_HANDLE_DELETION (0x17)
|
|
|
|
REFERENCE_BY_POINTER (0x18)
|
|
|
|
BAD_POOL_HEADER (0x19)
|
|
|
|
MEMORY_MANAGEMENT (0x1A)
|
|
|
|
PFN_SHARE_COUNT (0x1B)
|
|
|
|
PFN_REFERENCE_COUNT (0x1C)
|
|
|
|
NO_SPIN_LOCK_AVAILABLE (0x1D)
|
|
|
|
KMODE_EXCEPTION_NOT_HANDLED (0x1E)
|
|
1 - The exception code that was not handled
|
|
2 - The address that the exception occured at
|
|
3 - Parameter 0 of the exception
|
|
4 - Parameter 1 of the exception
|
|
|
|
This is a very common bugcheck. Usually the exception address pinpoints
|
|
the driver/function that caused the problem. Always note this address
|
|
as well as the link date of the driver/image that contains this address.
|
|
Some common problems are exception code 0x80000003. This means a hard
|
|
coded breakpoint or assertion was hit, but this system was booted
|
|
/NODEBUG. This should not happen, but I am positive you will see this.
|
|
If it happens repeatedly, make sure a debugger gets connected, and the
|
|
system is booted /DEBUG. This will let us see why this breakpoint is
|
|
happening.
|
|
|
|
On MIPs systems if the address of the exception is 0XBFC0304, then bugcheck is
|
|
the result of a cache parity error on the CPU. If the problem reoccurs
|
|
frequently, the hardware manufactor should be contacted.
|
|
|
|
SHARED_RESOURCE_CONV_ERROR (0x1F)
|
|
|
|
KERNEL_APC_PENDING_DURING_EXIT (0x20)
|
|
1 - The address of the APC found pending during exit.
|
|
2 - The thread's APC disable count
|
|
3 - The current IRQL
|
|
|
|
While this bugcheck is a rare event at MS, we have seen this twice in
|
|
the last bit of time. The key data items are the thread's APC disable
|
|
count. If this is non-zero, then this is the source of the problem. A
|
|
negative value indicates that a filesystem has called
|
|
FsRtlEnterFileSystem more than FsRtlExitFileSystem. A positive value
|
|
indicates that the reverse is true. If you ever see this, be very very
|
|
suspicios of all file systems installed on the machine. Third party
|
|
redirectorys (like novel) are especially suspicios since they do not
|
|
receive the heavy duty testing that NTFS, FAT, HPFS, and RDR receive.
|
|
|
|
This current IRQL should also be 0. If it is not, that a driver's
|
|
cancelation routine can cause this bugcheck by returning at an elevated
|
|
IRQL. Always attempt to not what the customer was doing/closing at the
|
|
time of the crash, and note all of the installed drivers at the time of
|
|
the crash. This symptom is usually a severe bug in a third party
|
|
driver.
|
|
|
|
QUOTA_UNDERFLOW (0x21)
|
|
|
|
FILE_SYSTEM (0x22)
|
|
|
|
FAT_FILE_SYSTEM (0x23)
|
|
All file system bug checks have encoded in their first ULONG
|
|
the source file and the line within the source file that generated
|
|
the bugcheck. The high 16-bits contains a number to identify the
|
|
file and low 16-bits is the source line within the file where
|
|
the bug check call occurs. For example, 0x00020009 indicates
|
|
that the FAT file system bugcheck occured in source file #2 and
|
|
line #9.
|
|
|
|
The file system calls bug check in multiple places and this will
|
|
help us identify the actual source line that generated the bug
|
|
check. The only thing that can be done right now is to collect
|
|
any bug check information in a database and pass on the output
|
|
to a developer who can look in the sources and hopefully identify
|
|
the cause of the bug check.
|
|
|
|
NTFS_FILE_SYSTEM (0x24)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
NPFS_FILE_SYSTEM (0x25)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
CDFS_FILE_SYSTEM (0x26)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
RDR_FILE_SYSTEM (0x27)
|
|
|
|
CORRUPT_ACCESS_TOKEN (0x28)
|
|
|
|
SECURITY_SYSTEM (0x29)
|
|
|
|
INCONSISTENT_IRP (0x2A)
|
|
1 - Address of the IRP that was found to be inconsistent
|
|
|
|
An IRP was encountered that was in an inconsistent state; i.e., some field
|
|
or fields of the IRP were inconsistent w/the remaining state of the IRP.
|
|
An example would be an IRP that was being completed, but was still marked
|
|
as being queued to a driver's device queue. This bugcheck code is not
|
|
currently being used in the system, but exists for debugging purposes.
|
|
|
|
PANIC_STACK_SWITCH (0x2B)
|
|
This error indicates that the kernel mode stack was overrun. This normally
|
|
occurs when a kernel-mode driver uses too much stack space. It can also
|
|
occur when serious data corruption occurs in the kernel.
|
|
|
|
PORT_DRIVER_INTERNAL (0x2C)
|
|
|
|
SCSI_DISK_DRIVER_INTERNAL (0x2D)
|
|
|
|
DATA_BUS_ERROR (0x2E)
|
|
This bugcheck is normally caused by a parity error in the system memory.
|
|
1. Virtual address that caused the fault
|
|
2. Physical address that caused
|
|
3. Processor status register (PSR)
|
|
4. Faulting instruction register (FIR)
|
|
This error can also be caused by a driver accessing a 0x8XXXXXXX address
|
|
that does not exist.
|
|
|
|
INSTRUCTION_BUS_ERROR (0x2F)
|
|
|
|
SET_OF_INVALID_CONTEXT (0x30)
|
|
|
|
PHASE0_INITIALIZATION_FAILED (0x31)
|
|
|
|
System init failed early on. Debugger is required to make sense of this
|
|
since the bugcheck tells you almost nothing.
|
|
|
|
PHASE1_INITIALIZATION_FAILED (0x32)
|
|
1 - NT Status code that describes why the system thinks initialization failed.
|
|
2 - Indicates location within init.c where phase 1 initialization failure occured
|
|
|
|
UNEXPECTED_INITIALIZATION_CALL (0x33)
|
|
|
|
CACHE_MANAGER (0x34)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
NO_MORE_IRP_STACK_LOCATIONS (0x35)
|
|
1 - Address of the IRP
|
|
|
|
A higher level driver has attempted to call a lower level driver through
|
|
the IoCallDriver() interface, but there are no more stack locations in the
|
|
packet, hence, the lower level driver would not be able to access its
|
|
parameters, as there are no parameters for it. This is a disasterous
|
|
situation, since the higher level driver "thinks" it has filled in the
|
|
parameters for the lower level driver (something it MUST do before it calls
|
|
it), but since there is no stack location for the latter driver, the former
|
|
has written off of the end of the packet. This means that some other memory
|
|
has probably been trashed at this point.
|
|
|
|
DEVICE_REFERENCE_COUNT_NOT_ZERO (0x36)
|
|
1 - Address of the device object
|
|
|
|
A device driver has attempted to delete one of its device objects from the
|
|
system but the reference count for that object was non-zero, meaning that
|
|
there are still outstanding references to the device. (The reference count
|
|
indicates the number of reasons why this device object cannot be deleted.)
|
|
This is a bug in the calling device driver.
|
|
|
|
FLOPPY_INTERNAL_ERROR (0x37)
|
|
|
|
SERIAL_DRIVER_INTERNAL (0x38)
|
|
|
|
SYSTEM_EXIT_OWNED_MUTEX (0x39)
|
|
|
|
SYSTEM_UNWIND_PREVIOUS_USER (0x3A)
|
|
|
|
SYSTEM_SERVICE_EXCEPTION (0x3B)
|
|
|
|
INTERRUPT_UNWIND_ATTEMPTED (0x3C)
|
|
|
|
INTERRUPT_EXCEPTION_NOT_HANDLED (0x3D)
|
|
|
|
MULTIPROCESSOR_CONFIGURATION_NOT_SUPPORTED (0x3E)
|
|
The system has multiple processors, but they are asymmtric in relation
|
|
to one another. In order to be symmtric 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. Additionaly, on x86
|
|
systems all processors must either have floating point capabilities, or
|
|
none should.
|
|
|
|
387 - MP machine with mix of 386/486, FP and non-FP, etc.
|
|
(This is NOT hal mismatch, that's 0x79, see below.)
|
|
|
|
|
|
NO_MORE_SYSTEM_PTES (0x3F)
|
|
1 - PTE Type (0 - system expansion, 1 nonpaged pool expansion)
|
|
2 - Requested size
|
|
3 - Total free system PTEs
|
|
4 - Total system PTEs
|
|
|
|
No System PTEs left. Usually caused by a driver not cleaning up
|
|
properly. If kernel debugger available get stack trace and
|
|
"!sysptes 3".
|
|
|
|
|
|
TARGET_MDL_TOO_SMALL (0x40)
|
|
|
|
A driver has called the IoBuildPartialMdl() function and passed it an MDL
|
|
to map part of a source MDL, but the target MDL is not large enough to map
|
|
the entire range of addresses requested. This is a driver bug. The source
|
|
and target MDLs, as well as the address range length to be mapped are the
|
|
arguments to the IoBuildPartialMdl() function, i.e.;
|
|
|
|
IoBuildPartialMdl(
|
|
IN PMDL SourceMdl,
|
|
IN OUT PMDL TargetMdl,
|
|
IN PVOID VirtualAddress,
|
|
IN ULONG Length
|
|
)
|
|
|
|
MUST_SUCCEED_POOL_EMPTY (0x41)
|
|
|
|
1 - size of the request that could not be satisfied
|
|
2 - number of pages used of nonpaged pool
|
|
3 - number of > PAGE_SIZE requests from nonpaged pool
|
|
4 - number of pages available
|
|
|
|
If debugger available, !vm command lists various sizes.
|
|
|
|
ATDISK_DRIVER_INTERNAL (0x42)
|
|
|
|
NO_SUCH_PARTITION (0x43)
|
|
|
|
MULTIPLE_IRP_COMPLETE_REQUESTS (0x44)
|
|
1 - Address of the IRP
|
|
|
|
A driver has requested that an IRP be completed (IoCompleteRequest()), but
|
|
the packet has already been completed. This is a tough bug to find because
|
|
the easiest case, a driver actually attempted to complete its own packet
|
|
twice, is generally not what happened. Rather, two separate drivers each
|
|
believe that they own the packet, and each attempts to complete it. The
|
|
first actually works, and the second fails. Tracking down which drivers
|
|
in the system actually did this is difficult, generally because the trails
|
|
of the first driver have been covered by the second. However, the driver
|
|
stack for the current request can be found by examining the DeviceObject
|
|
fields in each of the stack locations.
|
|
|
|
INSUFFICIENT_SYSTEM_MAP_REGS (0x45)
|
|
|
|
DEREF_UNKNOWN_LOGON_SESSION (0x46)
|
|
|
|
REF_UNKNOWN_LOGON_SESSION (0x47)
|
|
|
|
CANCEL_STATE_IN_COMPLETED_IRP (0x48)
|
|
1 - Pointer to the IRP
|
|
|
|
This bugcheck indicates that an I/O Request Packet (IRP) that is to be
|
|
cancelled, has a cancel routine specified in it -- meaning that the packet
|
|
is in a state in which the packet can be cancelled -- however, the packet
|
|
no longer belongs to a driver, as it has entered I/O completion. This is
|
|
either a driver bug, or more than one driver is accessing the same packet,
|
|
which is not likely and much more difficult to find.
|
|
|
|
PAGE_FAULT_WITH_INTERRUPTS_OFF (0x49)
|
|
|
|
Means exactly what it says, treat it as a case of 0x0A above.
|
|
|
|
IRQL_GT_ZERO_AT_SYSTEM_SERVICE (0x4A)
|
|
|
|
STREAMS_INTERNAL_ERROR (0x4B)
|
|
|
|
FATAL_UNHANDLED_HARD_ERROR (0x4C)
|
|
|
|
If a hard error occurs during system booting before windows is up, and
|
|
the hard error is a real error, the system will blue screen crash.
|
|
|
|
Some common cases are:
|
|
|
|
x218 - This means a necessary registry hive file could not be
|
|
loaded. The obvious reason is if it is corrupt or missing.
|
|
In this case, either the Emergency Repair Disk or a
|
|
reinstall is required.
|
|
|
|
Some less obvious reasons are that the driver has corrupted
|
|
the registry data while loading into memory, or the memory
|
|
where the registry file was loaded is not actually memory.
|
|
In particular, AST EISA machines with 16MB or more of memory
|
|
must have access to the memory above 16MB ENABLED in the
|
|
Eisa Config Utility, or else a registry file is liable to get
|
|
loaded in this spot, but will return just 0xffffffff when
|
|
we look at the memory.
|
|
|
|
x21a - This means that either winlogon, or csrss (windows) died
|
|
unexpectedly. The exit code tells more information. Usually
|
|
it is c0000005 meaning that an unhandled exception crashed
|
|
either of these processes. There is not much you can do
|
|
unless this becomes a persistent problem.
|
|
|
|
x221 - This means that a driver is corrupt, or a system DLL was
|
|
detected to be corrupt. We do our best to integrety check
|
|
drivers and important system DLLs, and if they are corrupt,
|
|
the blue screen the name of the corrupt file. This prevents
|
|
crashes from occuring when we stumble into the corruption
|
|
later. Boot an alternate OS, or reinstall if no alternate
|
|
exists. Make sure the on disk file that is listed as bad
|
|
matches the version on CD and replace if necessary. In some
|
|
cases, random corruption can mean that there is a hardware
|
|
problem in our I/O path to the file.
|
|
|
|
NO_PAGES_AVAILABLE (0x4D)
|
|
1 - Number of dirty pages
|
|
2 - number of physical pages in machine
|
|
3 - extended commit value in pages
|
|
4 - total commit value in pages
|
|
|
|
No free pages available to continue operations.
|
|
If kernel debugger available "!process 0 7", "!vm"
|
|
and "dd mmpagingfiles" followed by "dd @$p".
|
|
|
|
|
|
PFN_LIST_CORRUPT (0x4E)
|
|
1 - value 1
|
|
2 - ListHead value which was corrupt
|
|
3 - number of pages available
|
|
4 - 0
|
|
|
|
1 - value 2
|
|
2 - entry in list being removed
|
|
3 - highest physical page number
|
|
4 - reference count of entry being removed
|
|
|
|
Caused by corrupting I/O driver structures. If kernel debugger
|
|
available get stack trace.
|
|
|
|
|
|
NDIS_INTERNAL_ERROR (0x4F)
|
|
|
|
PAGE_FAULT_IN_NONPAGED_AREA (0x50)
|
|
|
|
REGISTRY_ERROR (0x51)
|
|
1 - value 1 (indicates where we bugchecked)
|
|
2 - value 2 (indicates where we bugchecked)
|
|
3 - depends on where it bugchecked, may be pointer to hive
|
|
4 - depends on where it bugchecked, may be return code of
|
|
HvCheckHive if the hive is corrupt.
|
|
|
|
Something has gone horribly wrong with the registry. If a kernel debugger
|
|
is available, get a stack trace.
|
|
|
|
If the stack trace indicates we are in a system worker thread (CmpWorker
|
|
will be on the call list) do the following kernel debugger commands:
|
|
|
|
dd CmpRegistryMutex+18 L1
|
|
!thread <whatever value the above command printed out>
|
|
|
|
This will give you the thread and stacktrace that made the registry call.
|
|
|
|
It can also indicate that the registry got an I/O error while trying to
|
|
read one of its files, so it can be caused by hardware problems or
|
|
filesystem corruption.
|
|
|
|
It may occur due to a failure in a refresh operation, which is used only
|
|
in by the security system, and then only when resource limits are encountered.
|
|
When you see this bugcode, be sure to ask if the machine is a PDC or BDC,
|
|
and how many accounts are in its sam, whether it might be a replication target,
|
|
and whether the volume where the hive files reside is nearly full.
|
|
|
|
MAILSLOT_FILE_SYSTEM (0x52)
|
|
|
|
NO_BOOT_DEVICE (0x53)
|
|
|
|
LM_SERVER_INTERNAL_ERROR (0x54)
|
|
|
|
DATA_COHERENCY_EXCEPTION (0x55)
|
|
|
|
INSTRUCTION_COHERENCY_EXCEPTION (0x56)
|
|
|
|
XNS_INTERNAL_ERROR (0x57)
|
|
|
|
FTDISK_INTERNAL_ERROR (0x58)
|
|
|
|
The system was booted from a revived primary partition so
|
|
the hives say the mirror is ok, when in fact it is not.
|
|
The "real" image of the hives are on the shadow.
|
|
The user must boot from the shadow.
|
|
|
|
PINBALL_FILE_SYSTEM (0x59)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
CRITICAL_SERVICE_FAILED (0x5A)
|
|
|
|
SET_ENV_VAR_FAILED (0x5B)
|
|
|
|
HAL_INITIALIZATION_FAILED (0x5C)
|
|
|
|
UNSUPPORTED_PROCESSOR (0x5D)
|
|
386 - System failed because the processor is only 386 instructions set
|
|
compatible. The system requires a 486 compatible or better processor.
|
|
|
|
HEAP_INITIALIZATION_FAILED (0x5D)
|
|
|
|
OBJECT_INITIALIZATION_FAILED (0x5E)
|
|
|
|
SECURITY_INITIALIZATION_FAILED (0x5F)
|
|
|
|
PROCESS_INITIALIZATION_FAILED (0x60)
|
|
|
|
HAL1_INITIALIZATION_FAILED (0x61)
|
|
|
|
OBJECT1_INITIALIZATION_FAILED (0x62)
|
|
|
|
SECURITY1_INITIALIZATION_FAILED (0x63)
|
|
|
|
SYMBOLIC_INITIALIZATION_FAILED (0x64)
|
|
|
|
MEMORY1_INITIALIZATION_FAILED (0x65)
|
|
|
|
CACHE_INITIALIZATION_FAILED (0x66)
|
|
|
|
CONFIG_INITIALIZATION_FAILED (0x67)
|
|
1 - 5
|
|
2 - indicates location in ntos\config\cmsysini that failed
|
|
|
|
This means the registry couldn't allocate the pool needed to contain the
|
|
registry files. This should never happen, since it is early enough in
|
|
system initialization that there is always plenty of paged pool available.
|
|
|
|
FILE_INITIALIZATION_FAILED (0x68)
|
|
|
|
IO1_INITIALIZATION_FAILED (0x69)
|
|
|
|
Initialization of the I/O system failed for some reason. There is
|
|
practically no other information available. In general, setup really made
|
|
some bad decisions about the installation of the system, or the user has
|
|
reconfigured the system.
|
|
|
|
LPC_INITIALIZATION_FAILED (0x6A)
|
|
|
|
PROCESS1_INITIALIZATION_FAILED (0x6B)
|
|
1 - Indicates the status code that tripped us into thinking that
|
|
initialization failed.
|
|
2 - Indicates the location in ntos\ps\psinit.c where the failure
|
|
was detected.
|
|
|
|
REFMON_INITIALIZATION_FAILED (0x6C)
|
|
|
|
SESSION1_INITIALIZATION_FAILED (0x6D)
|
|
1 - Indicates the NT status code that tripped us into thinking
|
|
that initialization failed.
|
|
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the location in
|
|
ntos\init\init.c where the failure was detected.
|
|
|
|
SESSION2_INITIALIZATION_FAILED (0x6E)
|
|
1 - Indicates the NT status code that tripped us into thinking
|
|
that initialization failed.
|
|
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the location in
|
|
ntos\init\init.c where the failure was detected.
|
|
|
|
SESSION3_INITIALIZATION_FAILED (0x6F)
|
|
1 - Indicates the NT status code that tripped us into thinking
|
|
that initialization failed.
|
|
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the location in
|
|
ntos\init\init.c where the failure was detected.
|
|
|
|
SESSION4_INITIALIZATION_FAILED (0x70)
|
|
1 - Indicates the NT status code that tripped us into thinking
|
|
that initialization failed.
|
|
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the location in
|
|
ntos\init\init.c where the failure was detected.
|
|
|
|
SESSION5_INITIALIZATION_FAILED (0x71)
|
|
1 - Indicates the NT status code that tripped us into thinking
|
|
that initialization failed.
|
|
|
|
The bugcheck code (SESSION1 - SESSION5) indicates the location in
|
|
ntos\init\init.c where the failure was detected.
|
|
|
|
ASSIGN_DRIVE_LETTERS_FAILED (0x72)
|
|
|
|
CONFIG_LIST_FAILED (0x73)
|
|
|
|
1 - 5
|
|
2 - 2
|
|
3 - index of hive in list
|
|
4 - pointer to UNICODE_STRING containing filename of hive
|
|
|
|
Indicates that one of the core system hives is corrupt or
|
|
unreadable. This can be either SOFTWARE, SECURITY or SAM.
|
|
|
|
BAD_SYSTEM_CONFIG_INFO (0x74)
|
|
|
|
Can indicate that the SYSTEM hive loaded by the osloader/NTLDR
|
|
was corrupt. This is unlikely, since the osloader will check
|
|
a hive to make sure it isn't corrupt after loading it.
|
|
|
|
It can also indicate that some critical registry keys and values
|
|
are not present. (i.e. somebody used regedt32 to delete something
|
|
that they shouldn't have) Booting from LastKnownGood may fix
|
|
the problem, but if someone is persistent enough in mucking with
|
|
the registry they will need to reinstall or use the Emergency
|
|
Repair Disk.
|
|
|
|
CANNOT_WRITE_CONFIGURATION (0x75)
|
|
|
|
This will result if the SYSTEM hive files (SYSTEM and SYSTEM.ALT)
|
|
cannot be grown to accomodate additional data written into it
|
|
between registry initialization and phase one initialization
|
|
(when the filesystems are available)
|
|
|
|
It usually means there are 0 bytes of free space available on the
|
|
drive.
|
|
|
|
You cannot store the registry on a read-only device.
|
|
|
|
PROCESS_HAS_LOCKED_PAGES (0x76)
|
|
1 - process address
|
|
2 - number of locked pages
|
|
3 - number of private pages
|
|
4 - 0
|
|
|
|
Caused by a driver not cleaning up completely after an I/O.
|
|
|
|
KERNEL_STACK_INPAGE_ERROR (0x77)
|
|
1 - 0
|
|
2 - value found in stack where signature should be
|
|
3 - 0
|
|
4 - address of signature on kernel stack
|
|
|
|
1 - status code
|
|
2 - i/o status code
|
|
3 - page file number
|
|
4 - offset into page file
|
|
|
|
The requested page of kernel data could not be read in. Caused by
|
|
bad block in paging file or disk controller error (in extremely
|
|
rare cases, caused by running out of resources, specifically,
|
|
nonpaged pool with status of c0000009a (STATUS_INSUFFICIENT_RESOURCES).
|
|
|
|
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 knowlege base article on SCSI termination.
|
|
|
|
PHASE0_EXCEPTION (0x78)
|
|
|
|
MISMATCHED_HAL (0x79)
|
|
1 - type of mismatch
|
|
type 1:
|
|
The PRCB release levels mismatch. (something is out of date)
|
|
2 - Major PRCB level of ntoskrnl.exe
|
|
3 - Major PRCB level of hal.dll
|
|
|
|
type 2:
|
|
The build types mismatch.
|
|
2 - Build type of ntoskrnl.exe
|
|
3 - Build type of hal.dll
|
|
|
|
Build type
|
|
0 = Free multiprocessor enabled build
|
|
1 = Checked multiprocessor enabled build
|
|
2 = Free uniprocessor build
|
|
|
|
type 3:
|
|
Microchannel computers require a micro-channel specific hal.
|
|
This type would means that there is a mis-match.
|
|
2 - Machine type as detected by ntdetect.com
|
|
A value of a 2 would mean the computer is MCA
|
|
3 - Machine type which hal supports:
|
|
A value of a 2 would mean the hal is built for MCA
|
|
|
|
The HAL revision level and HAL configuration type does not match that
|
|
of the kernel or the machine type. This would probabily happen if the
|
|
user has manually updated either ntoskrnl.exe or hal.dll and managed to
|
|
get a conflict.
|
|
|
|
You have an MP (multi-processor) Hal and a UP (uni-processor) Kernel,
|
|
or the reverse.
|
|
|
|
KERNEL_DATA_INPAGE_ERROR (0x7A)
|
|
1 - lock type that was held (value 1,2,3, or PTE address)
|
|
2 - error status (normally i/o status code)
|
|
3 - current process (virtual address for lock type 3, or PTE)
|
|
4 - virtual address that could not be in-paged
|
|
|
|
The requested page of kernel data could not be read in. Caused by
|
|
bad block in paging file or disk controller error. Also see
|
|
KERNEL_STACK_INPAGE_ERROR.
|
|
|
|
INACCESSIBLE_BOOT_DEVICE (0x7B)
|
|
1 - Pointer to the device object or Unicode string of ARC name
|
|
|
|
During the initialization of the I/O system, it is possible that the driver
|
|
for the boot device failed to initialize the device that the system is
|
|
attempting to boot from, or it is possible for the file system that is
|
|
supposed to read that device to either fail its initialization or to simply
|
|
not recognize the data on the boot device as a file system structure that
|
|
it recognizes. In the former case, the argument (#1) is the address of a
|
|
Unicode string data structure that is the ARC name of the device from which
|
|
the boot was being attempted. In the latter case, the argument (#1) is the
|
|
address of the device object that could not be mounted.
|
|
|
|
If this is the initial setup of the system, then this error can occur if
|
|
the system was installed on an unsupported disk or SCSI controller. Note
|
|
that some controllers are supported only by drivers which are in the Windows
|
|
Driver Library (WDL) which requires the user to do a custom install. See
|
|
the Windows Driver Library for more information.
|
|
|
|
This error can also be caused by the installation of a new SCSI adapter or
|
|
disk controller or repartitioning the disk with the system partition. If
|
|
this is the case, on x86 systems the boot.ini file must be edited or on ARC
|
|
systems setup must be run. See the "Advanced Server System Administrator's
|
|
User Guide" for information on changing boot.ini.
|
|
|
|
If the argument is a pointer to an ARC name string, then the format of the
|
|
first two (and in this case only) longwords will be:
|
|
|
|
USHORT Length;
|
|
USHORT MaximumLength;
|
|
PVOID Buffer;
|
|
|
|
That is, the first longword will contain something like 00800020 where 20
|
|
is the actual length of the Unicode string, and the next longword will
|
|
contain the address of buffer. This address will be in system space, so
|
|
the high order bit will be set.
|
|
|
|
If the argument is a pointer to a device object, then the format of the first
|
|
word will be:
|
|
|
|
USHORT Type;
|
|
|
|
That is, the first word will contain a 0003, where the Type code will ALWAYS
|
|
be 0003.
|
|
|
|
Note that this makes it immediately obvious whether the argument is a pointer
|
|
to an ARC name string or a device object, since a Unicode string can never
|
|
have an odd number of bytes, and a device object will always have a Type
|
|
code of 3.
|
|
|
|
BUGCODE_PSS_MESSAGE (0x7C)
|
|
|
|
INSTALL_MORE_MEMORY (0x7D)
|
|
1 - Number of physical pages found
|
|
2 - Lowest physical page
|
|
3 - Highest physical page
|
|
4 - 0
|
|
|
|
Not enough memory to boot NT (needs 5mb).
|
|
|
|
WINDOWS_NT_BANNER (0x4000007E)
|
|
|
|
UNEXPECTED_KERNEL_MODE_TRAP (0x7F)
|
|
|
|
This means a trap occured in kernel mode, and its a trap of a kind
|
|
that the kernel isn't allowed to have/catch (bound trap) or that
|
|
is always instant death (double fault). The first number in the
|
|
bugcheck parens is the number of the trap (8 = double fault, etc)
|
|
Consult an Intel x86 family manual to learn more about what these
|
|
traps are.
|
|
|
|
A kb and !trap on the appropriate frame (which will be the ebp that
|
|
goes with a procedure named KiTrap...) (at least on x86) will
|
|
show where the trap was taken.
|
|
|
|
|
|
NMI_HARDWARE_FAILURE (0x80)
|
|
|
|
Hopefully MS PSS will never hear about this. The HAL is supposed
|
|
to report whatever specific data it has, and to tell the user to
|
|
call their HARDWARE vendor for support.
|
|
|
|
SPIN_LOCK_INIT_FAILURE (0x81)
|
|
|
|
SETUP_FAILURE (0x85)
|
|
|
|
(NOTE: Textmode setup no longer uses bugchecks to bail out of serious
|
|
error conditions. Therefore, you will never encounter a bugcheck 0x85.
|
|
All bugchecks have been replaced with friendlier and (where possible)
|
|
more descriptive error messages. Some of the former bugchecks, however,
|
|
have simply been replaced by our own bugcheck screen, and the codes for
|
|
these error conditions are the same as before. These are documented below.)
|
|
|
|
The first extended bugcheck field is a code indicating what the
|
|
problem is, and the other fields are used differently depending on
|
|
that value.
|
|
|
|
1 -
|
|
0: The oem hal font is not a valid .fon format file, and so setup
|
|
is unable to display text.
|
|
This indicates that vgaxxx.fon on the boot floppy or CD-ROM
|
|
is damaged.
|
|
|
|
1: Video initialization failed. NO LONGER A BUGCHECK CODE.
|
|
This error now has its own error screen, and the user is only
|
|
presented with the two relevant parameters detailed below.
|
|
|
|
This may indicate that the disk containing vga.sys
|
|
(or other video driver appropriate to the machine)
|
|
is damaged or that machine has video hardware that
|
|
we cannot communicate with.
|
|
|
|
2 - What failed:
|
|
0: NtCreateFile of \device\video0
|
|
1: IOCTL_VIDEO_QUERY_NUM_AVAIL_MODES
|
|
2: IOCTL_VIDEO_QUERY_AVAIL_MODES
|
|
3: Desired video mode not supported. This is indicative of
|
|
an internal setup error.
|
|
4: IOCTL_VIDEO_SET_CURRENT_MODE (unable to set video mode)
|
|
5: IOCTL_VIDEO_MAP_VIDEO_MEMORY
|
|
6: IOCTL_VIDEO_LOAD_AND_SET_FONT
|
|
|
|
3 - Status code from NT API call, if appropriate.
|
|
|
|
2: Out of memory. NO LONGER A BUGCHECK CODE.
|
|
This error now uses a more friendly error screen that works regardless
|
|
of how far along in setup we are.
|
|
|
|
3: Keyboard initialization failed. NO LONGER A BUGCHECK CODE.
|
|
There are now 2 error screens for the two different possible errors
|
|
we can get here.
|
|
This may indicate that the disk containing the keyboard driver
|
|
(i8042prt.sys or kbdclass.sys) is damaged or that machine has
|
|
keyboard hardware we cannot communicate with.
|
|
|
|
It may also mean that the keyboard layout dll could not be loaded.
|
|
|
|
2 - What failed:
|
|
0: NtCreateFile of \device\KeyboardClass0 failed.
|
|
"Setup did not find a keyboard connected to your computer."
|
|
1: Unable to load keyboard layout dll.
|
|
"Setup could not load the keyboard layout file <filename>."
|
|
Indicates that the cd or floppy is missing a file (kbdus.dll
|
|
for us release, other layout dlls for localized ones).
|
|
|
|
4: Setup was unable to resolve the ARC device pathname of
|
|
the device from which setup was started. This is an internal
|
|
Setup error.
|
|
|
|
5: Partitioning sanity check failed. This indicates a bug in
|
|
a disk driver. The parameters are meaningful only to the setup
|
|
group.
|
|
|
|
MBR_CHECKSUM_MISMATCH (0x8B)
|
|
|
|
This message occurs during the boot process when the MBR checksum the system
|
|
calculates does not match the checksum passed in by the loader. This is usually
|
|
an indication of a virus. There are many forms of viruses and not all can be
|
|
detected. The newer ones usually can only be detected by a virus scanner that
|
|
has recently been upgraded. Boot a write-protected disk containing a virus
|
|
scanner and attempt to clean out the infection.
|
|
|
|
KerBugCheckEx parameters:
|
|
|
|
1 - Disk Signature from MBR.
|
|
2 - MBR check sum calculated by osloader.
|
|
3 - MBR checksum calculated by system.
|
|
|
|
PP0_INITIALIZATION_FAILED (0x8F)
|
|
|
|
This message occurs if phase 0 initialization of the kernel-mode Plug and
|
|
Play Manager failed. There's really nothing going on here that could cause
|
|
a failure.
|
|
|
|
PP1_INITIALIZATION_FAILED (0x90)
|
|
|
|
This message occurs if phase 1 initialization of the kernel-mode Plug and
|
|
Play Manager failed. This is where we do most of our initialization,
|
|
including setting up the environment (registry, etc.) for drivers to
|
|
subsequently call during I/O init.
|
|
|
|
|
|
UP_DRIVER_ON_MP_SYSTEM (0x92)
|
|
|
|
This message occurs if a UNIPROCESSOR only driver is loaded on a MultiProcessor
|
|
system with more than one active processor.
|
|
|
|
KeBugCheckEx parameters:
|
|
|
|
1 - The Base address of the driver.
|
|
|
|
INVALID_KERNEL_HANDLE (0x93)
|
|
|
|
This message occurs if kernel code (server, redirector, other driver, etc.) attempts
|
|
to close a handle that is not a valid handle.
|
|
|
|
1 - The handle that NtClose was called with.
|
|
|
|
2 - 0 means a protected handle was closed.
|
|
1 means an invalid handle was closed.
|
|
|
|
KERNEL_STACK_LOCKED_AT_EXIT (0x94)
|
|
|
|
This message occurs when a thread exits while it's kernel stack is
|
|
marked as not swapable
|
|
|
|
INVALID_WORK_QUEUE_ITEM (0x96)
|
|
|
|
This message occurs when KeRemoveQueue removes a queue entry whose flink
|
|
or blink field is null. This is almost always called by code misusing
|
|
worker thread work items, but any queue misuse can caus this. The rule
|
|
is that an entry on a queue may only be inserted on the list once. When an
|
|
item is removed from a queue, it's flink field is set to NULL. This bugcheck
|
|
occurs when remove queue attempts to remove an entry, but the flink or blink field
|
|
is NULL. In order to debug this problem, you need to know the queue being referenced.
|
|
If the queue is one of the EX worker queues (ExWorkerQueue), then the item being
|
|
removed is a WORK_QUEUE_ITEM (see ex.h). This bugcheck assumes that this is the case.
|
|
The bugcheck ex parameters are designed to help identify the driver misusing the queue
|
|
item.
|
|
|
|
BOUND_IMAGE_UNSUPPORTED (0x97)
|
|
|
|
MmLoadSystemImage was called to load a bound image.
|
|
This is not supported in the kernel. Make sure bind.exe was not run on the
|
|
image.
|
|
|
|
|
|
KeBugCheckEx parameters:
|
|
|
|
1 - The address of the queue entry whose flink/blink field is NULL
|
|
2 - The address of the queue being references. Usually this is one
|
|
of the ExWorkerQueues.
|
|
3 - The base address of the ExWorkerQueue array. This will help determine if
|
|
the queue in question is an ExWorkerQueue and if so, the offset from this
|
|
parameter will isolate the queue.
|
|
4 - If this is an ExWorkerQueue (which it usually is), this is the address of the
|
|
worker routine that would have been called if the work item was valid. This
|
|
can be used to isolate the driver that is misusing the work queue.
|
|
|
|
|
|
END_OF_NT_EVALUATION_PERIOD (0x98)
|
|
|
|
Your NT System is an evaluation unit with an expiration date. The trial period is over.
|
|
|
|
KeBugCheckEx parameters:
|
|
|
|
1 - The low order 32 bits of your instalation date
|
|
2 - The high order 32 bits of your instalation date
|
|
3 - The trial period in minutes
|
|
|
|
INVALID_REGION_OR_SEGMENT (0x99)
|
|
|
|
ExInitializeRegion or ExInterlockedExtendRegion was called with an invalid
|
|
set of parameters.
|
|
|
|
SYSTEM_LICENSE_VIOLATION (x9a)
|
|
|
|
A violation of the software license agreement has occured. This can be due to either
|
|
attempting to change the product type of an offline system, or an attempt to change
|
|
the trial period of an evaluation unit of NT.
|
|
|
|
1 - 0 means that offline product type changes were attempted
|
|
2 - if 1, product should be LanmanNT or ServerNT. If 0, should be WinNT
|
|
3 - partial serial number
|
|
4 - first two characters of product type from product options.
|
|
|
|
1 means that offline changes to the nt evaluation unit time period
|
|
2 - registered evaluation time from source 1
|
|
3 - partial serial number
|
|
4 - registered evaluation time from alternate source
|
|
|
|
|
|
2 means that the setup key could not be opened
|
|
2 - status code associated with the open failure
|
|
|
|
3 - The SetupType value from the setup key is missing so gui setup
|
|
mode could not be detected
|
|
2 - status code associated with the key lookup failure
|
|
|
|
4 - The SystemPrefix value from the setup key is missing
|
|
2 - status code associated with the key lookup failure
|
|
|
|
4 - The SystemPrefix value from the setup key is missing
|
|
|
|
5 - means that offline changes were made to the number of licensed processors
|
|
2 - see setup code
|
|
3 - invalid value found in licensed processors
|
|
4 - officially licensed number of processors
|
|
|
|
6 - means that ProductOptions key could not be opened
|
|
2 - status code associated with the open failure
|
|
|
|
7 - means that ProductType value could not be read
|
|
2 - status code associated with the read failure
|
|
|
|
8 - means that Change Notify on ProductOptions failed
|
|
2 - status code associated with the change notify failure
|
|
|
|
9 - means that Change Notify on SystemPrefix failed
|
|
2 - status code associated with the change notify failure
|
|
|
|
10 - Looks like an NTW system was converted to an NTS system
|
|
|
|
11 - Reference of setup key failed
|
|
2 - status code associated with the change failure
|
|
|
|
12 - Reference of product options key failed
|
|
2 - status code associated with the change failure
|
|
|
|
13 - Open of ProductOptions in worker thread failed
|
|
2 - status code associated with the failure
|
|
|
|
16 - Failure occured in the setup key worker thread
|
|
2 - status code associated with the failure
|
|
3 - 0 means set value failed, 1 means change notify failed
|
|
|
|
17 - Failure occured in the product options key worker thread
|
|
2 - status code associated with the failure
|
|
3 - 0 means set value failed, 1 means change notify failed
|
|
|
|
|
|
KeBugCheckEx parameters;
|
|
|
|
1 - The segment address which must reside on a quadword boundary.
|
|
2 - The segment size which must be greater than the block size plus
|
|
the size of a segment header.
|
|
3 - The block size which must be a multiple of eight and smaller than
|
|
the segment size minus the size of the segment header.
|
|
|
|
UDFS_FILE_SYSTEM (0x9B)
|
|
See the comment for FAT_FILE_SYSTEM
|
|
|
|
MACHINE_CHECK_EXCEPTION (0x9C)
|
|
|
|
A fatal Machine Check Exception has occurred.
|
|
|
|
KeBugCheckEx parameters;
|
|
|
|
If the processor has ONLY MCE feature available (For example Intel Pentium),
|
|
the parameters are:
|
|
|
|
1 - Low 32 bits of P5_MC_TYPE MSR
|
|
2 -
|
|
3 - High 32 bits of P5_MC_ADDR MSR
|
|
4 - Low 32 bits of P5_MC_ADDR MSR
|
|
|
|
If the processor also has MCA feature available (For example Intel
|
|
Pentium Pro), the parameters are:
|
|
|
|
1 - Bank number
|
|
2 - Address field of MCi_ADDR MSR for the MCA bank that had the error
|
|
3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
|
|
4 - Low 32 bits of MCi_STATUS MSR for the MCA bank that had the error
|