You are currently offline, waiting for your internet to reconnect

Stop 7F, 0x00000008 (double-fault) error occurs because of a single-bit error in the ESP register

Support for Windows XP has ended

Microsoft ended support for Windows XP on April 8, 2014. This change has affected your software updates and security options. Learn what this means for you and how to stay protected.

Support for Windows Server 2003 ended on July 14, 2015

Microsoft ended support for Windows Server 2003 on July 14, 2015. This change has affected your software updates and security options. Learn what this means for you and how to stay protected.

SUMMARY
This document discusses why Windows may display a "STOP 0x0000007F, 0x00000008" error message on your computer because of a specific processor error. This error message may be displayed when a single-bit error occurs in the ESP register of a processor that is running on the computer. The article describes methods to help you troubleshoot this error.
SYMPTOMS
On a computer that is running one or more Intel Xeon processors, or that is running other processors, Windows may display a Stop error message that is similar to the following:
STOP 0x0000007F (0x00000008, 0x00000000, 0x00000000, 0x00000000) UNEXPECTED_KERNEL_MODE_TRAP


When this problem occurs, the following conditions are true:
  • The first parameter of the Stop error is "0x0000008". (This error is a double-fault exception.)
  • Because of a single-bit error in the upper half of the ESP register, the value in the ESP register is outside the stack range of the current thread.
CAUSE
This problem occurs if one or more of the processors in the computer:
  • Require a microcode update that is not applied by the computer's basic input/output system (BIOS).
  • Are damaged or defective.
  • Are operating outside their specified ranges for temperature, power, or other conditions.
RESOLUTION
To resolve this problem, use one of the following troubleshooting methods.

Method 1: Determine if the processor is running the production revision of the microcode update

A microcode update corrects errata, or bugs, in a processor's internally implemented logic. Microcode updates cannot be permanently stored in the processor itself and must be loaded into the processor every time that the computer starts. Microcode updates can be applied by the computer's BIOS or by the Update.sys driver.

To identify the revision of the microcode update that is currently applied to an Intel processor that is installed on your computer, follow these steps:
  1. Download the Intel Processor Frequency ID Utility from the following Intel Web site:
  2. Install and run the Intel Processor Frequency ID Utility on the computer that is experiencing symptoms.
  3. Write down the following CPU information for each processor:
    • CPU Family
    • CPU Model
    • CPU Stepping
    • CPU Revision
    The CPU Family, CPU Model, and CPU Stepping values identify the specific type of processor. The CPU Revision value identifies the revision of the microcode update that is applied.
  4. Contact your computer manufacturer to determine whether the revision of the microcode update is the most current revision that is available for a particular processor. If the revision is not the most current, ask your computer manufacturer for an updated BIOS that will apply the most current microcode update revision.
The symptoms that are described in this article have been observed most frequently on Intel Xeon processors that have the CPU Family, CPU Model, and CPU Stepping values of 15, 2, and 9 respectively and that are installed on motherboards that use ServerWorks chipsets. (The CPU Family, CPU Model, and CPU Stepping hexadecimal values are F, 2, and 9 respectively.) These processors require a revision value of 0x18 or later to function correctly. (0x18 is equivalent to a decimal value of 24.)

A revision value of 0 indicates that the computer BIOS does not have the correct microcode update for the processors that are installed in the computer. You must update the BIOS with a microcode update revision that supports the processors that you are using.

Intel recommends that you apply the latest microcode update revisions to help avoid known issues.

Method 2: Determine if a processor is damaged or defective

If the processors that are installed in the affected computers have the production microcode update revision applied, and the symptoms that are described in this article do not occur on all computers of the same model that are running the same processors, the processors may be defective.

To determine if a processor is damaged or defective, move the processor to a computer that is not experiencing any symptoms.

Warning If you change processors, follow instructions that are provided by your computer manufacturer, or engage appropriately qualified hardware technicians to change the processors.

If the symptoms continue to occur on the original computer with the replacement processor, but not on the other computer with the original processor, the problem is probably not caused by a damaged or a defective processor.

