Çözüldü THREAD_STUCK_IN_DEVICE_DRIVER mavi ekran hatası

AhmetII · 27 Mart 2021

Mini Dump dosyası
AMD Ryzen 5 Pro 3400G İşlemci
AMD B450 Anakart
Adata DDR4 3200 8 GB Bellek
AMD Radeon(TM) Vega 11 Graphics (işlemci ekran kartı).

Bu konuyu bir arkadaşım adına açıyorum. Bilgisayarının verilerine baktığımda ısınma değeri pek yok, kararlılık testine soktuğumuzda işlemci en fazla 60 derece görmekte. Yardım ederseniz seviniriz.

Bora Dere · 27 Mart 2021

Dosyaların şifreli olduğunun farkındasınızdır umarım.

2021-03-27 20_40_51-THREAD_STUCK_IN_DEVICE_DRIVER mavi ekran hatası _ Technopat Sosyal.png

AhmetII · 27 Mart 2021

Bora Dere dedi:
Dosyaların şifreli olduğunun farkındasınızdır umarım.

Eki Görüntüle 943952

Kusura bakmayın yanlış dosyayı yüklemişim Mini Dump dosyası(Şifresiz)
Arkadaştan aldığım için şifreli olduğunu unutmuşum.

Bora Dere · 27 Mart 2021

Sorun ekran kartı (bu durumda dahili grafik birimi) kaynaklı görünüyor. Sürücüsünü DDU ile kaldırıp güncellemeyi deneyebilir.

Rehber: DDU ile Sürücü Kaldırma Rehberi

Display Driver Uninstaller (DDU), zamanla bilgisayara takılan farklı monitörler, üst üste güncellenen sürücüler ve Windows güncellemeleri sonrası biriken kayıt defteri ve sürücü dosyalarını silerek temiz bir sürücü kurulumunun yolunu açan kullanışlı bir araçtır. Adım adım sürücü temizliği...

www.technopat.net

Telefon ile USB tethering mi yapıyor? Öyleyse bir süre yapmayı bıraksın. AIDA64 ve ESET'i kaldırsın. BIOS güncel görünmüyor. Güncellemek için:

Önce bunu kursun.

https://download.asrock.com/Drivers/AMD/VGA/AMD_VGA(v20.45.36_WHQL).zip

Sonra buradan BIOS'u güncellesin.

ASRock B450M-HDV R4.0

Supports AMD AM4 Socket Ryzen™ 2000, 3000, 4000 G-Series, 5000 and 5000 G-Series Desktop Processors; 2 DIMMs, Supports DDR4 3200+(OC)<span style=color:red;>*</span>; 1 PCIe 3.0 x16, 1 PCIe 2.0 x1; Graphics Output : HDMI, DVI-D, D-Sub; 7.1 CH HD Audio (Realtek ALC887/897 Audio Codec); 4 SATA3, 1...

www.asrock.com

Kod:

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: ffffc186711985c0, 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: 6421

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 120217

    Key  : Analysis.Init.CPU.mSec
    Value: 890

    Key  : Analysis.Init.Elapsed.mSec
    Value: 17291

    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


BUGCHECK_CODE:  ea

BUGCHECK_P1: ffffc186711985c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffc186711985c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
ffff8784`96d4ee38 fffff801`5300337d     : 00000000`000000ea ffffc186`711985c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff8784`96d4ee40 fffff801`5300345e     : ffff8784`96d4ef20 fffff801`52fd73cb ffff8784`96d4ef20 fffff801`590ca764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff8784`96d4eeb0 fffff801`58f90c00     : 000003ce`8dfb826e fffff801`590ca764 00000000`00000000 ffffc186`720ce000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff8784`96d4eef0 000003ce`8dfb826e     : fffff801`590ca764 00000000`00000000 ffffc186`720ce000 00000000`00989680 : amdkmdag+0x70c00
ffff8784`96d4eef8 fffff801`590ca764     : 00000000`00000000 ffffc186`720ce000 00000000`00989680 00000000`00000001 : 0x000003ce`8dfb826e
ffff8784`96d4ef00 00000000`00000000     : ffffc186`720ce000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764


STACK_COMMAND:  .thread 0xffffc186711985c0 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.19041.867

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: ffffcc0e1900e5c0, 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: 5406

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 111803

    Key  : Analysis.Init.CPU.mSec
    Value: 890

    Key  : Analysis.Init.Elapsed.mSec
    Value: 14778

    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


BUGCHECK_CODE:  ea

BUGCHECK_P1: ffffcc0e1900e5c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffcc0e1900e5c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
fffff98c`a74f3e38 fffff807`1b1f337d     : 00000000`000000ea ffffcc0e`1900e5c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff98c`a74f3e40 fffff807`1b1f345e     : fffff98c`a74f3f20 fffff807`1b1c73cb fffff98c`a74f3f20 fffff807`2163a764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
fffff98c`a74f3eb0 fffff807`21500c00     : 000001a3`dcb50700 fffff807`2163a764 00000000`00000000 ffffcc0e`18940000 : dxgkrnl!TdrTimedOperationDelay+0xce
fffff98c`a74f3ef0 000001a3`dcb50700     : fffff807`2163a764 00000000`00000000 ffffcc0e`18940000 00000000`00989680 : amdkmdag+0x70c00
fffff98c`a74f3ef8 fffff807`2163a764     : 00000000`00000000 ffffcc0e`18940000 00000000`00989680 00000000`00000001 : 0x000001a3`dcb50700
fffff98c`a74f3f00 00000000`00000000     : ffffcc0e`18940000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764


