Çözüldü THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea) mavi ekran

Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.
Çözüm
Konu 7 sayfa gereksiz uzamış. Ve 7 sayfa boyunca bir kişi bile sanırım ekran kartının marka/modelini sormamış sana. Ekran kartının markası ve modeli nedir?

Sorun ekran kartında çünkü. Kartın bozuk.

RX 570 imiş. RX serisinde sorun yaşamayan yok galiba. İyi ki bu kartla hiç sistem toplamadık bugüne kadar. Başkası toplasa sesini çıkarmayan güruh biz toplasak laf eder. Böyle de zombi bir kitle var 🤭 😅

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: 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
---------
O zaman bu dediklerimi bilgisayardan anlayan biri var ise tanıdık ona verin o yapsın. Başka çare yok çünkü. Deneme yanılma ile sorunu bulabiliriz.
 
O zaman bu dediklerimi bilgisayardan anlayan biri var ise tanıdık ona verin o yapsın. Başka çare yok çünkü. Deneme yanılma ile sorunu bulabiliriz.
Aygıt yöneticisinde, görüntü bağdaştırıcı kısmını açtığımda Radeon ve 4600 çıkıyor karşıma. Radeona tıkladığımda konum kısmının karşısında PCI veri yolu 1 yazıyor. 4600'e tıkladığımda ise aynı yerde 0 yazıyor. Belkide dediğiniz gibidir.
 
Dostum servise ver güzelce donanımsal sorun ise düzeltsinler. Dahili ekran kartı bozuk büyük ihimal bu da işlemcinin tehlikede olduğu anlamına geliyor. Sistemin garantisi var ise servise ver bu sorunu çözemezsin dostum göründüğü kadarıyla teknik bilgin fazla yok.
 
Dostum servise ver güzelce donanımsal sorun ise düzeltsinler. Dahili ekran kartı bozuk büyük ihimal bu da işlemcinin tehlikede olduğu anlamına geliyor. Sistemin garantisi var ise servise ver bu sorunu çözemezsin dostum göründüğü kadarıyla teknik bilgin fazla yok.
Garantisi yok ama az önce yine aldım mavi ekran.
 

1603123870712.png


  • Şu paketi kur küçük ihtimalde olsa göz önünde bulunduralım.

 

Eki Görüntüle 707540

  • Şu paketi kur küçük ihtimalde olsa göz önünde bulunduralım.

upload_2020_10_20_11_57_00_068.jpg
Hocam şu mavi kabloyuda içerden takmadigim için görüntü vermiyor olabilirmi?
Öyleyse nereye takmalıyım?
pic1603184267750.jpg
 

Yeni konular

Geri
Yukarı