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: ffff8d86235f2100, 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 atikmdag.sys
*** WARNING: Unable to verify timestamp for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 4593
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-G25IS1E
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 63675
Key : Analysis.Memory.CommitPeak.Mb
Value: 83
Key : Analysis.System
Value: CreateObject
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
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: ea
BUGCHECK_P1: ffff8d86235f2100
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffff8d86235f2100
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff687`e1b17708 fffff807`6cfc285d : 00000000`000000ea ffff8d86`235f2100 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff687`e1b17710 fffff807`6cfc293e : fffff687`e1b177f8 fffff807`6cf9713b fffff687`e1b177f8 fffff687`e1b17821 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff687`e1b17780 fffff807`71631f0a : 00000003`1b1d56b6 fffff687`e1b17821 00000000`00000000 ffff8d86`22eb0000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff687`e1b177c0 00000003`1b1d56b6 : fffff687`e1b17821 00000000`00000000 ffff8d86`22eb0000 00000000`00000001 : atikmdag+0x71f0a
fffff687`e1b177c8 fffff687`e1b17821 : 00000000`00000000 ffff8d86`22eb0000 00000000`00000001 00000000`00989680 : 0x00000003`1b1d56b6
fffff687`e1b177d0 00000000`00000000 : ffff8d86`22eb0000 00000000`00000001 00000000`00989680 fffff687`00000000 : 0xfffff687`e1b17821
STACK_COMMAND: .thread 0xffff8d86235f2100 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.572
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: ffff810fc9ba2100, 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 win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 4483
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-G25IS1E
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 66955
Key : Analysis.Memory.CommitPeak.Mb
Value: 83
Key : Analysis.System
Value: CreateObject
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
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: ea
BUGCHECK_P1: ffff810fc9ba2100
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffff810fc9ba2100
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff883`3ef56708 fffff807`7260285d : 00000000`000000ea ffff810f`c9ba2100 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff883`3ef56710 fffff807`7260293e : fffff883`3ef567f0 fffff807`725d713b fffff883`3ef567f0 fffff807`778830dc : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff883`3ef56780 fffff807`7774dd10 : 00000000`6ee70269 fffff807`778830dc 00000000`00000000 ffff810f`c94ea000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff883`3ef567c0 00000000`6ee70269 : fffff807`778830dc 00000000`00000000 ffff810f`c94ea000 00000000`00989680 : amdkmdag+0x6dd10
fffff883`3ef567c8 fffff807`778830dc : 00000000`00000000 ffff810f`c94ea000 00000000`00989680 00000000`00000001 : 0x6ee70269
fffff883`3ef567d0 00000000`00000000 : ffff810f`c94ea000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a30dc
STACK_COMMAND: .thread 0xffff810fc9ba2100 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.572
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: ffff9e0e54dbc100, 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: 4030
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-G25IS1E
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 68251
Key : Analysis.Memory.CommitPeak.Mb
Value: 82
Key : Analysis.System
Value: CreateObject
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
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: ea
BUGCHECK_P1: ffff9e0e54dbc100
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffff9e0e54dbc100
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffff9d03`da406708 fffff807`71c7285d : 00000000`000000ea ffff9e0e`54dbc100 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff9d03`da406710 fffff807`71c7293e : ffff9d03`da4067f0 fffff807`71c4713b ffff9d03`da4067f0 fffff807`778730dc : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff9d03`da406780 fffff807`7773dd10 : 0000001b`f5c96068 fffff807`778730dc 00000000`00000000 ffff9e0e`54a65000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff9d03`da4067c0 0000001b`f5c96068 : fffff807`778730dc 00000000`00000000 ffff9e0e`54a65000 00000000`00989680 : amdkmdag+0x6dd10
ffff9d03`da4067c8 fffff807`778730dc : 00000000`00000000 ffff9e0e`54a65000 00000000`00989680 00000000`00000001 : 0x0000001b`f5c96068
ffff9d03`da4067d0 00000000`00000000 : ffff9e0e`54a65000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a30dc
STACK_COMMAND: .thread 0xffff9e0e54dbc100 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.572
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
---------