Windows'ta IRQL (Kesinti İstek Düzeyi) nedir ve BSOD'larla nasıl ilişkilidir?

Eğer daha önce şu tür mesajlar içeren mavi bir ekran gördüyseniz: irql_not_less_or_equal o DRIVER_IRQL_NOT_LESS_OR_EQUAL, muhtemelen sürücüler dünyasının dışında pek bilinmeyen bir kavramla karşılaşmışsınızdır: IRQL (Kesinti İstek Seviyesi). Windows, bu seviyedeki kesme önceliği, sistem belirli bir eşik değerinin üzerinde olduğunda iş parçacığı önceliğine göre öncelik kazanır ve bunun kararlılık üzerinde doğrudan sonuçları olur.

Sonraki satırlarda bulacaksınız bir tam rehber ve IRQL'nin ne olduğu, nasıl çalıştığı hakkında İspanya'dan İspanyolca, mavi ekranların neden tetiklendiğini, WinDbg ile ilgili sorunun nasıl teşhis edileceğini ve hatayı yaşayan bir kullanıcı veya çekirdek modu sürücüleri geliştiren biriyseniz ne yapmanız gerektiğini açıklıyoruz. İşe koyulalım.

Windows'ta IRQL (Kesinti İstek Düzeyi) Nedir?

Windows'ta, IRQL, önceliği tanımlar donanım bir işlemcinin çalıştığı yer Windows Sürücü Modeli (WDM) kapsamında, düşük bir IRQL'de çalışan kod, daha yüksek bir IRQL'de çalışan kod tarafından kesintiye uğrayabilir. Hatta, çok çekirdekli tek bir bilgisayarda, her CPU farklı bir IRQL'de olabilir ve bu da senkronizasyonu zorlaştırır.

