Çözüldü MULTIPLE_IRP_COMPLETE_REQUESTS (44) mavi ekran hatası

  • Konuyu başlatan Konuyu başlatan Mienaki
  • Başlangıç Tarihi Başlangıç Tarihi
  • Mesaj Mesaj 34
  • Görüntüleme Görüntüleme 1B
Bu konu çözüldü olarak işaretlenmiştir. Çözülmediğini düşünüyorsanız konuyu rapor edebilirsiniz.

Mienaki

Uzman
Katılım
26 Eylül 2024
Mesajlar
49
Beğeniler
6

Merhaba, iyi geceler. Tekrardan rahatsız ettim kusura bakmayınız.. Ayın 27'sinde hata almıştım en son 13 gün önce ve şu an tekrarladı. Minidump dosyasını paylaşmak istedim. Portların yerini değiştirip kullanıyordum ve hiçbir sorun yoktu ama birden takıldı tekrar "tııır" sesi ve siyah ekran ile reset atmak zorunda kaldım.
 
Son düzenleyen: Moderatör:
Çözüm
Rich (BB code):
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common BugCheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffff80000003, The exception code that was not handled
Arg2: fffff807dfe79470, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: fffff807dfe79470, Parameter 1 of the exception

Gördüğümüz gibi oldukça genel bir hata kontrolümüz var. Bunlar, kendileri için işleyici yazılmamış ya da yapılandırılmış istisna işleme kullanılarak yakalanamayan istisnaların atılmasından kaynaklanıyor. Örneğin, PageFault, try-catch deyimi ile ele alınamayan bir istisnadır.

İşlenmeyen istisna nedir?

Rich (BB code):
0: kd> !error 80000003
Error code: (HRESULT) 0x80000003 (2147483651) - Bir veya daha fazla bağımsız değişken geçersiz

İstisnaya sebep olan fonksiyon nedir?

Rich (BB code):
0: kd> ln fffff807dfe79470
Browse module
Set bu breakpoint

(fffff807`dfe79470)   nt!DbgBreakPoint   |  (fffff807`dfe79480)   nt!DbgUserBreakPoint
Exact matches:

Microsoft'un bunun hakkındaki belgelemesine bakarsak:


Bu neden sistemin mavi ekran verdiğini açıklıyor. Lakin ne yüzünden verdiğini açıklamıyor, Yığıtlara bakarak bunu çözebiliriz;


Rich (BB code):
0: kd> k
 # Child-SP RetAddr Call Site
00 fffff807`71b950c8 fffff807`dff2a112 nt!KeBugCheckEx
01 fffff807`71b950d0 fffff807`e003d172 nt!KiFatalExceptionHandler+0x22
02 fffff807`71b95110 fffff807`dfd52302 nt!RtlpExecuteHandlerForException+0x12
03 fffff807`71b95140 fffff807`dfd53469 nt!RtlDispatchException+0x2d2
04 fffff807`71b958a0 fffff807`e0033d92 nt!KiDispatchException+0xac9
05 fffff807`71b95fb0 fffff807`e0033d60 nt!KxExceptionDispatchOnExceptionStack+0x12
06 fffff807`71b84128 fffff807`e0047c3e nt!KiExceptionDispatchOnExceptionStackContinue
07 fffff807`71b84130 fffff807`e003fe9b nt!KiExceptionDispatch+0x13e
08 fffff807`71b84310 fffff807`dfe79471 nt!KiBreakpointTrap+0x35b < Çökme 
09 fffff807`71b844a8 fffff807`71532260 nt!DbgBreakPoint+0x1
0a (Inline Function) --------`-------- Wdf01000!Mx::MxDbgBreakPoint+0xc
0b fffff807`71b844b0 fffff807`714c6f0d Wdf01000!FxVerifierDbgBreakPoint+0x50
0c (Inline Function) --------`-------- Wdf01000!FxVerifierCheckIrqlLevel+0xc43 < Doğrulama kontrolü 
0d fffff807`71b844f0 fffff807`65932fab  Wdf01000!imp_WdfUsbTargetDeviceSendControlTransferSynchronously+0xf7d
0e fffff807`71b848c0 00000000`00000000 sshid+0x2fab

