Ryzen Pro 3400G THREAD_STUCK_IN_DEVICE_DRIVER_M Hatası

KojiroHyuga04 dedi:

Vega 11 sistemi çökertiyor.
DDU ile sürücüsünü kaldırıp en güncel halini kurun lütfen.

Realtek Wi-Fi sürücüsünü güncelleyin.

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

https://www.amd.com/en/support/apu/amd-ryzen-pro-processors/amd-ryzen-5-pro-desktop-processors-radeon-vega-graphics/amd-1

Genişletmek için tıkla...

Recep Baltaş dedi:

GPU, sistem belleğini kullanıyor. Bellek frekansı da stabil değilse mavi ekran alabilirsin. BIOS sürümün aşırı eski. Güncellemen fayda edebilir bu soruna.

ASRock A320M-HDV R4.0

AMD AM4 Socket; 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 Ultra M.2 (PCIe Gen3 x4 & SATA3)<span style=color:red;>*</span>; 6 USB 3.2 Gen1 (2...

www.asrock.com

Kod:Panoya kopyala

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

Genişletmek için tıkla...

Recep Baltaş dedi:

BIOS güncellemek bedava. Ücretli bir yöntem lazımsa ekran kartı alabilirsin. Kesin çözüm.

Genişletmek için tıkla...