Çö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
Recep Baltaş
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
---------
Tarihe göre sırala Puana göre sırala
1- Bu rehbere göre eksik/bozuk SYS dosyalarını onar.
2- Bu rehbere göre DDU ile ekran kartı sürücünü kaldır ve WHQL (beta sürümü olmayan, stabil çalışan) bir sürücü kur.
3- Bu videoya göre Memtest86 ile belleklerini test et ve sonuçlarını burada paylaş.
4- CPU-Z, HWiNFO ve Riot Vanguard'ı kaldır.
 
Artı 0 Eksi
KITT dedi:
1- Bu rehbere göre eksik/bozuk SYS dosyalarını onar.
2- Bu rehbere göre DDU ile ekran kartı sürücünü kaldır ve WHQL (beta sürümü olmayan, stabil çalışan) bir sürücü kur.
3- Bu videoya göre Memtest86 ile belleklerini test et ve sonuçlarını burada paylaş.
4- CPU-Z, HWiNFO ve Riot Vanguard'ı kaldır.
Genişletmek için tıkla...

RAM testini tamamladım. 12 GB RAM'ler ile 3.5 saat sürdü.
Dosyayı okudunuz mu bu arada?
 
Son düzenleyen: Moderatör:
Artı 0 Eksi
Kolpa Ayhan dedi:
Ram testini tamamladım. 3.5 Saat sürdü.
Dosyayı okudunuz mu bu arada ?
Genişletmek için tıkla...
Evet, dosyayı okumadan CPU-Z, HWiNFO ve Vanguard kullandığını nasıl bileyim?

Memtest86 testini bitirdiğini söylemişsin, sonuçlarını paylaş. Tüm dediklerimi yaptıktan sonra ek olarak @Trieetz'in dediği C:\Windows\Temp klasörünü de temizle.
 
Artı 0 Eksi
KITT dedi:
Evet, dosyayı okumadan CPU-Z, HWiNFO ve Vanguard kullandığını nasıl bileyim?

Memtest86 testini bitirdiğini söylemişsin, sonuçlarını paylaş. Tüm dediklerimi yaptıktan sonra ek olarak @Trieetz'in dediği C:\Windows\Temp klasörünü de temizle.
Genişletmek için tıkla...

Sonuçları kaydetmedim fakat Recep Baltaş'ın hazırladığı Video'nun izinden gittim ve hata bulamamıştı program RAM'lerde.
 
Son düzenleyen: Moderatör:
Artı 0 Eksi
KITT dedi:
Tamamdır. Belirttiklerimi uyguladıktan sonra tek bir iletide yazarsın her şeyi. Art arda yazınca bildirim gelmiyor yoksa.
Genişletmek için tıkla...