Verifier'in önemini şimdi anlamış olduk. Sorunun sebebini ilk çökmede verdi kendi dosyası olmasa bile. SteelSeries sürücüsü dediğim gibi, en başından beri. Bir USB aygıtına Senkranizasyon kontrolü yapılıyor ve burada bir breakpoint yakalıyor sistem/Verifier. Nerede çöktüğümüzü ve ayrıca önceden çağrılan sorunlu bir sürücüyü görebiliyoruz kırmızı ile. Yığına dikkat edersen Wdf01000!FxVerifierCheckIrqlLevel ve Wdf01000!FxVerifierDbgBreakPoint. Artık kesme noktasının neden çağrıldığını biliyoruz, FxVerifierCheckIrqlLevel işlevi tarafından bir hata ayıklayıcının içeri girmesini ve geliştiricinin sürücüsünün neden çöktüğünü görmesini sağlamak için kullanılıyor. SSHID, yanlış IRQL düzeyinde çağırılıyor bu da çökmeye direkt olarak sebep olması için yeterlidir çünkü IRQL 2 düzeyinde Kernel bir sürücünün herhangi bir işlevinin yaptığı bir yanlış sistemi çökertecek düzeyde olur.

Rich (BB code):
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

Sürücünün doğrulama kontrolünde başarısız olduğunu ve bu nedenle kesme noktasının çağrıldığını varsayabiliriz, ancak bunu !wdflogdump komutunu kullanarak kesin olarak doğrulayabilirdik ama,