If the symptoms do not continue to occur on the original computer with the replacement processor, but do occur on the other computer with the original processor, the problem is probably caused by a damaged or a defective processor. In this case, contact your computer manufacturer to replace the original processor.

If the computer that is experiencing the symptoms that are described in this article has more that one processor, move all processors to the other computer. If the results indicate that one or more of these processors may be defective, move processors one at a time to determine the processor or processors that may be defective.

Method 3: Determine if a processor is operating outside a specified range of environmental conditions

Excessive room temperature, bad ventilation, or dust accumulation can cause electronic components, such as processors, to behave erratically. Malfunctioning fans or blocked air passages can cause ventilation problems. If the interior or the air passages of the computer are dusty, or if the computer exhibits symptoms when it is installed only in a particular location, system overheating may be a factor. Make sure that components are clean, that fans are functioning correctly, and that air passages are not obstructed. Additionally, make sure that the room where the computer is located is adequately ventilated. The temperature of the room must be in the operating range that is specified by the computer manufacturer.

Voltage that is higher or lower than specified, or that fluctuates, may cause processors and other electronic components to behave erratically. Incorrect or inconsistent main power voltage, an overloaded or improperly functioning power supply in the computer, or improperly functioning motherboard circuitry may cause incorrect or inconsistent voltage to be supplied to the processor. Contact the appropriate technicians to verify whether any one of these issues may be the cause of symptoms.
For information about how to contact your computer manufacturer, visit the following Microsoft Web site:
MORE INFORMATION
For additional information about "STOP 0x0000007F" errors, click the following article number to view the article in the Microsoft Knowledge Base:
137539 General causes of STOP 0x0000007F errors
The ESP register is also known as the stack pointer register. A stack is a data structure in memory that is used to store information about the current state of the execution of a thread. A thread's stack is used to keep track of function calls in progress, of parameters that are passed to those functions, and of variables that are used by those functions. The value in the ESP register is expected to point to the current top of the stack. If the value in ESP is incorrect, it may point to incorrect information or to an invalid address. If the value in ESP points to an invalid address, a double-fault exception may occur.