Bir temel kural var: Bir CPU, PASSIVE_LEVEL'in üstünde bir IRQL'de çalışıyorsa, yalnızca daha yüksek bir IRQL'deki etkinlik tarafından önceden engellenebilir.Bu, kullanıcı kodu, çekirdek işlevleri, ertelenmiş çağrıcılar (DPC'ler) ve aygıt kesinti hizmeti rutinleri (ISR'ler) arasındaki birlikteliği düzenler.

Seviyeler ve öncelikler: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL ve DIRQL

Genel anlamda, x86'da 0 ile 31 arasında IRQL değerleri kullanılır; x64'te ise 0 ile 15 arasındaPratik anlamı aynıdır: IRQL 0 (PASSIVE_LEVEL), normal kullanıcı kodunun ve birçok sürücü fonksiyonunun yürütüldüğü yerdir; APC ve sayfa hataları Bunlar genellikle IRQL 1'e (APC_LEVEL) eşlenir; IRQL 2 (DISPATCH_LEVEL), iş parçacığı zamanlayıcısını ve DPC'leri kapsar. DISPATCH_LEVEL'in üzerindeki seviyeler, aygıt kesintileri (DIRQL olarak bilinir) ve HIGH_LEVEL gibi diğer dahili kullanımlar için ayrılmıştır.

Sürücü ekosisteminde, Birçok yaygın rutin DISPATCH_LEVEL seviyesinde çalışır: örneğin, DPC ve StartIo. Bu tasarım, bunlardan biri dahili kuyruklara veya diğer paylaşılan kaynaklara dokunurken, aynı seviyedeki başka bir rutinin o CPU'da kesintiye neden olmamasını sağlar, çünkü kesinti kuralı yalnızca daha yüksek seviyelerdeki kesintilere izin verir.

DISPATCH_LEVEL ile profilleme/yüksek seviyeler arasında yer var her cihazın donanım kesintileri (DIRQL)Bir aygıtın IRQL'si, diğer aygıtlara göre önceliğini tanımlar. Bir WDM sürücüsü, bu IRQL'yi IRP_MJ_PNP sırasında IRP_MN_START_DEVICE ile elde eder. Bu aygıt IRQL'si genel ve sabit bir değer değil, belirli bir kesme hattıyla ilişkili bir değerdir.

IRQL ve İş Parçacığı Önceliği

Kavramları birbirine karıştırmamak gerekir: İş parçacığı önceliği, zamanlayıcının ne zaman önceden müdahale edeceğini ve hangi iş parçacığının yürütüleceğini belirler; IRQL, hangi tür etkinliklerin yürütülebileceğini ve hangi kesmelerin maskeleneceğini kontrol eder. DISPATCH_LEVEL seviyesinin üzerinde, iş parçacığı değiştirme yoktur: kontrol eden iş parçacığı önceliği değil, IRQL'dir.

IRQL ve Sayfalama: Yapmamanız Gerekenler

IRQL'yi yükseltmenin doğrudan bir etkisi, sistemin sayfa hatalarını işleyemiyorAltın kural: DISPATCH_LEVEL seviyesinde veya üzerinde çalışan kod sayfa hatalarına neden olamaz. Pratikte bu, söz konusu rutinlerin ve dokundukları verilerin sayfalanmamış bellekte bulunmalıdırEk olarak, belirli çekirdek yardımcıları kullanımlarını IRQL'ye göre kısıtlar: örneğin, KeWaitForSingleObject DISPATCH_LEVEL yalnızca bloklama yapmıyorsanız (sıfır zaman aşımı) çağrılabilir ve sıfır olmayan zaman aşımları için DISPATCH_LEVEL değerinin altında olmanız gerekir.

IRQL'nin örtük ve açık kontrolü

Çoğu zaman, sistem, rutinlerinizi doğru IRQL'de çağırır ne yapmaları gerektiği için. IRP'ler için gönderme rutinleri PASSIVE_LEVEL'de çalışır (herhangi bir yardımcıyı engelleyebilir veya çağırabilirler), StartIo ve DPC paylaşılan kuyrukları korumak için DISPATCH_LEVEL'de çalışır ve ISR'ler DIRQL'de çalışır.

Açıkça kontrol etmeniz gerekiyorsa, IRQL'yi şu şekilde yükseltebilir veya düşürebilirsiniz: KeRaiseIrql y KeLowerIrqlÇok kullanılan bir kısayol var: KeRaiseIrqlToDpcLevel() önceki IRQL'i döndürür ve sizi DISPATCH_LEVEL'de bırakır. Önemli: IRQL'i asla sistem sizi çağırdığındaki değerin altına düşürmeyin; bu senkronizasyonu bozmak çok ciddi yarış pencereleri açabilir.

IRQL ile ilgili mavi ekran hataları: IRQL_NOT_LESS_OR_EQUAL ve DRIVER_IRQL_NOT_LESS_OR_EQUAL

Bu sorunlarla ilişkili iki klasik hata denetimi şunlardır: IRQL_DEĞİL_AZ_VEYA_EŞİT (0xA) y SÜRÜCÜ_IRQL_DAHA_AZ_VEYA_EŞİT_DEĞİL (0xD1)Her ikisi de, çok yüksek bir IRQL'de sayfalanabilir (veya geçersiz) bir adrese erişim girişimini gösterir. Bu durum genellikle sürücülerin yanlış adresler kullanmasından, hatalı işaretçilere başvurmamasından veya sayfalanabilir kodu uygunsuz düzeylerde çalıştırmasından kaynaklanır.

Özel durumda DRIVER_IRQL_DEĞİL_AZ_VEYA_EŞİT (0x000000D1)Parametreler oldukça bilgilendiricidir: 1) başvurulan bellek adresi; 2) o andaki IRQL; 3) erişim türü (0 okuma, 1 yazma, 2/8 yürütme); 4) belleğe başvuran talimatın adresi. Hata ayıklayıcıyla şunları kullanabilirsiniz: ln 4. parametre için en yakın sembolü listeleyin ve hangi işlevin çalıştığını bilin.

Akılda tutulması gereken yaygın nedenler

