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

bicy dedi:

Maalesef. Emin olmadığım için sansürlemiştim zaten ve üzerinden uzunca bir süre geçmesine rağmen herhangi bir hataya zorlamadı beni. Çok güvenli bir yol değil System32 içine erişim sağlamak için.

Bu sırada basit bir wdf tabanlı sürücü yazıp açıkçası birkaç hataya zorladım ve aldığın hatanın bir benzerini aldım. Kodlamada ne tür bir hatanın bu tür bir soruna sebep olabileceğini anlamak içindi ve üzerinden 2-3 denemeden fazla da durmadım açıkçası. Yazdığım kod sshid gibi bir sürücü için yazılan koddan çok daha düşük seviye bir koddu çünkü. Yine de durumu az buz anlamış sayılırım.

Rich (BB code):

1: kd> !wdflogdump bicy.sys
Trace searchpath is:

Trace format prefix is: %7!u!: %!FUNC! -
Trying to extract TMF information from - C:\ProgramData\dbg\sym\Wdf01000.pdb\066683F62DF745C1C6CD389F00F53E281\Wdf01000.pdb
Gather log: Please wait, this may take a moment (reading 4024 bytes).
% read so far ... 10, 20, 30, 40, 50, 100.
There are 39 log entries.
--- start of log ---
1: FxIFRStart - FxIFR logging started.
[.....]
37: FxVerifierCheckIrqlLevel - FxVerifierCheckIrqlLevel - Called at wrong IRQL; at level 2, should be at level 0
---- end of log ----

Tabii bu çok incelikli bir kod değil. Basit olarak kontrol mekanizmasına sahip olmayan bir hatada IRQL hatasını yakalayabildim.

Handlequerybusrelations fonksiyonunu özellikle kullandım çünkü bir PnP aygıtı ile ilgili en olasılıklı cevabı bu şekilde alabilirdim. Kısacası; bu fonksiyon çağrıldığında, IRQL seviyesinin 0'dan daha yüksek olduğu bir durumda exallocatepoolwithtag fonksiyonu ile sayfalanabilen belleğe (pagedpool) erişmeye çalıştım. Lakin bu durum, yalnızca IRQL = 0 seviyesinde yapılabilecek bir işlem olduğu için verifier bunu tespit edip senin aldığın hatanın aynısını verdi. Tabii ki bir IRQL kontrol mekanizması bile olmayan basit bir koddan ibaretti. Nihayetinde bu kontrol sağlanınca sorun çözülüyordu.

Sshıd gibi bir sürücü bu kontrolden daha nitelikli bir hataya sahip olmalı ki verifier çalışmıyorken bile sistemi çökertiyor... IRQL yükseltme, IRQL düşürme ya da belleğe erişim. Açıkçası bus ile her şeye bunlar sebep olabilir ve sürücü kapalı kaynakken bunu tespit etmem imkansız. Ek olarak senin hatan da hangi fonksiyonda çöküyor da bu hatayı yaratıyor ondan bile emin değiliz, fonksiyon o an kaç aygıtla ilişkide, kaç kere çağrılıyor ya da çağrılmadan önce fxverifier hangi kontrolleri yapıyor bilmiyoruz çünkü buna sahip bir dump dosyası sahibi de hiç olmadık. Özetle:

Sürücünün tüm dosyaları silinip baştan yüklendi. / çözülmedi.
Sürücüyü kullanan aygıt çıkartıldı. / çözüldü.

Belki de sorun klavye değil de sürücü derken ben hatalıydım. Bunu bilemem ama göründüğü kadarıyla zaten hem format attın hem sürücüyü sildin yükledin ama tek olumlu sonucu klavye takılı değilken aldın. SteelSeries ile iletişime geçip bir sürücü desteği de almadığın sürece bir Windows geliştiricisi olmadığımız için sana hangi PnP aygıtının hangi ırq kullanımını değiştirmeyi buradan anlatamayacağımdan da dolayı klavyeni değiştirmek isteyebilirsin.

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

bicy dedi:

Sistem yedeği alırsan System32 içindeki sshid dosyalarını silebileceğin bir kod yazıp .bat halinde sana sağlayabilirim. Dosyayı kullanmadan önce klavyeyi çıkarmalı ve öncesinde olduğu gibi Aygıt Yöneticisi'nden kendisini kaldırmalısın. Konunun öncesine baktığımda System32 içindeki dosyaları silmediğini fark ettim. Bu da elimizde kalan tek deneme yolu.

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

bicy dedi:

Takıldığın şey doğru değil. Hata bir süre zarfında tekrarlamıyor, aksine hatanın sebebini bulduğumuz gün ya da son 3 günden zaten bir süre beklediğini görmüyoruz. Tam bilmediğimiz için muhtemelen hataya sebep olan kodu yanlış seviyede çağırdığında ya da yüksek bir seviyede stuck'landığında ya da yanlış bir seviyede bir bellek aralığı açtığında hata oluyor. Bu da bir süre zarfını beklemiyor, stacklenme durumundan kastın ne bilmiyorum ama muhtemelen anladığın şey değil o. Normal bir şekilde oluyor yani. 5 gün de oldu 10 gün de oldu 15 gün de oldu 3 ay da oldu. Yani oluyor.

Yüzde bilmiyorum. Olası büyük bir ihtimal olduğunu sanmıyorum ama yedek her zaman alınabilir. Sildiğin sürücü sistemin işleyişini etkilemeyecek sonuçta. Dümdüz gibi System32 içinde sshid ile ilgili her şeyi kendin de silebilirsin. Yaptığımız şey tüm sürücü dosyalarını silip baştan sisteme kurmak. PnP bir fonksiyon hataya sebep oluyorsa bus fonksiyonu gibi, direkt olarak sürücü hatası değil klavyenin kendi hatasından da olabiliyor. Bu da tahminden ibaret sadece. Görmedim.

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