To determine if the Stop error is the result of a single-bit error in the ESP register, follow these steps:
  1. Install the Microsoft Debugging Tools for Windows. To download the tools, visit the following Microsoft Web site:
  2. Run the WinDbg tool, click File, click Open Crash Dump to locate the memory dump file that contains the Stop error information, and then click OK.

    The initial bugcheck analysis typically appears similar to the following:
    ********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************Use !analyze -v to get detailed debugging information.BugCheck 7F, {8, 0, 0, 0}Probably caused by : ntkrnlmp.exe ( nt!KiUnlockDispatcherDatabase+1c )Followup: MachineOwner
  3. Run the !analyze -v command to obtain an automated analysis of the dump file. The following is an example of the output of the !analyze -v command:
    0: kd> !analyze -v********************************************************************************                                                                             **                        Bugcheck Analysis                                    **                                                                             ********************************************************************************UNEXPECTED_KERNEL_MODE_TRAP (7f)This means a trap occurred in kernel mode, and it is a trap of a kindthat the kernel isn't permitted to have/catch (bound trap) or thatis always instant death (double fault).  The first number in thebugcheck params is the number of the trap (8 = double fault, etc)Consult an Intel x86 family manual to learn more about what thesetraps are. Here is a *portion* of those codes: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 valueElse        .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)Endifkb will then show the corrected stack.Arguments:Arg1: 00000008, EXCEPTION_DOUBLE_FAULTArg2: 00000000Arg3: 00000000Arg4: 00000000Debugging Details:------------------BUGCHECK_STR:  0x7f_8TSS:  00000028 -- (.tss 28)eax=ffdff4dc ebx=f5d299dc ecx=8046f1c0 edx=00000000 esi=853e7a60 edi=00000102eip=8046a86c esp=f5da9948 ebp=f5d2997c iopl=0         nv up ei pl zr na po nccs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246nt!KiUnlockDispatcherDatabase+0x1c:8046a86c 59               pop     ecxResetting default scopeDEFAULT_BUCKET_ID:  DRIVER_FAULTLAST_CONTROL_TRANSFER:  from 80450bb3 to 8046a86cSTACK_TEXT:  f5d2997c 80450bb3 00000003 f5d299f8 00000001 nt!KiUnlockDispatcherDatabase+0x1cf5d29d48 80466389 00000003 0076fe84 00000001 nt!NtWaitForMultipleObjects+0x385f5d29d48 77f9323e 00000003 0076fe84 00000001 nt!KiSystemService+0xc90076fe5c 77e7a059 00000003 0076fe84 00000001 ntdll!ZwWaitForMultipleObjects+0xb0076feac 77dee9fb 0076fe84 00000001 00000000 KERNEL32!WaitForMultipleObjectsEx+0xea0076ff08 77deea48 0076fed4 0076ff5c 00000000 USER32!MsgWaitForMultipleObjectsEx+0x1530076ff24 6d095a7c 00000002 0076ff5c 00000000 USER32!MsgWaitForMultipleObjects+0x1d0076ff7c 780085bc 00283a90 0062f5ac 0062ffdc IisRTL!SchedulerWorkerThread+0xa70076ff90 8042fa31 85400680 0076ff88 ffffffff MSVCRT!_endthreadex+0xc100283ab8 ffffffff 00000000 00000000 00000000 nt!KiDeliverApc+0x1a100283ab8 ffffffff 00000000 00000000 00000000 0xffffffff0000096c 00000000 00000000 00000000 00000000 0xffffffffFOLLOWUP_IP: nt!KiUnlockDispatcherDatabase+1c8046a86c 59               pop     ecxSYMBOL_STACK_INDEX:  0FOLLOWUP_NAME:  MachineOwnerSYMBOL_NAME:  nt!KiUnlockDispatcherDatabase+1cMODULE_NAME:  ntIMAGE_NAME:  ntkrnlmp.exeDEBUG_FLR_IMAGE_TIMESTAMP:  3ee650b3STACK_COMMAND:  .tss 28 ; kbBUCKET_ID:  0x7f_8_nt!KiUnlockDispatcherDatabase+1cFollowup: MachineOwner
  4. Examine the output of the !analyze -v command to see if the output shows a double-fault condition. If a double-fault condition exists, run the .tss 28 command to display the system state at the time of the double-fault. For example, the following output shows the values in the processor's registers at the moment when a double-fault exception occurred:
    0: kd> .tss 28eax=ffdff4dc ebx=f5d299dc ecx=8046f1c0 edx=00000000 esi=853e7a60 edi=00000102eip=8046a86c esp=f5da9948 ebp=f5d2997c iopl=0         nv up ei pl zr na po nccs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246nt!KiUnlockDispatcherDatabase+0x1c:8046a86c 59               pop     ecx
    In the previous example, the value of the ESP register is f5da9948. Generally, this value is relatively close to the value of the EBP register. In the previous example, the value of the EBP register is f5d2997c.
  5. Run the !thread command to view the current thread's stack range. A double-fault exception typically occurs when the value of the ESP register is outside the range of addresses that are reserved for the stack for the current thread. The following is an example of the output of the !thread command:
    0: kd> !threadTHREAD 853e7a60  Cid 904.96c  Teb: 7ffdc000  Win32Thread: a21a5c48 RUNNINGNot impersonatingOwning Process 85400680Wait Start TickCount    578275        Elapsed Ticks: 0Context Switch Count    38423                   LargeStackUserTime                  0:00:02.0031KernelTime                0:00:06.0640Start Address KERNEL32!BaseThreadStartThunk (0x77e5b700)Win32 Start Address MSVCRT!_threadstartex (0x78008532)Stack Init f5d2a000 Current f5d29c9c Base f5d2a000 Limit f5d27000 Call 0Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0ChildEBP RetAddr  Args to Child00000000 8046a86c 00000000 00000000 00000000 nt!_KiTrap08+0x41f5d2997c 80450bb3 00000003 f5d299f8 00000001 nt!KiUnlockDispatcherDatabase+0x1cf5d29d48 80466389 00000003 0076fe84 00000001 nt!NtWaitForMultipleObjects+0x385f5d29d48 77f9323e 00000003 0076fe84 00000001 nt!_KiSystemService+0xc90076fe5c 77e7a059 00000003 0076fe84 00000001 ntdll!ZwWaitForMultipleObjects+0xb0076feac 77dee9fb 0076fe84 00000001 00000000 KERNEL32!WaitForMultipleObjectsEx+0xea0076ff08 77deea48 0076fed4 0076ff5c 00000000 USER32!MsgWaitForMultipleObjectsEx+0x1530076ff24 6d095a7c 00000002 0076ff5c 00000000 USER32!MsgWaitForMultipleObjects+0x1d0076ff7c 780085bc 00283a90 0062f5ac 0062ffdc IisRTL!SchedulerWorkerThread+0xa70076ffb4 77e5b382 00283ab8 0062f5ac 0062ffdc MSVCRT!_threadstartex+0x8f0076ffec 00000000 78008532 00283ab8 00000000 KERNEL32!BaseThreadStart+0x52
    In the previous output, the following information indicates the stack range values:
    Stack Init f5d2a000 Current f5d29c9c Base f5d2a000 Limit f5d27000 Call 0
    When this particular thread is running, the ESP register value must always be between the Stack Base value (f5d2a000) and the Limit value (f5d27000). Generally, the value of the ESP register is relatively close to the Current value (f5d29c9c). (The Current value is also between the Stack Base value and the Limit value.) In the previous example, the value of the ESP register is f5da9948. This value is considerably outside the required range.

    You may also be able to check the stack range values by running the !pcr command. The following is an example of the output of the !pcr command:
    0: kd> !pcrPCR Processor 0 @ffdff000	NtTib.ExceptionList: f5d29d38	    NtTib.StackBase: f5d29df0	   NtTib.StackLimit: f5d27000	 NtTib.SubSystemTib: 00000000	      NtTib.Version: 00000000	  NtTib.UserPointer: 00000000	      NtTib.SelfTib: 7ffdc000	            SelfPcr: ffdff000	               Prcb: ffdff120	               Irql: 00000000	                IRR: 00000000	                IDR: ffffffff	      InterruptMode: 00000000	                IDT: 80036400	                GDT: 80036000	                TSS: 80474850	      CurrentThread: 853e7a60	         NextThread: 00000000	         IdleThread: 80470600	          DpcQueue: 
    The NtTib.StackLimit value represents the lower limit of the stack range. The NtTib.StackBase value represents a recent value of ESP. The NtTib.StackBase value may be compared against the current value of the ESP register to help identify whether there is a single-bit error in the current ESP register value.
  6. Run the .formats esp ^ ebp command to display the differences in values between the ESP and EBP registers. The stack pointer value in the EBP register will be close to the stack pointer value in the ESP register, except for the single-bit error. This command frequently reveals the single high-order bit that contains the error, especially when the error is displayed in binary format, as it is in the following example:
    0: kd> .formats esp ^ ebpEvaluate expression:  Hex:     00080034  Decimal: 524340  Octal:   00002000064  Binary:  00000000 00001000 00000000 00110100  Chars:   ...4  Time:    Tue Jan 06 17:39:00 1970  Float:   low 7.34757e-040 high 0  Double:  2.59058e-318
    If you ignore the lower, least significant digits, the single-bit difference between the ESP and EBP registers is 00000000 00001000 00000000 00000000 in binary format. The difference is 00080000 in hexadecimal format.

    This single-bit error causes the ESP register to contain an incorrect value. The incorrect value causes a double-fault exception, a bugcheck, and a system crash.
