How to debug a system after you receive "Stop error code 0x0000000A (IRQL_NOT_LESS_OR_EQUAL)"


This article describes how to use a sample debugging session to determine the specific driver that is causing the following error message:


After you install a driver, the system stops responding, and you receive the following error message in nt!KiActivateWaiterQueue+0x27:
The initial stack trace indicates that the problem is in the Fast Fat driver.


This problem typically occurs because drivers call either the IoQueueWorkItem function or the ExQueueWorkItem function two times on the same work item before the work item has been executed.

Device drivers that statically allocate either the IO_WORKITEM structure or the WORK_QUEUE_ITEM structure are particularly prone to this problem. Device drivers that perform such a static allocation must guarantee that they do not try to use the statically allocated item while it is already queued.

More Information

To debug a system that has stopped responding with the error that is mentioned in "Symptoms", follow these steps:
  1. Assuming that you installed a driver that is named, for example, Xyz.sys, the system stops responding and you receive the stop error 0xA that is mentioned earlier.
  2. Start the debugger with the correct symbols, and then follow the debugging example that is described later in this article.

    This example uses kernel debugger. You can use either KD or WinDbg. You can also use this method by enabling the driver verifier.
  3. The kv command in the debugger shows the stack. The following stack trace indicates that WORKER_QUEUE has been corrupted.
    Stack Trace:
    f8979768 804f076c fc502008 ff651fb8 e16de008 nt!KiActivateWaiterQueue+0x27
    f8979790 f8462061 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x198
    f89797ac f8462289 ff651fb8 00000600 ff651fb8 Fastfat!FatWaitSync+0x18
    f897989c f8461e62 ff651fb8 fc502008 e16de008 Fastfat!FatNonCachedIo+0x36b
    f8979a2c f845b6b0 ff651fb8 fc502008 fc502008 Fastfat!FatCommonWrite+0xf29
    f8979a70 804eca36 82378020 fc502008 823d1698 Fastfat!FatFsdWrite+0xaa
    f8979a80 f847f3b8 804f46ad f377404c f8979ab8 nt!IopfCallDriver+0x31
    f8979a90 804eca36 82379a08 e27dac88 f8979aec sr!SrWrite+0xa8
    f8979ad8 804f46ad f376a0a6 823cafb8 82035ca8 nt!IopfCallDriver+0x31
    f8979adc f376a0a6 823cafb8 82035ca8 80570400 nt!IoSetThreadHardErrorMode
  4. If you review the stack in step 3, you might think that Fast Fat is the faulty driver. However, the KQUEUE structure shows a corrupted LIST_ENTRY:
    kd> dv
    Queue = ffffffff8054eddc
    kd> dt -r1 _KQUEUE 8054eddc
    +0x000 Header :
    +0x000 Type : 0x4 ''
    +0x001 Absolute : 0 ''
    +0x002 Size : 0xa ''
    +0x003 Inserted : 0 ''
    +0x004 SignalState : 1
    +0x008 WaitListHead : _LIST_ENTRY [ 0x823cb438 - 0x823ca6b0 ]
    +0x010 EntryListHead : [ 0x0 - 0x820ae3c8 ]
    +0x000 Flink : (null)
    +0x004 Blink : 0x820ae3c8 [ 0x0 - 0x8054edec ]
  5. Dereferencing the BLINK structure, it points to a WORK_QUEUE_ITEM (here, it is actually the first parameter in an IO_WORKITEM).

    Note The structure definition for IO_WORKITEM is available by using the symbols server for Windows XP and later versions. The structure is the same in earlier versions of Windows, although symbols are not available.
    kd> dt -r1 _IO_WORKITEM 820ae3c8
    +0x000 WorkItem :
    +0x000 List : _LIST_ENTRY [ 0x0 - 0x8054edec ]
    +0x008 WorkerRoutine : 0x8057fb78 nt!IopProcessWorkItem+0
    +0x00c Parameter : 0x820ae3c8
    +0x010 Routine : 0xf289dff0 +0
    +0x014 DeviceObject : 0xfe01b110
    +0x000 Type : 0
    +0x002 Size : 0
    +0x004 ReferenceCount : 0
    +0x008 DriverObject : (null)
    +0x00c NextDevice : (null)
    +0x010 AttachedDevice : 0x1fde0970
    +0x014 CurrentIrp : (null)
    +0x018 Timer : (null)
    +0x01c Flags : 0
    +0x020 Characteristics : 0x490049
    +0x024 Vpb : 0x000c0105
    +0x028 DeviceExtension : 0x0001ffff
    +0x02c DeviceType : 0x86a24
    +0x030 StackSize : 8 ''
    +0x034 Queue : __unnamed
    +0x05c AlignmentRequirement : 0x7fffffff
    +0x060 DeviceQueue : _KDEVICE_QUEUE
    +0x074 Dpc : _KDPC
    +0x094 ActiveThreadCount : 0
    +0x098 SecurityDescriptor : (null)
    +0x09c DeviceLock : _KEVENT
    +0x0ac SectorSize : 0
    +0x0ae Spare1 : 0
    +0x0b0 DeviceObjectExtension : (null)
    +0x0b4 Reserved : (null)
    +0x018 Context : 0x81f4a14c
    Note The contents of the device object do not show that it is a valid device object. However, the Context field is valid, and the !pool command shows a pooltag of Culprit Pool Tag.
  6. To determine whether the Routine address is valid, use the ln command on the pool address. If you have symbols, the result of using the ln command on the pool address should correspond to an address in the culprit driver. Therefore, an educated guess is that the IO_WORKITEM corresponds to some device that is made by the driver of the pool tag.
  7. In the following code, the work queue contains a single item. Therefore, dereferencing the BLINK was an easy way to find it. Because the work queue can contain multiple items, you must dereference the BLINK of each work item until you find the work item whose BLINK points back to KQUEUE.
    kd> !pool 81f4a14c
    Pool page 81f4a14c region is Nonpaged pool
    *81f4a140 size: 2b8 previous size: 8 (Allocated) *Culprit Pool Tag


To prevent the system from halting with this Stop error, turn off and then replace the faulty device driver that was found through the debugging session.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
314063 Troubleshooting a Stop Error 0xA in Windows XP

For more information and documentation from the Windows DDK, visit the following MSDN Web sites:

문서 ID: 818501 - 마지막 검토: 2012. 1. 30. - 수정: 1