THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
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.
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.
Arguments:
Arg1: ffffce0c54d7a0c0, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" BugCheck 0xEA was hit (see notes).
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for amdkmdag.sys
*** WARNING: Unable to verify timestamp for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 4264
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 71571
Key : Analysis.Init.CPU.mSec
Value: 858
Key : Analysis.Init.Elapsed.mSec
Value: 7370
Key : Analysis.Memory.CommitPeak.Mb
Value: 78
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
BUGCHECK_CODE: ea
BUGCHECK_P1: ffffce0c54d7a0c0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffce0c54d7a0c0
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffffed80`b6214738 fffff803`870e353d : 00000000`000000ea ffffce0c`54d7a0c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffffed80`b6214740 fffff803`870e361e : ffffed80`b6214820 fffff803`870b73bb ffffed80`b6214820 fffff803`8ce7a764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffffed80`b62147b0 fffff803`8cd40c00 : 00000007`44796efe fffff803`8ce7a764 00000000`00000000 ffffce0c`5477f000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffffed80`b62147f0 00000007`44796efe : fffff803`8ce7a764 00000000`00000000 ffffce0c`5477f000 00000000`00989680 : amdkmdag+0x70c00
ffffed80`b62147f8 fffff803`8ce7a764 : 00000000`00000000 ffffce0c`5477f000 00000000`00989680 00000000`00000001 : 0x00000007`44796efe
ffffed80`b6214800 00000000`00000000 : ffffce0c`5477f000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764
STACK_COMMAND: .thread 0xffffce0c54d7a0c0 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.928
FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}
Followup: MachineOwner
---------
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
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.
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.
Arguments:
Arg1: ffffe78cec7bf080, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" BugCheck 0xEA was hit (see notes).
Debugging Details:
------------------
*** WARNING: Unable to verify timestamp for amdkmdag.sys
*** WARNING: Unable to verify timestamp for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 3984
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 73970
Key : Analysis.Init.CPU.mSec
Value: 750
Key : Analysis.Init.Elapsed.mSec
Value: 7346
Key : Analysis.Memory.CommitPeak.Mb
Value: 78
Key : WER.OS.Branch
Value: vb_release
Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z
Key : WER.OS.Version
Value: 10.0.19041.1
BUGCHECK_CODE: ea
BUGCHECK_P1: ffffe78cec7bf080
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffe78cec7bf080
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffffaf88`90268738 fffff806`8ca7353d : 00000000`000000ea ffffe78c`ec7bf080 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffffaf88`90268740 fffff806`8ca7361e : ffffaf88`90268820 fffff806`8ca473bb ffffaf88`90268820 fffff806`9325a764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffffaf88`902687b0 fffff806`93120c00 : 00000008`4278a368 fffff806`9325a764 00000000`00000000 ffffe78c`ec764000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffffaf88`902687f0 00000008`4278a368 : fffff806`9325a764 00000000`00000000 ffffe78c`ec764000 00000000`00989680 : amdkmdag+0x70c00
ffffaf88`902687f8 fffff806`9325a764 : 00000000`00000000 ffffe78c`ec764000 00000000`00989680 00000000`00000001 : 0x00000008`4278a368
ffffaf88`90268800 00000000`00000000 : ffffe78c`ec764000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764
STACK_COMMAND: .thread 0xffffe78cec7bf080 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.928
FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {ea458ad2-d5ab-aa6c-7a11-54653c70dfb8}
Followup: MachineOwner
---------
www.technopat.net
