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: ffffb9897dbe7040, 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: 4531
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 79329
Key : Analysis.Init.CPU.mSec
Value: 905
Key : Analysis.Init.Elapsed.mSec
Value: 13403
Key : Analysis.Memory.CommitPeak.Mb
Value: 79
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
FILE_IN_CAB: 112021-16718-01.dmp
BUGCHECK_CODE: ea
BUGCHECK_P1: ffffb9897dbe7040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffb9897dbe7040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff186`20d4d268 fffff800`830d455d : 00000000`000000ea ffffb989`7dbe7040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff186`20d4d270 fffff800`830d463e : fffff186`20d4d350 fffff800`830a6d0b fffff186`20d4d350 fffff800`88291c90 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff186`20d4d2e0 fffff800`8815d100 : 00000004`ebd97fec fffff800`88291c90 00000000`00000000 ffffb989`8306f000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff186`20d4d320 00000004`ebd97fec : fffff800`88291c90 00000000`00000000 ffffb989`8306f000 00000000`00989680 : amdkmdag+0x6d100
fffff186`20d4d328 fffff800`88291c90 : 00000000`00000000 ffffb989`8306f000 00000000`00989680 00000000`00000001 : 0x00000004`ebd97fec
fffff186`20d4d330 00000000`00000000 : ffffb989`8306f000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a1c90
STACK_COMMAND: .thread 0xffffb9897dbe7040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.1288
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
---------
3: kd> !sysinfo machineid
Machine ID Information [From Smbios 3.2, DMIVersion 0, Size=1348]
BiosMajorRelease = 5
BiosMinorRelease = 14
BiosVendor = American Megatrends Inc.
BiosVersion = P4.00
BiosReleaseDate = 07/16/2020
SystemManufacturer = To Be Filled By O.E.M.
SystemProductName = To Be Filled By O.E.M.
SystemFamily = To Be Filled By O.E.M.
SystemVersion = To Be Filled By O.E.M.
SystemSKU = To Be Filled By O.E.M.
BaseBoardManufacturer = ASRock
BaseBoardProduct = A320M-HDV R4.0
BaseBoardVersion =
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: ffffe10b4980d040, 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: 6952
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 76080
Key : Analysis.Init.CPU.mSec
Value: 921
Key : Analysis.Init.Elapsed.mSec
Value: 13448
Key : Analysis.Memory.CommitPeak.Mb
Value: 89
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
FILE_IN_CAB: 112021-24031-01.dmp
BUGCHECK_CODE: ea
BUGCHECK_P1: ffffe10b4980d040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffe10b4980d040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff90b`2e43e268 fffff804`1675455d : 00000000`000000ea ffffe10b`4980d040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff90b`2e43e270 fffff804`1675463e : fffff90b`2e43e350 fffff804`16726d0b fffff90b`2e43e350 fffff804`1c931c90 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff90b`2e43e2e0 fffff804`1c7fd100 : 00000050`09f9acdd fffff804`1c931c90 00000000`00000000 ffffe10b`35c83000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff90b`2e43e320 00000050`09f9acdd : fffff804`1c931c90 00000000`00000000 ffffe10b`35c83000 00000000`00989680 : amdkmdag+0x6d100
fffff90b`2e43e328 fffff804`1c931c90 : 00000000`00000000 ffffe10b`35c83000 00000000`00989680 00000000`00000001 : 0x00000050`09f9acdd
fffff90b`2e43e330 00000000`00000000 : ffffe10b`35c83000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a1c90
STACK_COMMAND: .thread 0xffffe10b4980d040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.1288
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: ffffbb87a50ba040, 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: 4311
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 76354
Key : Analysis.Init.CPU.mSec
Value: 921
Key : Analysis.Init.Elapsed.mSec
Value: 13623
Key : Analysis.Memory.CommitPeak.Mb
Value: 90
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
FILE_IN_CAB: 111921-21125-01.dmp
BUGCHECK_CODE: ea
BUGCHECK_P1: ffffbb87a50ba040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffbb87a50ba040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffffe8c`b50f4268 fffff801`3769455d : 00000000`000000ea ffffbb87`a50ba040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffffe8c`b50f4270 fffff801`3769463e : fffffe8c`b50f4350 fffff801`37666d0b fffffe8c`b50f4350 fffff801`43a81c90 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffffe8c`b50f42e0 fffff801`4394d100 : 0000000c`7d4c85de fffff801`43a81c90 00000000`00000000 ffffbb87`adae8000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffffe8c`b50f4320 0000000c`7d4c85de : fffff801`43a81c90 00000000`00000000 ffffbb87`adae8000 00000000`00989680 : amdkmdag+0x6d100
fffffe8c`b50f4328 fffff801`43a81c90 : 00000000`00000000 ffffbb87`adae8000 00000000`00989680 00000000`00000001 : 0x0000000c`7d4c85de
fffffe8c`b50f4330 00000000`00000000 : ffffbb87`adae8000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a1c90
STACK_COMMAND: .thread 0xffffbb87a50ba040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.1288
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
---------