Belirli kodun ötesinde tekrarlanan kalıplar vardır. DISPATCH_LEVEL veya daha yüksek bir değere sahip geçersiz bir işaretçinin başvurusunun kaldırılması Bu, felakete giden kesin bir reçetedir. Bu düzeyde sayfalanabilir verilere erişmek veya sayfalanabilir kodu (örneğin, sayfalanabilir olarak işaretlenmiş bir işlevi) çalıştırmak da hata denetimini tetikler.

Diğer yaygın durumlar şunlardır: önceden indirilmiş başka bir sürücüdeki bir fonksiyonu çağırın (sarkan fonksiyon işaretçisi) veya geçersiz bir fonksiyon işaretçisi aracılığıyla dolaylı olarak çağrılabilir. Genellikle, sistem bir modülü tanımlayabiliyorsa, adını mavi ekranda görürsünüz ve ayrıca şuraya kaydedilir: KiBugCheckDriver, erişilebilir dx KiBugCheckDriver WinDbg'den.

Pratik bir detay: Çoğu D1/A'da gerçek sorun IRQL'nin kendisi değildir, daha ziyade referans alınan bellek adresidir. Bu nedenle 1, 3 ve 4 numaralı parametreler tanıya odaklanmak için çok önemlidir.

WinDbg ile Tanılama: Faydalı komutlar ve parametre okuma

Bu vakalar üzerinde çalışmak için, WinDbg anahtar araçtırve eğer BSOD bahsederse ntoskrnl.exe Bu bilgiler, hatanın çekirdek alt sisteminde olup olmadığı konusunda çok sayıda rehberlik sağlar. !analyze -v Hata denetiminin, yığının ve şanslıysanız ilgili modülün özetini almak için. Döküm bir yakalama çerçevesi içeriyorsa, .trap sizi başarısız CPU'nun bağlamına yerleştirir.

Jardines de Viveros komutlar yığın olarak k, kb, kc, kd, kp, kP, kv Size farklı düzeylerde geri izleme ayrıntılarını gösterirler. ln 4. parametrede atlayabilirsiniz hafızaya atıfta bulunan talimata ve yakındaki sembolü alın. Ve kesintiden önce çalışan öncelik seviyesinden şüpheleniyorsanız, !irql hedef işlemci için kaydedilmiş IRQL'i gösterir (örn. DISPATCH_LEVEL).

Parametre 1'in yönünü analiz etmek için, !pool Sayfalanmış bir havuza ait olup olmadığını size söyleyecektir; !address y !pte o bölgenin hafıza haritasını araştırın. Kullanabilirsiniz bellek görüntüleme komutları Erişilmeye çalışılan içeriği incelemek için. Son olarak, u, ub, uu 4. parametrenin adresi etrafında parçalama yapmanıza izin verir.

Unutma lm t n yüklenen modülleri listelemek için y !memusage genel hafıza durumu için. Eğer KiBugCheckDriver bir şeye sahip, dx KiBugCheckDriver Unicode modülünün adını döndürecektir: Tipik bir örnekte, hata kontrolü sırasında ilgili sürücü olarak “Wdf01000.sys” görülmüştür.

Sistem Araçları: Sürücü Doğrulayıcı, Olay Görüntüleyici ve Tanılama

El Sürücü Doğrulayıcı Sürücülerin davranışını gerçek zamanlı olarak inceler ve hatalı kaynak kullanımı (havuz gibi) tespit ettiğinde hata oluşmasını zorlar ve kodun sorunlu alanını izole etmek için bir istisna oluşturur. verifier itibaren komut istemi ve çok fazla yük eklemekten kaçınmak için mümkün olan en küçük sürücü setini seçmeniz önerilir.

Kendinizi WinDbg ile göremiyorsanız, temel önlemleri uygulamak: Olay Görüntüleyicisi'ndeki sistem günlüğünü belirli bir aygıt/sürücüye işaret eden hatalar açısından kontrol edin; mavi ekranda belirtilen sürücüyü güncelleyin veya devre dışı bırakın; donanımın Windows sürümünüzle uyumluluğunu doğrulayın; RAM'den şüpheleniyorsanız Windows Bellek Tanılama'yı kullanın. Bu eylemler basit olsa da, çok sayıda vakayı çözüyorlar.