Dosya da her zamanki gibi yetersiz:[

Rich (BB code):
0: kd> !wdflogdump sshid
ReadListEntry failed
Warning: It looks like you're using the WDF debugger extension on a WDM
         driver. Framework logs will not be available

Muhtemelen karşılaşacağımız hata bu olacaktı:

Rich (BB code):
38: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 00001BF908FB2F68 returning 3 devices in relations FFFF820D1551C5D0
39: FxVerifierCheckIrqlLevel - Called at wrong IRQL; at level 2, should be at level 0


Sshid, açıkça çökmeye sebep oluyor. SS klavye sürücüsünü kaldırmalısın. Aygıt yöneticisi üzerinde bulabiliyor olman lazım ilgili sürücüyü, HID olmadan SS Keyboard aygıtı olarak ekli olması lazım...

Rich (BB code):
0: kd> lmvmsshid
Browse full module list
start             end                 module name
fffff807`65930000 fffff807`6593d000   sshid    T (no symbols)           
    Loaded symbol image file: sshid.sys
    Image path: sshid.sys
    Image name: sshid.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Feb 24 06:09:08 2022 (6216F6D4) 
    CheckSum:         00018401
    ImageSize:        0000D000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
Belirttiğin Windows sürücüleri dışında başka Windows sürücüsünü işaretlemedim. Unknown sürücülerini de işaretlemedim ama onun dışında gördüğüm her şeyi seçtim; NVIDIA, Revo Uninstaller vb. her şeyi...

Verifier calışırken mavi ekran yedim şimdi. 4 saat aralıkla yaşadım şu an.


Verifier calışırken oluşan minidump dosyası.

Şu an ne yapmam gerekiyor? verifier'i kapatayım mı? Yoksa sık sık cökmeler normal mi? Endişelenmeli miyim?
 
Son düzenleyen: Moderatör:
Rich (BB code):
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common BugCheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffff80000003, The exception code that was not handled
Arg2: fffff807dfe79470, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: fffff807dfe79470, Parameter 1 of the exception

Gördüğümüz gibi oldukça genel bir hata kontrolümüz var. Bunlar, kendileri için işleyici yazılmamış ya da yapılandırılmış istisna işleme kullanılarak yakalanamayan istisnaların atılmasından kaynaklanıyor. Örneğin, PageFault, try-catch deyimi ile ele alınamayan bir istisnadır.

İşlenmeyen istisna nedir?

Rich (BB code):
0: kd> !error 80000003
Error code: (HRESULT) 0x80000003 (2147483651) - Bir veya daha fazla bağımsız değişken geçersiz

İstisnaya sebep olan fonksiyon nedir?

Rich (BB code):
0: kd> ln fffff807dfe79470
Browse module
Set bu breakpoint

(fffff807`dfe79470)   nt!DbgBreakPoint   |  (fffff807`dfe79480)   nt!DbgUserBreakPoint
Exact matches:

Microsoft'un bunun hakkındaki belgelemesine bakarsak:


Bu neden sistemin mavi ekran verdiğini açıklıyor. Lakin ne yüzünden verdiğini açıklamıyor, Yığıtlara bakarak bunu çözebiliriz;


Rich (BB code):
0: kd> k
 # Child-SP RetAddr Call Site
00 fffff807`71b950c8 fffff807`dff2a112 nt!KeBugCheckEx
01 fffff807`71b950d0 fffff807`e003d172 nt!KiFatalExceptionHandler+0x22
02 fffff807`71b95110 fffff807`dfd52302 nt!RtlpExecuteHandlerForException+0x12
03 fffff807`71b95140 fffff807`dfd53469 nt!RtlDispatchException+0x2d2
04 fffff807`71b958a0 fffff807`e0033d92 nt!KiDispatchException+0xac9
05 fffff807`71b95fb0 fffff807`e0033d60 nt!KxExceptionDispatchOnExceptionStack+0x12
06 fffff807`71b84128 fffff807`e0047c3e nt!KiExceptionDispatchOnExceptionStackContinue
07 fffff807`71b84130 fffff807`e003fe9b nt!KiExceptionDispatch+0x13e
08 fffff807`71b84310 fffff807`dfe79471 nt!KiBreakpointTrap+0x35b < Çökme 
09 fffff807`71b844a8 fffff807`71532260 nt!DbgBreakPoint+0x1
0a (Inline Function) --------`-------- Wdf01000!Mx::MxDbgBreakPoint+0xc
0b fffff807`71b844b0 fffff807`714c6f0d Wdf01000!FxVerifierDbgBreakPoint+0x50
0c (Inline Function) --------`-------- Wdf01000!FxVerifierCheckIrqlLevel+0xc43 < Doğrulama kontrolü 
0d fffff807`71b844f0 fffff807`65932fab  Wdf01000!imp_WdfUsbTargetDeviceSendControlTransferSynchronously+0xf7d
0e fffff807`71b848c0 00000000`00000000 sshid+0x2fab

Verifier'in önemini şimdi anlamış olduk. Sorunun sebebini ilk çökmede verdi kendi dosyası olmasa bile. SteelSeries sürücüsü dediğim gibi, en başından beri. Bir USB aygıtına Senkranizasyon kontrolü yapılıyor ve burada bir breakpoint yakalıyor sistem/Verifier. Nerede çöktüğümüzü ve ayrıca önceden çağrılan sorunlu bir sürücüyü görebiliyoruz kırmızı ile. Yığına dikkat edersen Wdf01000!FxVerifierCheckIrqlLevel ve Wdf01000!FxVerifierDbgBreakPoint. Artık kesme noktasının neden çağrıldığını biliyoruz, FxVerifierCheckIrqlLevel işlevi tarafından bir hata ayıklayıcının içeri girmesini ve geliştiricinin sürücüsünün neden çöktüğünü görmesini sağlamak için kullanılıyor. SSHID, yanlış IRQL düzeyinde çağırılıyor bu da çökmeye direkt olarak sebep olması için yeterlidir çünkü IRQL 2 düzeyinde Kernel bir sürücünün herhangi bir işlevinin yaptığı bir yanlış sistemi çökertecek düzeyde olur.

Rich (BB code):
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

Sürücünün doğrulama kontrolünde başarısız olduğunu ve bu nedenle kesme noktasının çağrıldığını varsayabiliriz, ancak bunu !wdflogdump komutunu kullanarak kesin olarak doğrulayabilirdik ama,

Dosya da her zamanki gibi yetersiz:[

Rich (BB code):
0: kd> !wdflogdump sshid
ReadListEntry failed
Warning: It looks like you're using the WDF debugger extension on a WDM
         driver. Framework logs will not be available

Muhtemelen karşılaşacağımız hata bu olacaktı:

Rich (BB code):
38: FxPkgPnp::HandleQueryBusRelations - WDFDEVICE 00001BF908FB2F68 returning 3 devices in relations FFFF820D1551C5D0
39: FxVerifierCheckIrqlLevel - Called at wrong IRQL; at level 2, should be at level 0


Sshid, açıkça çökmeye sebep oluyor. SS klavye sürücüsünü kaldırmalısın. Aygıt yöneticisi üzerinde bulabiliyor olman lazım ilgili sürücüyü, HID olmadan SS Keyboard aygıtı olarak ekli olması lazım...

Rich (BB code):
0: kd> lmvmsshid
Browse full module list
start             end                 module name
fffff807`65930000 fffff807`6593d000   sshid    T (no symbols)           
    Loaded symbol image file: sshid.sys
    Image path: sshid.sys
    Image name: sshid.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Feb 24 06:09:08 2022 (6216F6D4) 
    CheckSum:         00018401
    ImageSize:        0000D000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
 
Çözüm
SS uygulaması yüklü değil ve Denetim Masası ve Revo üzerinden görünmüyor. Hiç de yüklemedim fakat klavyeyi taktiğimda görmüş olup kendi kendine yüklemiş olabilir, emin değilim. Peki tamamen kaldırmanın başka bir yolu var mı Aygıt Yöneticisi'nden? Tek tek kontrol edip SteelSeries ile ilgili her şeyi sileyim mi? HID klavye dahil olmak üzere.

2. olarak sorun klavyeden cıkarsa nasıl düzelteceğiz? Yani klavyeyi bir daha kullanmayacak mıyım? Ya da nasıl bir yol izleyebiliriz tamir vs. gibi?

Verifier /reset komutunu kullandiğimda "no settings were changed." Hatasi veriyor.
 
Son düzenleyen: Moderatör:
Sistemi güvenli modda aç;

CMD'i yönetici olarak çalıştır > Verifier/ reset yaz ve enter'la.

------------------------------------------------------------------
  1. Verifier'i aç.
  2. "delete existing settings" seçeneğini seç.
  3. Sistemi yeniden başlat.
------------------------------------------------------------------

Verifier ayarları bu 2 kayıt defteri girdisinde tutulur. Bunları da silebilirsin.

Rich (BB code):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

3 seçenek de işe yaramazsa bildir. Detaylandırayım.
 

Direkt sistemi geri yükledim ve şu an yeni klavyeden yazıyorum, ne yapmam lazım? Şimdi eski klavyeyi hiç kullanamayacak mıyım eğer sorun ondan kaynaklıysa? İlana koyup satmalı mıyım? Ya da servise mi göndermeliyim? SS yüklü değil fakat SS var gibi görünüyor dediniz. Tüm geçmiş SS ile ilgili her şeyi nasıl kaldırabilirim? (denetim masasında görünmüyor uygulama olarak da.)
 
Son düzenleyen: Moderatör:
Aygıt Yöneticisi > Gizli aygıtlar altında SteelSeries klavye sürücünü görüyor olman lazım. Bu sürücüyü Aygıt Yöneticisi'nden kaldır ve muhtemelen sonrasında Windows bu sürücüyü tekrardan kurmak için bir Update çıkaracaktır.(Farklı bir SS aygıtı varsa.) Sorun klavye değil, Sorun sürücü. Windows'un bu kuracağı yeni sürücü işe yarayabilir. (Farklı bir aygıt yoksa kurmaz) Şu anlık farklı bir klavye ile dediğimi deneyin ki eğer sorun çıkmazsa eski klavyenizi geri takın diyebileyim. İlla görmek istiyorsan C:\Windows\System32 konumuna gidip sshid olarak arama yaparsan ilgili sürücüyü görürsün.
 
Aygıt Yöneticisi > gizli aygıtlar altında sistem aygıtlarından 2 tane ve insan arabirim aygıtlarından 3 tane, toplam 5 tane sildim.

SS uygulamasını yükleyip klavye ve fareyi artik takayım mı yoksa bir süre daha beklemeli miyim? Ya da direkt takıp kullanayım kendisi mi yüklesin? Yüklerse tabii.
 
Son düzenleme:
Hayır. Sistem ne sürede mavi ekran veriyorsa o süre zarfında bekle ve kontrol et. Eğer şimdi çıkarırsan hiçbir anlamı olmayacak.
Merhaba, şu anlık sorun yok. SteelSeries desteğe mesaj atmıştım ve bunları yazmış, senin bu konu hakkındaki düşüncelerin neler?





 
Son düzenleyen: Moderatör:
Merhaba, Sorunun çözüldüğüne sevindim. Bir süredir aktif değildim - malum sınavlar falan biraz yoğun oluyor. SS ekibinin istediği LOG'ları ben de isterdim ama uygulamayı hiç yüklemediğini bildiğim için istemedim. Elde edecekleri şeyler benim söylediğim şeylerin sebebini ortaya çıkarmayacaktı ama, ondan eminim. Klavyeni takıp sürücüyü tekrar yükleyerek sistemini kontrol edebilirsin. Eğer tekrar mavi ekran verirse 2 3 haftadır sisteme taktığım klavye ile kontrol ettiğim sshid sürücüsünü kendi System32 klasörümden sana atabilirim. Bu da çok makul bir hareket olmayacak. Benim takip ettiğim süreçte hiçbir sorun yaşamadım ve neden olduğunu da anlamış değilim.
 
Bu siteyi kullanmak için çerezler gereklidir. Siteyi kullanmaya devam etmek için çerezleri kabul etmelisiniz. Daha Fazlasını Öğren.…