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.
drive.google.com