Gerçek hayattan örnekler: BSOD'lar rastgele göründüğünde

Windows 10 Pro (AMD Ryzen 5 3400G CPU) kullanan bir kullanıcı GPU NVIDIA GeForce GTX 1660 Ti ve Gigabyte B450 AORUS PRO WIFI kartı, 16 GB RAM) aralıklı "IRQL_LESS_OR_NOT_EQUAL" ekranları yaşıyordum. Temel sürücüleri (ağ, grafik) zaten güncellemiştim, tüm Windows güncellemelerini yüklemiştim ve bellek aracını çalıştırmıştım, ancak hiçbir sorun tespit edemedim.

Bu gibi senaryolarda, Bir sonraki adım WinDbg ile dökümleri analiz etmektir ve kalıpları arayın: düştüğünde dahil olan süreçler (örneğin, explorer.exe), grafiksel arayüz modülleri (win32kfull.sys) ve şu gibi işlevler: xxxProcessNotifyWinEvent Yığında görünen. Bu modül Windows olsa da, tetikleyici genellikle uygunsuz bir IRQL'de bellek kullanan üçüncü taraf bir sürücüdür (grafik, giriş, katman, yakalama kartları) ve hata, win32k.

Buradaki pratik öneri şudur: geçici olarak kaplama yazılımını devre dışı bırak (yakalama, GPU OSD), agresif yazılım çevre birimi sürücüleri (makrolu fareler/klavyeler) ve grafik sürücülerinin beta sürümlerini kullanın ve bunları daraltın. Şüphelilerde Sürücü Doğrulayıcı'yı kullanmak, daha net bir yığınla sorunu daraltmanıza yardımcı olabilir.

Çok yaygın bir ağ modeli: ndis.sys her zaman suçlu değildir

Bir başka tipik durum: ndis.sys ile ekran görüntüsü (Windows ağ katmanı). Gerçek bir bilgisayarda, sistem başlangıçta hemen çökerdi. Pratik çözüm, Windows'u yeniden başlatmaktı. Güvenli mod ağ işlevleri olmadan, açın Aygıt Yöneticisi ve sorunu izole etmek için “Ağ Bağdaştırıcıları” altındaki bağdaştırıcıları devre dışı bırakın.

O takımda bir Realtek PCIe GBE Ailesi Denetleyicisi ve Atheros AR5007GHer ikisi de devre dışı bırakıldığında, gerçek nedenin athrx.sys (Atheros), mavi ekrandan bahsedilmesine rağmen ndis.sysÇöplük bunu doğruladı: yığın geçti ndis!NdisFreeTimerObject ama suçlu modül athrx.sysSon düzeltme şu şekildeydi: cihazı kaldırın ve güncellenmiş resmi sürücüleri yükleyin Atheros üreticisinin web sitesinden. Mantıksal sonuç: BSOD'de belirtilen modül, etkilenen alt sistemin bir parçası olabilir, sorunun kaynağı olmayabilir.

Kullanıcılar için tipik destek yanıtı ve hızlı adımlar

Gerçek bir destek alışverişinde bir teknisyen şu yanıtı verdi: "Verdiğimiz rahatsızlıktan dolayı özür dileriz. Sürücü, bellek veya antivirüs sorunu olabilir. Lütfen sürücülerinizi güncelleyin ve sorun devam ederse bellek tanılama programını çalıştırın."Bu temel ama geçerli bir tavsiyedir; ancak hatalar devam ederse, Verifier ve dump analizi ile daha ileri gitmek iyi bir fikirdir.

Teknik olmayan kullanıcılar için makul bir protokol şu şekilde olabilir: 1) Sistem olaylarını kontrol edin, 2) Temel sürücüleri güncelleyin (yonga seti/ağ/grafik), 3) RAM'i kontrol edin entegre araçla, 4) test çizme Çekirdeğe/GUI'ye kancalar yerleştiren üçüncü taraf yazılımlar olmadan temizleyin ve 5) hiçbir şey net değilse üçüncü taraf sürücülerde Doğrulayıcı'yı kullanın.

