Windows'ta BSOD'ları ve çekirdek dökümlerini analiz etmeye yönelik eksiksiz kılavuz

Informatec Dijital » Ücretsiz Destekler » Windows'ta BSOD'ları ve çekirdek dökümlerini analiz etmeye yönelik eksiksiz kılavuz

Bir Windows bilgisayar mavi ekran hatasıyla donduğunda, bu sadece can sıkıcı değildir: genellikle ciddi sorunları vardır. Bellek dökümünde çok değerli bilgiler gizli. Bu bize çekirdekte tam olarak ne olduğunu gösteriyor. İlk sorun belirtisinde RAM'i, BIOS'u veya formatlamayı suçlamak yerine, bu verileri nasıl okuyacağınızı öğrenmekte fayda var.

Biraz pratikle, WinDbg gibi araçlar ve özellikler sayesinde, !analyze -v, .bugcheck veya sembollerin doğru kullanımı Bu sayede "Mavi ekran hatası alıyorum" durumundan "Mavi ekran hatasına hangi sürücünün, kaynağın veya aygıtın neden olduğunu biliyorum" durumuna geçebiliyoruz. Bu makalede, bir mavi ekran hatasını çekirdek dökümü kullanarak nasıl analiz edeceğimizi, hangi döküm türlerinin mevcut olduğunu, her şeyi nasıl hazırlayacağımızı ve analizden en iyi şekilde yararlanmak için hangi komutları kullanacağımızı adım adım ve oldukça ayrıntılı bir şekilde ele alacağız.

BSOD nedir ve hangi bilgileri içerir?

Windows bir durumla karşılaştığında Bu durum sistemin bütünlüğünü tehlikeye atıyor. ve güvenli bir şekilde kurtarılamazsa, dahili bir çekirdek çağrısı yapar. KeBugCheckExBu çağrı, ünlü mavi ekran hatasına (BSOD) neden olan şeydir.

KeBugCheckEx her zaman alır beş argüman: bir DURDURMA kodu (hata kontrol kodu) y dört ek parametre Bu veriler, arızaya teknik bir bağlam sağlar. Daha sonra bu verilere başvurabiliriz:

• Mavi ekranda Sistem otomatik olarak yeniden başlatılacak şekilde yapılandırılmamışsa, klasik durum geçerlidir.
• Windows olay günlüğündeOlay Görüntüleyicisi (sistem günlüğü) içinde.
• Bellek dökümü dosyasında (minidump, çekirdek dökümü veya tam döküm), WinDbg ve aşağıdaki komutlar kullanılarak !analyze -v o .bugcheck.

Her hata kontrol kodunun bir sembolik ad ve ilişkili onaltılık değerÖrneğin, hata denetimi DRIVER_POWER_STATE_FAILURE kodu var 0x9FSüre RESOURCE_NOT_OWNED karşılık gelir 0xE3Bu kodlar ve parametreleri, her zaman elinizin altında bulundurmanız gereken Microsoft hata denetleme kodları referansında belgelenmiştir.

Kodun yanı sıra, mavi ekran şunları da gösterebilir: Olayda adı geçen .sys sürücüsünün adıÜçüncü taraf bir sürücü (antivirüs, ağ kartı, ekran kartı vb.) söz konusuysa, genellikle net bir şüpheliye sahibiz. Eğer ortaya çıkan şey genel bir sistem bileşeni (ntoskrnl.exe, win32k.sys…) ise veya hiçbir şey görünmüyorsa, daha derinlemesine incelemek için bellek dökümü ve WinDbg kullanmamız gerekecek.

Windows'ta bellek dökümü türleri

Bir BSOD hatasını derinlemesine analiz edebilmek için Windows'un bir çıktı üretmesi gerekiyor. bellek dökümü dosyası (DMP) Arıza meydana geldiğinde, bu dosya hatanın oluştuğu anda sistemin durumunu kaydeder ve farklı türlerde olabilir.

"Başlangıç ​​ve Kurtarma" seçeneklerinde ("Bu Bilgisayar / Bilgisayarım"a sağ tıklayın → Özellikler → Gelişmiş sistem ayarları → "Gelişmiş" sekmesi → "Başlangıç ​​ve Kurtarma" altındaki "Ayarlar" düğmesi), çeşitli döküm türleri arasından seçim yapabilirsiniz. Her birinin avantajları ve dezavantajları vardır.