To obtain more information about your specific hardware, follow these steps:
  1. Use the !cpuinfo command to obtain CPU version information. The following is an example of the output from the !cpuinfo command.
    0: kd> !cpuinfoTargetInfo::ReadMsr is not available in the current debug sessionCP F/M/S Manufacturer  MHz Update Signature Features 0 15,2,9 GenuineIntel 2790>0000000000000000<00002fff 1 15,2,9 GenuineIntel 2790 0000000000000000 00002fff
    Although the Update Signature value may not always be accurately reported when you analyze a crash dump file, the Update Signature field generally indicates the microcode update revision that is applied to the CPU. In the previous example, this value is 0 (0000000000000000). The currently supported revision is 0x18 (0000001800000000), as shown in the following example output:
    0: kd> !cpuinfoCP F/M/S Manufacturer  MHz Update Signature FeaturesTargetInfo::ReadMsr is not available in the current debug session 0 15,2,9 GenuineIntel 2994>0000001800000000<00033fff 1 15,2,9 GenuineIntel 2994 0000001800000000 00033fff 2 15,2,9 GenuineIntel 2994 0000001800000000 00033fff 3 15,2,9 GenuineIntel 2994 0000001800000000 00033fff
  2. Use the !pcitree command to find the vendor and device identifiers (VenDev IDs) for existing Peripheral Connect Interface (PCI) devices. The following is an example of the output from the !pcitree command:
    0: kd> !pcitreeBus 0x0 (FDO Ext 85dceed8)  0600 00141166 (d=0,  f=0) devext 85dcf348 Bridge/HOST to PCI  0600 00141166 (d=0,  f=1) devext 85e110e8 Bridge/HOST to PCI  0600 00141166 (d=0,  f=2) devext 85e11ee8 Bridge/HOST to PCI  0100 00c09005 (d=2,  f=0) devext 85e11ce8 Mass Storage Controller/SCSI  0100 00c09005 (d=2,  f=1) devext 85e11ae8 Mass Storage Controller/SCSI  0300 47521002 (d=3,  f=0) devext 85e11788 Display Controller/VGA  0200 16a614e4 (d=4,  f=0) devext 85e11428 Network Controller/Ethernet  0880 a0f00e11 (d=5,  f=0) devext 85dcdee8 Base System Device/'Other' base system device  0601 02011166 (d=f, f=0) devext 85dcdb88 Bridge/PCI to ISA  0101 02121166 (d=f, f=1) devext 85dcd988 Mass Storage Controller/IDE  0c03 02201166 (d=f, f=2) devext 85dcd628 Serial Bus Controller/USB  0600 02251166 (d=f, f=3) devext 85dcd2c8 Bridge/HOST to PCI  0600 01011166 (d=11, f=0) devext 85e100e8 Bridge/HOST to PCI  0600 01011166 (d=11, f=2) devext 85e10ee8 Bridge/HOST to PCIBus 0x2 (FDO Ext 85dcecd8)  0104 00460e11 (d=2,  f=0) devext 85e0f9a8 Mass Storage Controller/RAIDBus 0x5 (FDO Ext 85dce9d8)No devices have been enumerated on this bus.Total PCI Root busses processed = 3

    For each PCI device that is listed, the first 8-digit hexadecimal value (DWORD) on each line is the VenDev ID. The Vendor ID is actually the second 4 digits of this value. For example, the first device that is listed in the previous example has a VenDev ID of 0x00141166. The Device ID is 0x0014, and the Vendor ID is 0x1166. The Vendor ID for ServerWorks is 0x1166. Therefore, this output is from a processor that is installed on a motherboard that uses ServerWorks chipsets.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
STOP, 0x0000007F, STOP 0x0000007F, 7F, error, 0x7F
Properties

Article ID: 842465 - Last Review: 06/10/2008 02:25:34 - Revision: 4.1

Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Web Edition, Microsoft Windows XP 64-Bit Edition Version 2003, Microsoft Windows XP Professional, Microsoft Windows XP Home Edition, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Server, Microsoft Windows 2000 Datacenter Server, Microsoft Windows 2000 Professional Edition

  • kbprb KB842465
Feedback
html>ft.com/c.gif?DI=4050&did=1&t=">