Sürücü geliştiricileri için en iyi uygulamalar

Eğer geliştirme aşamasındaysanız ve D1/A ile karşılaşırsanız, koşu rutini sayfalanabilir olarak işaretlenmemiş DISPATCH_LEVEL veya daha yüksek bir seviyede çalışırken sayfalanabilir işlevleri çağırmayın. Bu, sayfalanmış bölümlerdeki verilere referans vermekten kaçınmayı ve DDK'da açıklanan çekirdek yardımcıları için IRQL kısıtlamalarına uymayı içerir.

Paylaşılan verileri senkronize etmek için, "Paylaşılan verilere her zaman aynı yüksek IRQL'de eriş" kuralını uygulayın ve uygun olduğunda spin kilitlerini kullanın. Çoklu işlemcilerde, IRQL tek başına farklı CPU'lar arasında dışlamayı garanti etmez; spin kilitleri IRQL'yi (DISPATCH_LEVEL'e) yükseltir ve çekirdekler arasında erişimi koordine eder. Hassas donanım kayıtlarında işlem yapmanız gerekiyorsa, KeSynchronizeExecution kritik bölümleri doğru DIRQL'de yürütmenize yardımcı olur.

Plan IRQL'yi yükseltmeyi gerektirdiğinde, Amerika Birleşik Devletleri KeRaiseIrqlToDpcLevel DISPATCH_LEVEL için veya KeRaiseIrql dikkatli, önceki IRQL'i kaydedip tam olarak geri yükleyerek KeLowerIrql. Giriş IRQL'sinin altına inin, sadece bir an için bile olsa, Bu ciddi bir senkronizasyon hatasıdır.

Kesintiler ve donanımla ilişki

IRQL, Windows'un emirler öncelikleri ve belirli dahili görevleri kesintiye uğratırMimari düzeyde, "Kesme", "Kesme işleyicisi" veya "Kesme öncelik düzeyi" gibi kavramlarla ve klasik platformlarda, Programlanabilir Kesme Kontrol Cihazı (PIC)Diğer sistemlerde öncelik kontrolü, aşağıdaki gibi mekanizmalar aracılığıyla ifade edilir: spl en Unix; genel fikir aynıdır: Kim kimi rahatsız edebilir.

Gelişmiş Hata Ayıklama İpuçları

Yığının işaret ettiği çöplüklerde win32kfull!xxxProcessNotifyWinEvent 0xA/0xD1 hata denetimiyle, bağlamı inceleyin .process y .thread (eğer varsa), şu süreçlere bakın: explorer.exe en !process 0 1 ve katmanları ve GUI etkileşim sürücülerini kontrol edin. Çoğu zaman sorun Bu yolda ortaya çıkan şey, üçüncü bir tarafça bozulmuş bir hafızadır..

IRQL'i kontrol etmeyi unutmayın !irqlve karşıtlık: DISPATCH_LEVEL (2) seviyesindeyseniz ve parametre 3 okuma/yazma/yürütme olarak gösteriliyorsa Sayfalanabilir bir sayfada, neden düştüğüne dair zaten bir ipucunuz var. Bu ipucunu çaprazlayın ln Belirli fonksiyonu elde etmek için parametre 4'e girin.

iyi anlamak IRQL nedir? ve çekirdek yürütmesine nasıl uyduğu, gürültüyü sinyallerden ayırmaya yardımcı olur. Eğer bir kullanıcıysanız, şuna odaklanın: sürücüler ve donanım (Varsayılan olarak Doğrulayıcı, olaylar ve testlerle). Geliştirme yapıyorsanız, IRQL, sayfalanmamış bellek ve spin kilitleriyle senkronizasyon kurallarına kesinlikle uyun. Doğru araçlar (WinDbg, Doğrulayıcı) ve parametrelerin (1, 3 ve 4) dikkatlice okunmasıyla, Bu hata kontrolleri artık bir sır değil. ve bunlar metodik olarak ele alınabilecek sorunlara dönüşüyor.