STACK_COMMAND:  .thread 0xffffcc0e1900e5c0 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.19041.867

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: ffffe28fe160e5c0, 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: 5046

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 115811

    Key  : Analysis.Init.CPU.mSec
    Value: 937

    Key  : Analysis.Init.Elapsed.mSec
    Value: 11739

    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


BUGCHECK_CODE:  ea

BUGCHECK_P1: ffffe28fe160e5c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffe28fe160e5c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
ffff8b84`6a9bce38 fffff805`2af3337d     : 00000000`000000ea ffffe28f`e160e5c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff8b84`6a9bce40 fffff805`2af3345e     : ffff8b84`6a9bcf20 fffff805`2af073cb ffff8b84`6a9bcf20 fffff805`30c5a764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff8b84`6a9bceb0 fffff805`30b20c00     : 00000094`11430318 fffff805`30c5a764 00000000`00000000 ffffe28f`e0f11000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff8b84`6a9bcef0 00000094`11430318     : fffff805`30c5a764 00000000`00000000 ffffe28f`e0f11000 00000000`00989680 : amdkmdag+0x70c00
ffff8b84`6a9bcef8 fffff805`30c5a764     : 00000000`00000000 ffffe28f`e0f11000 00000000`00989680 00000000`00000001 : 0x00000094`11430318
ffff8b84`6a9bcf00 00000000`00000000     : ffffe28f`e0f11000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764


STACK_COMMAND:  .thread 0xffffe28fe160e5c0 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.19041.867

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: ffffa30bc5bba5c0, 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: 5984

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 110191

    Key  : Analysis.Init.CPU.mSec
    Value: 999

    Key  : Analysis.Init.Elapsed.mSec
    Value: 7785

    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


BUGCHECK_CODE:  ea

BUGCHECK_P1: ffffa30bc5bba5c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffffa30bc5bba5c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
ffff9589`35a05e38 fffff802`7d04337d     : 00000000`000000ea ffffa30b`c5bba5c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff9589`35a05e40 fffff802`7d04345e     : ffff9589`35a05f20 fffff802`7d0173cb ffff9589`35a05f20 fffff802`84f9a764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff9589`35a05eb0 fffff802`84e60c00     : 000003f5`e7fe7e7c fffff802`84f9a764 00000000`00000000 ffffa30b`c6ada000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff9589`35a05ef0 000003f5`e7fe7e7c     : fffff802`84f9a764 00000000`00000000 ffffa30b`c6ada000 00000000`00989680 : amdkmdag+0x70c00
ffff9589`35a05ef8 fffff802`84f9a764     : 00000000`00000000 ffffa30b`c6ada000 00000000`00989680 00000000`00000001 : 0x000003f5`e7fe7e7c
ffff9589`35a05f00 00000000`00000000     : ffffa30b`c6ada000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764


STACK_COMMAND:  .thread 0xffffa30bc5bba5c0 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.19041.867

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: ffff8e8f55db05c0, 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: 5999

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 108915

    Key  : Analysis.Init.CPU.mSec
    Value: 890

    Key  : Analysis.Init.Elapsed.mSec
    Value: 3479

    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


BUGCHECK_CODE:  ea

BUGCHECK_P1: ffff8e8f55db05c0

BUGCHECK_P2: 0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

FAULTING_THREAD:  ffff8e8f55db05c0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
ffff880c`10221918 fffff807`6904337d     : 00000000`000000ea ffff8e8f`55db05c0 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
ffff880c`10221920 fffff807`6904345e     : ffff880c`10221a00 fffff807`690173cb ffff880c`10221a00 fffff807`700aa764 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x45
ffff880c`10221990 fffff807`6ff70c00     : 00000005`474f62d6 fffff807`700aa764 00000000`00000000 ffff8e8f`56cea000 : dxgkrnl!TdrTimedOperationDelay+0xce
ffff880c`102219d0 00000005`474f62d6     : fffff807`700aa764 00000000`00000000 ffff8e8f`56cea000 00000000`00989680 : amdkmdag+0x70c00
ffff880c`102219d8 fffff807`700aa764     : 00000000`00000000 ffff8e8f`56cea000 00000000`00989680 00000000`00000001 : 0x00000005`474f62d6
ffff880c`102219e0 00000000`00000000     : ffff8e8f`56cea000 00000000`00989680 00000000`00000001 00000000`00000028 : amdkmdag+0x1aa764


STACK_COMMAND:  .thread 0xffff8e8f55db05c0 ; kb

SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+45

MODULE_NAME: dxgkrnl

IMAGE_NAME:  dxgkrnl.sys

IMAGE_VERSION:  10.0.19041.867

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
---------

AhmetII · 2 Nisan 2021

Teşekkür ederim, sorun çözüldü. BIOS güncellemesi şu anlık yapamadık ama DDU işe yaradı, sorunu çözdü. Tekrardan yardımlarınız için teşekkür ederim. Konu kilitlensin lütfen.

Çözüldü THREAD_STUCK_IN_DEVICE_DRIVER mavi ekran hatası

Ayrıntılı düzenleme

AhmetII

Hectopat

Bora Dere

Rehber: DDU ile Sürücü Kaldırma Rehberi

ASRock B450M-HDV R4.0

Bora Dere

Moderasyon Ekibi Üyesi

AhmetII

Hectopat

Bora Dere

Moderasyon Ekibi Üyesi

Rehber: DDU ile Sürücü Kaldırma Rehberi

ASRock B450M-HDV R4.0

AhmetII

Hectopat

Benzer konular

Bu konuyu görüntüleyen kullanıcılar

Technopat Haberler

Yeni konular

Yeni mesajlar

Gizliliğinize önem veriyoruz