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: ffffb0063559e040, 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 checksum for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 6031
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: 77048
Key : Analysis.Memory.CommitPeak.Mb
Value: 88
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: ffffb0063559e040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffb0063559e040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff589`aad94fe8 fffff807`8065263d : 00000000`000000ea ffffb006`3559e040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff589`aad94ff0 fffff807`8065271e : fffff589`aad950d0 fffff807`8062709b fffff589`aad950d0 fffff807`891fce00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff589`aad95060 fffff807`89158ff0 : 00000000`6eeccbc5 fffff807`891fce00 00000000`00000000 ffffb006`3233c000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff589`aad950a0 00000000`6eeccbc5 : fffff807`891fce00 00000000`00000000 ffffb006`3233c000 00000000`00989680 : atikmdag+0x68ff0
fffff589`aad950a8 fffff807`891fce00 : 00000000`00000000 ffffb006`3233c000 00000000`00989680 00000000`00000001 : 0x6eeccbc5
fffff589`aad950b0 00000000`00000000 : ffffb006`3233c000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x10ce00
STACK_COMMAND: .thread 0xffffb0063559e040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.329
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: ffffb90f2de62040, 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 checksum for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 7483
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: 83298
Key : Analysis.Memory.CommitPeak.Mb
Value: 89
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: ffffb90f2de62040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffb90f2de62040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffff8c82`a1bb0fc8 fffff804`1f64263d : 00000000`000000ea ffffb90f`2de62040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff8c82`a1bb0fd0 fffff804`1f64271e : ffff8c82`a1bb10b0 fffff804`1f61709b ffff8c82`a1bb10b0 fffff804`68d7ce00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff8c82`a1bb1040 fffff804`68cd8ff0 : 00000000`6a51501d fffff804`68d7ce00 00000000`00000000 ffffb90f`2f7d7000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff8c82`a1bb1080 00000000`6a51501d : fffff804`68d7ce00 00000000`00000000 ffffb90f`2f7d7000 00000000`00989680 : atikmdag+0x68ff0
ffff8c82`a1bb1088 fffff804`68d7ce00 : 00000000`00000000 ffffb90f`2f7d7000 00000000`00989680 00000000`00000001 : 0x6a51501d
ffff8c82`a1bb1090 00000000`00000000 : ffffb90f`2f7d7000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x10ce00
STACK_COMMAND: .thread 0xffffb90f2de62040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.329
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: ffff8582db3d00c0, 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 checksum for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 5733
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: 76820
Key : Analysis.Memory.CommitPeak.Mb
Value: 88
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: ffff8582db3d00c0
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffff8582db3d00c0
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffff9783`b520bfc8 fffff806`80cd263d : 00000000`000000ea ffff8582`db3d00c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff9783`b520bfd0 fffff806`80cd271e : ffff9783`b520c0b0 fffff806`80ca709b ffff9783`b520c0b0 fffff806`ca3dce00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff9783`b520c040 fffff806`ca338ff0 : 0000003e`a16953d1 fffff806`ca3dce00 00000000`00000000 ffff8582`d9d3c000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff9783`b520c080 0000003e`a16953d1 : fffff806`ca3dce00 00000000`00000000 ffff8582`d9d3c000 00000000`00989680 : atikmdag+0x68ff0
ffff9783`b520c088 fffff806`ca3dce00 : 00000000`00000000 ffff8582`d9d3c000 00000000`00989680 00000000`00000001 : 0x0000003e`a16953d1
ffff9783`b520c090 00000000`00000000 : ffff8582`d9d3c000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x10ce00
STACK_COMMAND: .thread 0xffff8582db3d00c0 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.329
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: ffff9285ccdec040, 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 checksum for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 5202
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: 31315
Key : Analysis.Memory.CommitPeak.Mb
Value: 87
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: ffff9285ccdec040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffff9285ccdec040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
fffff600`31dc3c38 fffff804`881b263d : 00000000`000000ea ffff9285`ccdec040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff600`31dc3c40 fffff804`881b271e : fffff600`31dc3d20 fffff804`8818709b fffff600`31dc3d20 fffff804`d18f25bc : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff600`31dc3cb0 fffff804`d17bd8e0 : 00000000`c1e57991 fffff804`d18f25bc 00000000`00000000 ffff9285`db281000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff600`31dc3cf0 00000000`c1e57991 : fffff804`d18f25bc 00000000`00000000 ffff9285`db281000 00000000`00989680 : amdkmdag+0x6d8e0
fffff600`31dc3cf8 fffff804`d18f25bc : 00000000`00000000 ffff9285`db281000 00000000`00989680 00000000`00000001 : 0xc1e57991
fffff600`31dc3d00 00000000`00000000 : ffff9285`db281000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1a25bc
STACK_COMMAND: .thread 0xffff9285ccdec040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.329
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: ffffe28a09e64040, 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 checksum for win32k.sys
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 6108
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: 82043
Key : Analysis.Memory.CommitPeak.Mb
Value: 88
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: ffffe28a09e64040
BUGCHECK_P2: 0
BUGCHECK_P3: 0
BUGCHECK_P4: 0
FAULTING_THREAD: ffffe28a09e64040
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_TEXT:
ffff9c81`1ff0ffc8 fffff802`14cf263d : 00000000`000000ea ffffe28a`09e64040 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff9c81`1ff0ffd0 fffff802`14cf271e : ffff9c81`1ff100b0 fffff802`14cc709b ffff9c81`1ff100b0 fffff802`5e18ce00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff9c81`1ff10040 fffff802`5e0e8ff0 : 00000002`48b4711f fffff802`5e18ce00 00000000`00000000 ffffe28a`0984d000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff9c81`1ff10080 00000002`48b4711f : fffff802`5e18ce00 00000000`00000000 ffffe28a`0984d000 00000000`00989680 : atikmdag+0x68ff0
ffff9c81`1ff10088 fffff802`5e18ce00 : 00000000`00000000 ffffe28a`0984d000 00000000`00989680 00000000`00000001 : 0x00000002`48b4711f
ffff9c81`1ff10090 00000000`00000000 : ffffe28a`0984d000 00000000`00989680 00000000`00000001 00000000`00000028 : atikmdag+0x10ce00
STACK_COMMAND: .thread 0xffffe28a09e64040 ; kb
SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
IMAGE_VERSION: 10.0.19041.329
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
---------
Söyle ki onlara sitelerinde ilk BIOS en azındna olması lazım neden yok deyin o zaman kafaları çalışır belki.