Birşey sorucam. HWiNFO ne bilmiyorum ama Vanguard ( Valorant'ı açmadığım sürece ) ve CPU-Z arka planda çalışmıyorlar bunların nasıl bir yan etkisi olabilir ki?
Yani uzun zamandır kullanmadığım 2 program. Arka Planda'ki işlemlerini kapatmıştım manuel olarak da.
Bir de Ekran Kartı sürücülerinden değildir diye umuyorum. En son sürücü yüklü şu an da beta değil ve resmi sitesinden indirdim. 8 Ay önce de aynı sorunu çekiyordum eski sürücü ile.
Ek düzenleme: Dosya onarımını da 2 gün önce yapmıştım.
 
Son düzenleyen: Moderatör:
Artı 0 Eksi
Kolpa Ayhan dedi:
Birşey sorucam. HWİNFO ne bilmiyorum ama Vanguard ( Valorant'ı açmadığım sürece ) ve CPU-Z arka planda çalışmıyorlar bunların nasıl bi yan etkisi olabilir ki?
Yani uzun zamandır kullanmadığım 2 program. Arka Planda'ki işlemlerini kapatmıştım manuel olarakta.
Birde Ekran Kartı sürücülerinden değildir diye umuyorum. En son sürücü yüklü şuan da beta değil ve resmi sitesinden indirdim. 8 Ay öncede aynı sorunu çekiyordum eski sürücü ile.
Genişletmek için tıkla...
HWiNFO'nun ne olduğunu ben de bilmiyordum. Sistem bilgisi veren bir yazılımmış.

Vanguard bilgisayarın açılırken çalışacak şekilde programlanır. CPU-Z'yi kullanmadığım için çalışma şeklini bilmiyorum, yorum yapamayacağım. Yine de bu dosyalarla ilişkili SYS dosyaları yüklenmemiş ve mavi ekrana sebep olmuş olabilir ki gönderdiğin loglar da bunları işaret ediyor. En azından hata düzelene kadar bunları kaldır. Hatan düzelip mavi ekran almadığın zaman bunları tekrar yükleyebilirsin.

Loglardan incelediğimiz kadarıyla bazen kesin olarak bazen yüksek ihtimalle şundan şundandır diyebiliyoruz. Logları inceledim ve ekran kartı sürücünün mavi ekrana sebebiyet verebileceği ihtimalinde bir çıkarımda bulundum, bu nedenle DDU ile ekran kartı sürücünü kaldırıp tekrardan kurmanı istiyorum. Dediklerimizi harfiyen uygula ki çözüme daha da yaklaşabilelim. Çözüme kavuşmanı istiyoruz.

Şimdi, Memtest86 ile test yaptığını ve bir hata olmadığını söylüyorsun. Aşağıdaki adımları uygula.
KITT dedi:
1- Bu rehbere göre eksik/bozuk SYS dosyalarını onar.
2- Bu rehbere göre DDU ile ekran kartı sürücünü kaldır ve WHQL (beta sürümü olmayan, stabil çalışan) bir sürücü kur.
4- CPU-Z, HWiNFO ve Riot Vanguard'ı kaldır.
Genişletmek için tıkla...
Trieetz dedi:
C:\Windows\Temp klasörünü temizleyin.
Genişletmek için tıkla...
 
Artı 0 Eksi
KITT dedi:
HWiNFO'nun ne olduğunu ben de bilmiyordum. Sistem bilgisi veren bir yazılımmış.

Vanguard bilgisayarın açılırken çalışacak şekilde programlanır. CPU-Z'yi kullanmadığım için çalışma şeklini bilmiyorum, yorum yapamayacağım. Yine de bu dosyalarla ilişkili SYS dosyaları yüklenmemiş ve mavi ekrana sebep olmuş olabilir ki gönderdiğin loglar da bunları işaret ediyor. En azından hata düzelene kadar bunları kaldır. Hatan düzelip mavi ekran almadığın zaman bunları tekrar yükleyebilirsin.

Loglardan incelediğimiz kadarıyla bazen kesin olarak bazen yüksek ihtimalle şundan şundandır diyebiliyoruz. Logları inceledim ve ekran kartı sürücünün mavi ekrana sebebiyet verebileceği ihtimalinde bir çıkarımda bulundum, bu nedenle DDU ile ekran kartı sürücünü kaldırıp tekrardan kurmanı istiyorum. Dediklerimizi harfiyen uygula ki çözüme daha da yaklaşabilelim. Çözüme kavuşmanı istiyoruz.

Şimdi, Memtest86 ile test yaptığını ve bir hata olmadığını söylüyorsun. Aşağıdaki adımları uygula.
Genişletmek için tıkla...
Vanguard'ı manuel olarak durdurdum. Oyuna çift tıkladıgımda bilgisayarı yeniden başlatarak Vanguardı çalıştırmak istiyor ancak o şekilde açılıyor. CPU-Z'de şüphelenebileceğimiz en son şey olsun bundan masum program yoktur. :)
Dosya onarmayı şuan tekrardan yapıyorum. Bunun hakkında paylaşmamı istediğiniz birşey var mı?
 
Artı 0 Eksi

Benzer konular

T
  • Soru
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea) mavi ekran hatası
2 3
Mesaj
27
Görüntüleme
1B
tpex8
T
mehmet.cengiz16
  • Soru
"THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)" mavi ekran hatası
Mesaj
3
Görüntüleme
646
mehmet.cengiz16
mehmet.cengiz16
KadirDincerr
  • Soru
100000ea mavi ekran sorunu
Mesaj
0
Görüntüleme
2B
KadirDincerr
KadirDincerr
I
  • Soru
THREAD_STUCK_IN_DEVICE_DRIVER_M mavi ekran
2 3
Mesaj
22
Görüntüleme
1B
Recep Baltaş
Recep Baltaş
D
  • Soru
THREAD_STUCK_IN_DEVICE_DRIVER_M mavi ekran hatası
2
Mesaj
11
Görüntüleme
802
283156
2

Yeni konular

Yeni mesajlar

Geri
Yukarı