Küçük Bellek Dökümü (Minidump)

El minidump En küçük format (yaklaşık 64 KB) olup, gelişmiş hata ayıklama için de en sınırlı olanıdır. Bununla birlikte, yine de kullanışlıdır. hızlı bir teşhis alın birçok BSOD senaryosunda.

Bir minidump dosyası, diğer verilerin yanı sıra şunları saklar:

• Durdurma mesajı, hata kontrol kodu ve parametreleri.
• İşlemci bağlamı (PRCB) arızaya neden olan işlemcinin.
• Çekirdek işlem bilgileri (EPROSS), kaza anındaki aktif sürecin.
• Çekirdekteki iş parçacığı bilgileri Çökmenin meydana gelmesine neden olan iş parçacığının (ETHREAD) değeri.
• Çekirdek modu çağrı yığını Bu konu için (en fazla 16 KB).
• Yüklenen sürücülerin listesi Kararın verildiği sırada.
• Yüklenen ve indirilen modüllerin listesi.
• Bir hata ayıklama veri bloğu Temel sistem bilgileriyle birlikte.

Bu tür dökümler normalde şuraya kaydedilir: % SystemRoot% \ Mini döküm (örneğin, C: \ Windows \ MinidumpTemel destek veya teşhis işlemlerinin çoğu için, iyi analiz edilmiş bir minidump dosyası yeterlidir. !analiz et -v fazlasıyla yeterli olabilir.

Çekirdek Bellek Dökümü

El çekirdek bellek dökümü Bu, kullanıcı işlem belleği alanları hariç, çökme anındaki çekirdek belleği içeriğini içerir. Boyut ve ayrıntı arasında çok ilginç bir orta noktadır ve genellikle Çoğu BSOD tanısı için önerilen seçenek.

Bu döküm dosyası şu şekilde kaydedildi: MEMORY.DMP en % SystemRoot% (varsayılan, C: \ Windows \ MEMORY.DMPBoyutu, çekirdek tarafından kullanılan belleğe bağlıdır, ancak genellikle minidump'tan çok daha büyük ve tam dump'tan çok daha yönetilebilir bir boyuttadır.

Tam Bellek Dökümü

El tam bellek dökümü Pratik olarak tasarruf sağlıyor. RAM'in tüm içeriği Hata anında: çekirdek, kullanıcı süreçleri vb. En detaylı olanıdır, ancak aynı zamanda en çok yer kaplayan ve yapılandırma açısından en zorlayıcı olanıdır.

Eksiksiz bir veri dökümünün geçerli olabilmesi için çeşitli şartların yerine getirilmesi gerekir:

• El Disk belleği dosyası içinde olmalı Windows'un kurulu olduğu aynı bölüm.
• Olmalı Disk alanının en az fiziksel bellek boyutuna eşit olması gerekir. makinenin.
• Bozuk bellek dökümlerinden kaçınmak istiyorsanız, sanal bellek dosyasını başka bir fiziksel diske taşımayın.

Çok fazla RAM'e sahip üretim ortamlarında tam bir bellek dökümü almak pratik olmayabilir, ancak çok karmaşık veya aralıklı vakalar Sorunun yerini tespit etmede büyük fark yaratabilir.

Windows'u BSOD'ları yakalayacak ve kaydedecek şekilde yapılandırın.

WinDbg ile işe koyulmadan önce, sistemin şu özelliklere sahip olduğundan emin olmak çok önemlidir: Hata dökümlerini doğru şekilde oluşturuyor ve olayı kaydediyor. Mavi ekrandan.

"Başlatma ve Kurtarma" penceresinde birkaç ilgili seçenek buluyoruz:

• Sistem günlüğüne bir olay yazın.Hata denetiminin Olay Görüntüleyicisine kaydedilebilmesi için bu özelliğin etkinleştirilmesi gerekir.
• Hata ayıklama bilgilerini yazBurada Minidump, Çekirdek bellek dökümü veya Tam bellek dökümü seçeneklerinden birini tercih ediyoruz.
• döküm dosyası yolu: varsayılan %SystemRoot%\MEMORY.DMP çekirdek/tam için.
• Otomatik olarak yeniden başlat: İstersek işaretini kaldırmamız tavsiye edilir. Mavi ekrana sakince bakın. ve ekranda belirenleri not edin.

Bazı üreticiler veya destek departmanları, örneğin belirli ağ adaptörlerinde olduğu gibi, kullanıcıdan aşağıdaki bilgileri talep etmektedir: Döküm dosyasını gönderGenellikle şu şekildedir: C:\Windows\memory.dmp Son arızaya karşılık gelen kaydı belirlemek için tarih/saat bazında arama yapılması önerilir.

Eğer istediğimiz şey güç ise Sistem donmuş olsa bile zorla bellek dökümü işlemi gerçekleştirin. (Klavye veya fare yanıt vermediğinde), PS/2 klavyeler için (USB/Bluetooth olmayanlar için) çok kullanışlı bir yöntem daha vardır; bu yöntem, bir tuş kombinasyonuyla döküm işlemini tetikleyecek şekilde kayıt defterini yapılandırmaktan oluşur.

Donma durumunda klavyeyi kullanarak zorla bellek dökümü alın.

Ekran tamamen donmuş olsa bile bellek dökümü oluşturmak için şu seçeneği kullanabiliriz: CrashOnCtrlScroll Bu yöntem USB veya Bluetooth klavyeler için geçerli değildir.

Kayıt defterinde aşağıdaki anahtarı oluşturmalı veya değiştirmeliyiz:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Yeniden başlatmanın ardından, istediğimiz zaman (ekran donmuş olsa bile) şunları yapabileceğiz: kontrollü bir çarpışmaya neden olmak ve sistemin tuşa basılarak bellek dökümü oluşturduğu. Sağ CTRL ve sonra, Scroll Lock tuşuna iki kez basın.Mavi ekran hatası (BSOD) göstermeyen ani sistem çökmelerini araştırmak için çok kullanışlıdır.

Çekirdek dökümlerini analiz etmek için WinDbg'ye giriş

WinDbg, Microsoft'un en önemli araçlarından biridir. çekirdek hata ayıklama ve bellek dökümü analiziÜcretsiz olarak kullanılabilir (şu anda Microsoft Store'da WinDbg Preview olarak da mevcuttur) ve ilk bakışta karmaşık görünse de, ilk BSOD analizi için yalnızca birkaç temel seçeneği yönetmemiz gerekiyor.

WinDbg'yi etkilenen makineye veya başka bir makineye kurabiliriz. başka herhangi bir takım.dmp dosyası ağ üzerinden, USB aracılığıyla veya hatta CAB dosyasına sıkıştırılarak kopyalanabilir. Dökümü analiz etmek için kullanılan işlemci ve Windows sürümü, çöken makinenin işlemci ve Windows sürümleriyle aynı olmayabilir.

Komut satırından bir döküm dosyasıyla WinDbg'yi başlatın.

WinDbg'de bellek dökümü açmanın klasik bir yolu, komut satırını parametresiyle kullanmaktır. -z Döküm dosyasının yolunu belirtiyoruz. Bunu sembol veya ikili dosya yolu gibi diğer parametrelerle birleştirebiliriz:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

değiştirici -v etkinleştirmek detaylı mod (verbose)Bu da daha fazla bağlam görmek için çok faydalı. WinDbg'nin yanı sıra, şunlar da var: kd.exeKonsol tabanlı bir hata ayıklayıcı sürümü olan bu araç, neredeyse aynı şeyi yapmanıza olanak tanır ancak grafik arayüzü içermez:

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Grafik arayüzden bir döküm dosyası açın.

WinDbg'yi pasif modda zaten açmışsak, menüyü kullanarak bir döküm dosyasını yükleyebiliriz. Dosya → Kilitlenme Dökümünü Aç veya kısayol ile Ctrl + D.dmp dosyasını (hatta onu içeren bir .cab dosyasını bile) seçiyoruz ve WinDbg döküm bilgilerini yüklüyor.

Bir diğer alternatif ise WinDbg'yi başlatmak ve içeri girdikten sonra şu komutu çalıştırmaktır. .opendump Döküm dosyasının yolunu ve ardından komutu belirterek. g (Go) Hata ayıklama oturumunu başlatmak için:

.opendump C:\Windows\Memory.dmp
g

WinDbg hatta buna izin veriyor. birden fazla çöplüğü aynı anda temizlemekbirkaç parametre eklemek -z komut satırında veya tekrarlayarak .opendump Farklı rotalarla ve çoklu varış noktalı oturumu yöneterek.

WinDbg'de sembol yolunu yapılandırın.

Semboller olmadan WinDbg neredeyse körü körüne çalışıyor. Semboller (.pdb) şunları içerir: Fonksiyonlar, iç yapılar, değişkenler, ofsetler vb. hakkında hata ayıklama bilgileri.ve özellikle çekirdek (kernel) ile çalışırken güvenilir analiz için vazgeçilmezdirler.

Microsoft'un herkese açık sembollerini manuel olarak indirmek zorunda kalmadan kullanmanın en iyi yolu, bir yapılandırma yapmaktır. sembol sunucusu Resmi Microsoft sunucusuna ve yerel bir önbellek dizinine işaret ediyor. Örneğin, önceden bir klasör oluşturabiliriz. C:\semboller Ardından, WinDbg'de sembol yolunu aşağıdaki gibi yapılandırın:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Bu menüden yapılabilir Dosya → Sembol Dosya Yolu veya WinDbg Önizlemesinde, Dosya → Ayarlar → Hata ayıklama ayarları "Varsayılan sembol yolu"nu ayarlama. Belirli bir sistemden alınan bir dökümü ilk kez analiz ettiğimizde, hata ayıklayıcı Gerekli semboller otomatik olarak indirilecektir. İnternet üzerinden, bağlantı hızına bağlı olarak birkaç dakika sürebilir.

Microsoft'un kamuya açık sembollerinin bazı durumlarda şu hususa dikkat çekmek gerekir: Bunlar, tüm dahili tip bilgilerini içermez."Hata ayıklayıcınız doğru sembolleri kullanmıyor" gibi uyarılar veya çözümlenemeyen türlere yapılan atıflar göreceğiz. Temel BSOD analizi için genellikle public semboller yeterlidir, ancak daha fazla ayrıntıya ihtiyacımız olursa sınırlamalar olacaktır.

İlk analiz: temel komutlar ve hata kontrolü

Veri dökümü yüklendikten ve semboller yapılandırıldıktan sonra, WinDbg genellikle sistem bilgileri ve bir uyarı içeren bir başlık görüntüler. “Ayrıntılı hata ayıklama bilgileri almak için !analyze -v komutunu kullanın.”Bu, ön analiz için ilk durağımız.

Komut !analiz et -v Döküm dosyasının otomatik analizini gerçekleştirir ve genellikle şunları sağlar:

• Hata kontrol kodu (örneğin, 0xE3, 0xD1, 0x9F, 0x44…).
• Arg1, Arg2, Arg3 ve Arg4 parametreleri Hata kontrolünden.
• En muhtemel modül veya sürücü arızanın nedeni (Probably caused by).
• İlgili süreç o anda (örneğin, Teams.exe).
• Çağrı yığını (yığın izi) Çökme olayına neden olan iş parçacığının.
• Kova bilgileri ve tekrarlanan hataları ilişkilendirmek için kullanışlı olan hata özetleri.

Örneğin, gerçek dünyadaki bir hata kontrolü senaryosunda KAYNAK SAHİPLENİLMİYOR (0xE3)Analiz, bir tehdit girişiminin olabileceğini gösterebilir. Sahip olmadığı bir kaynağı serbest bırakmaksürecin nasıl işlediğini gösteriyor Takımlar.exe ve işaret ederek win32kbase.sys bir fonksiyonda DrvEnumDisplaySettingsBu bize, başarısız olan iş parçacığının, Windows grafik katmanı aracılığıyla kullanıcı alanından görüntü ayarlarını sorguladığı veya değiştirdiği yönünde bir ipucu veriyor.

Durdurma kodunun ve parametrelerinin ayrıntılarına biraz daha inmek için, elimizde şu komut da var: .bugcheckBu da hata kontrolünü ve dört argümanı tekrar gösterir; bu, her şeyi yeniden çalıştırmadan bu bilgiyi tekrarlamak istediğimizde faydalıdır. !analyze -v.

Pratik örnekler: Sürücüler ve tipik çatışmalar

BSOD analizi genellikle şunlar etrafında döner: Hatalı veya uygunsuz davranış sergileyen sürücüleri tespit etmekDenetleyiciler arasındaki çatışmalar, belleğe yetkisiz erişim, IRP'lerin (G/Ç İstek Paketleri) yanlış işlenmesi vb. Süreci daha iyi anlamak için gerçek vakalardan alınan bazı pratik örneklere bakalım.

RESOURCE_NOT_OWNED (0xE3) hatası, Teams ve win32kbase.sys ile ilişkilidir.

Windows 10'da, birkaç günlük kesintisiz çalışmanın ardından bir hata denetimiyle birlikte mavi ekran hatası (BSOD) ortaya çıkıyor. 0xE3 (KAYNAK SAHİPLENİLMEMİŞ)Minikernel çıktısı şöyle bir şey gösteriyor:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Burada hata ayıklayıcı, hata denetiminin şu iş parçacığı tarafından tetiklendiğini gösteriyor: Takımlar.exeAncak kritik anda yığında bulunan kod aslında şuna aittir: win32kbase.sysözellikle de fonksiyona DrvEnumDisplaySettingsBu, Teams'in doğrudan "suçlu" olduğu anlamına gelmez, daha ziyade Teams üzerinden bir kullanıcı API'si çağrılıyor. Bu durum, grafik alt sisteminde senkronizasyon hatasına veya kaynak serbest bırakılmasına yol açar.

Bu tür teşhislerde, varılan sonuç genellikle şudur: Windows grafik yığınında, belirli bir video sürücüsünde bir hata. veya uygulama ile sürücüler arasındaki etkileşimde. Gerçek çözüm şunları içerebilir: GPU sürücülerini güncelleyin, Teams'i güncelleyin veya belirli Windows yamalarını uygulayın."Kendiliğinden düzelmesini beklemekten" öte.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) NotMyFault ile

Yarar Benim hatam değil Sysinternals'ın aracı, ekran görüntülerini analiz etmeyi öğrenmek için kontrollü bir şekilde çekirdek hataları oluşturmanıza olanak tanıyan bir eğitim kaynağıdır. Örneğin, NotMyFault'tan seçeneği başlatırsak... Yüksek IRQL hatası (çekirdek modu) ve "Hata Oluştur" düğmesine bastığımızda, bir işlemi zorlayacağız. SÜRÜCÜ_IRQL_DAHA_AZ_VEYA_EŞİT_DEĞİL (0xD1).

Mavi ekranda buna benzer bir şey göreceğiz. DRIVER_IRQL_NOT_LESS_OR_EQUAL ve muhtemelen bir sürücü adayı (örneğin, MyFault.sys(Aracın kullandığı sürücü). Döküm dosyası oluşturulduktan ve WinDbg ile açıldıktan sonra, ilk çıktı şuna benzer görünebilir:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Hata ayıklayıcı işaret etse de bellek_bozulmasıGerçek nedenin NotMyFault ve sürücüsüyle ilgili olduğunu biliyoruz. Bunu doğrulamak için, aşağıdaki gibi komutlarla izlemeye devam edebiliriz. !iplik Hata oluştuğu sırada iş parçacığının hangi çağrıları yaptığını görmek için, !irp Hata denetiminin G/Ç işlemleriyle ilgili olup olmadığını analiz etmek için ilgili IRP'yi inceleyin.

Örneğin, !iplik İş parçacığının yığın izini görebilecek ve talimatın nerede göründüğünü tespit edebileceğiz. myfault+0x403Bu bize test sürücüsünün nerede hata yaptığını gösteriyor. Buradan yola çıkarak, gerçek bir hata durumunda olduğu gibi IRP'yi, bellek durumunu vb. inceleyebiliriz.

ÇOKLU_IRP_TAMAMLAMA_İSTEKLERİ (0x44) ve USB çakışmaları

Bir diğer çok açıklayıcı örnek ise hata denetimidir. ÇOKLU_IRP_TAMAMLAMA_İSTEKLERİ (0x44)Bu hata şu durumlarda oluşur: Bir IRP (G/Ç İstek Paketi) birden fazla kez tamamlanıyor.Genellikle iki farklı sürücünün aynı IRP'ye sahip olduklarına inanmaları ve ikisinin de arama yapması nedeniyle olur. IoCompleteRequest().

Analiz şu şekilde yapıldı: !analiz et -v Şuna benzer bir açıklama üretebilir:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

İlk bakışta şüpheli şu gibi görünüyor: Usbehci.sysUSB EHCI denetleyicileri için bir Microsoft sürücüsü. Ancak, hatanın herhangi bir üçüncü taraf etkileşimi olmadan yerel bir Windows sürücüsünden kaynaklanması nispeten nadirdir. Konuya gelecek olursak, hata denetimi tarafından bize verilen IRP adresini (Arg1) kullanıyoruz ve başlatıyoruz. !irp:

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

Son satırda zinciri açıkça görüyoruz. Sürücü\usbehci ax88172Bu da IRP'nin çok şey atlattığını ortaya koyuyor. Usbehci.sys Örneğin, bir sürücü tarafından ax88172.sysBu durum, belirli bir USB ağ yonga setiyle (AX88172) ilişkilidir. Bu nedenle, çakışmanın buradan kaynaklandığı sonucuna varabiliriz. üçüncü taraf USB NIC sürücüsüBu, genel Microsoft EHCI sürücüsü değil.

Bu durumda çözüm şudur: USB adaptör sürücüsünü güncelleyin, cihazı değiştirin veya başka seçeneğiniz yoksa cihazı kaldırın.IRP kullanan bu tür analizler, özellikle USB, depolama, ağ kartları ve genel olarak yoğun G/Ç kullanan herhangi bir bileşenle ilgili BSOD'larda oldukça faydalıdır.

Çekirdek modunda kullanışlı WinDbg komutları

ötesinde !analiz et -v y .bugcheckÇekirdek dökümü incelemesine biraz daha derinlemesine girmek istediğimizde çok faydalı olan çeşitli WinDbg uzantıları ve komutları bulunmaktadır.

En yaygın olanlarından bazıları şunlardır:

• !iplik: Bir iş parçacığı hakkında çağrı yığını, durumu, ilişkili IRP'leri vb. dahil olmak üzere ayrıntılı bilgiler görüntüler. Sistem çöktüğünde çalışan iş parçacığının "son eylemlerini" görmenizi sağlar.
• !işlem 0 0Bu, çökme anında aktif olan tüm işlemleri listeler. Makinede şüpheli işlemlerin, hizmetlerin, EDR'nin, antivirüsün vb. çalışıp çalışmadığını belirlemek için faydalıdır.
• !irp: belirli bir IRP'yi analiz eder ve gösterir geçtiği sürücülerin iziGiriş/çıkış komutları, bayraklar vb., ilgili hataların tespitinde kilit öneme sahiptir. MULTIPLE_IRP_COMPLETE_REQUESTS ve diğer G/Ç hataları.
• !işlemci bilgisiİşlemci hakkında bilgi sağlar (üretici, MHz, imzalar, özellikler), donanım ortamlarının doğrulanması için faydalıdır.
• !pebPEB (İşlem Ortamı Bloğu) ile ilgili bilgisayar adı, Windows kurulum yolu, işlemci sayısı vb. ayrıntıları görüntüler.
• !token: İşlem veya iş parçacığının güvenlik belirteçleri, izinleri ve güvenlik bağlamı hakkında bilgi sağlar.
• .clsKomut penceresini, normal bir konsolda olduğu gibi temizler.

Ayrıca, birçok özel uzantı (örneğin, dosya sistemleri için PnP, NTFS, vb.) dökümlerden daha fazla bilgi çıkarılmasına olanak tanır. Bazı durumlarda, WinDbg şunların varlığını gösterecektir: KARA KUTU* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), sistemin belirli alanlarının teşhisini kolaylaştırmak için hata denetimi sırasında yakalanan ek veri bloklarıdır.

Sürücü Doğrulayıcıyı kullanarak sorunlu sürücüleri bulma

Windows Mavi Ekran Hatası (BSOD) vakalarının çok büyük bir kısmı şu nedenlerden kaynaklanmaktadır: arızalı veya kötü programlanmış sürücülerBu tür sorunları önceden tespit etmek için sistem çok güçlü bir araç içeriyor: Sürücü Doğrulayıcı.

El Sürücü Doğrulayıcı Gerçek zamanlı olarak çalışır ve seçilen sürücüleri bir dizi test ve stres testine tabi tutar: doğruluğunu kontrol eder. Belleğin, çekirdek havuzlarının, IRQL'nin, IRP'nin vb. doğru kullanımı.Sürücünün yanlış bir şey yaptığını tespit ederse, şunları yapabilir: kontrollü bir BSOD'ye zorlamak Böylece, suçlunun genellikle çok açık bir şekilde tespit edildiği, çok daha net bir atık dökümünü analiz edebiliriz.

Sürücü Doğrulama yöneticisini başlatmak için, yönetici ayrıcalıklarıyla bir komut istemi açın ve şunu yazın:

verifier

Buradan hangi kontrolörlerin doğrulanmasını istediğimizi seçebiliriz. Dikkatli olmakta fayda var: Doğrulayıcı Sisteme ek yük getirir ve performansı düşürebilir.Bu nedenle, doğrulamayı yalnızca aşağıdaki durumlar için etkinleştirmeniz önerilir: şüpheli sürücülerin minimum sayısı her şeyi neşeyle işaretlemek yerine.

Doğrulayıcı hatalı davranışı tespit ettiğinde bir BSOD (Mavi Ekran Hatası) tetiklediğinde, WinDbg ile çekirdek dökümünü analiz edebilir ve umarım durumu net bir şekilde görebiliriz. Hangi sürücü yakalandı? Peki neyi yanlış yaptı? Microsoft'un Driver Verifier hakkındaki referans makaleleri, çeşitli seçenekleri ve kullanım stratejilerini ayrıntılı olarak açıklıyor.

Mühendisler ve teknisyenler için pratik tavsiyeler

İster sürücü geliştiricisi, ister çekirdekle etkileşim kuran bir yazılım geliştiricisi, isterse de tüm mavi ekran hatalarıyla ilgilenen uzman teknisyen olun, mavi ekran hatalarının karmaşasında kaybolmamak için bazı temel kuralları benimsemeniz faydalı olacaktır.

Öncelikle, hatanın kendi kodunuzla ilgili olup olmadığını göz önünde bulundurmalısınız. Sorunu yeniden üretmek ve analiz etmek için çekirdek hata ayıklayıcısını sistematik olarak kullanın.Hata ayıklayıcıyı hedef makineye (ağ, seri vb. yoluyla) bağlayarak, hata denetimi sistemin doğrudan mavi ekran göstermesi yerine hata ayıklayıcı içinde durmasına neden olur. Buradan bellek, yığınlar, veri yapıları incelenebilir ve kodda hata ayıklama yapılabilir.

Diğer senaryolarda, hata kontrolleri şunlardan kaynaklanabilir: üçüncü taraf sürücüler, donanım veya yazılım Kontrolümüz dışında olan durumlar söz konusu olduğunda, amaç "kodu düzeltmekten" başka bir şeye kayar. Sorunu izole edin ve hafifletin.:

• WinDbg ve döküm analizi kullanarak şüpheli sürücüyü veya donanım bileşenini belirleyin.
• Güncelle veya geri al Sürücü sürümleri, BIOS, bellenim veya ilgili uygulamalar.
• Çıkar veya değiştir USB aygıtları, ekran kartları, ağ adaptörleri çatışmacı.
• Dayanmak için Olay görüntüleyici, Sysinternals, ağ izleme ve analiz araçları Ek bilgi için.

Görünüşte gizemli olan birçok sorun, şu yöntemle çözülüyor: temel sorun giderme prosedürleriDokümantasyonu incelemek, dosya sürümlerini ve tarihlerini kontrol etmek, temel bileşenleri yeniden yüklemek veya çakışan modülleri devre dışı bırakmak sürecin bir parçasıdır. Hata dökümünü analiz etmek, nereye bakmamız gerektiği konusunda bize net bir yön verir ve genellikle saatlerce süren deneme yanılma sürecinden bizi kurtarır.

Olayın meydana geldiği ortam gibi ortamlarda, bunun da unutulmaması gerekir. CrowdStrike Şahin Diğer EDR'lerde olduğu gibi, en sık sorulan sorular şunlarla ilgilidir: Mavi ekran hatasına ne sebep oldu ve bunu hızlıca nasıl tespit edebiliriz?WinDbg'nin sembollerle ve döküm dosyalarını açma ve analiz etme konusunda net bir prosedürle düzgün bir şekilde yapılandırılması, aksi takdirde nedenini gerçekten anlamadan "format ve yeniden yükleme" ile sonuçlanabilecek bir sorunu dakikalar içinde daraltmanıza olanak tanır.

Özetle, iyi bir bellek dökümü yapılandırması, WinDbg, Driver Verifier ve Sysinternals gibi araçların disiplinli kullanımı ve günlükleri ve yığınları metodik olarak inceleme alışkanlığı, öngörülemeyen bir düşmanın mavi ekranlarını çözüme dönüştürür. Çekirdekte neyin yanlış gittiği hakkında çok doğru bir bilgi kaynağı.Bu sayede çok daha bilinçli teknik kararlar alabiliyoruz.