Mavi Ekran (BSOD) Analizi: Minidump Dosyalarını Okuma

Tarafındankomut
0 Comments

Gece 2’de telefon çalıyor. “Sunucu yeniden başladı, ne olduğunu bilmiyoruz.” Bu cümleyi duyduğunuzda içinizin nasıl bir his kapladığını tahmin edebiliyorum. Windows Server ortamlarında en korkulan ama aynı zamanda en bilgi dolu hata türü olan BSOD (Blue Screen of Death), doğru araçlarla analiz edildiğinde size olayın tüm hikayesini anlatır. Sorun şu ki, çoğu sysadmin mavi ekranı görüp yeniden başlatıyor ve geçiyor. Oysa o minidump dosyası içinde gerçek cevap sizi bekliyor.

Bu yazıda Windows Server ortamlarında BSOD analizini, minidump dosyalarını okumayı ve gerçek dünya senaryolarından örneklerle hata ayıklama sürecini ele alacağız.

BSOD ve Minidump Dosyaları Nedir?

Windows bir kernel panic durumuna girdiğinde, yani kurtarılamaz bir hatayla karşılaştığında sistemi durdurup belleğin bir kısmını diske yazar. Bu bellek dökümlerine dump dosyası denir. Üç temel türü vardır:

  • Complete Memory Dump: Tüm fiziksel RAM içeriğini yazar. Büyük sunucularda 256GB+ olabilir, pratik değil.
  • Kernel Memory Dump: Sadece kernel modu belleğini yazar. Genellikle RAM’in %25-30’u kadar yer tutar.
  • Small Memory Dump (Minidump): En küçük seçenek, sadece 256KB-1MB. Stop kodu, yüklü sürücüler, aktif işlem listesi ve çökmeye neden olan stack bilgisini içerir.

Minidump dosyaları C:WindowsMinidump klasöründe, MMDDYYYY-NN.dmp formatında tutulur. Örneğin 011524-23456-01.dmp dosyası 15 Ocak 2024 tarihli ilk dump anlamına gelir.

Dump Ayarlarını Doğru Yapılandırmak

Analiz yapabilmek için önce sistem doğru yapılandırılmış olmalı. Çoğu zaman sysadminler “dump dosyası nerede?” diye sorar, çünkü dump yazımı ya devre dışıdır ya da yanlış ayarlanmıştır.

# Mevcut dump ayarlarini kontrol et
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl"

Bu komutun çıktısında dikkat etmeniz gereken değerler:

  • CrashDumpEnabled: 0 = Devre dışı, 1 = Complete Dump, 2 = Kernel Dump, 3 = Small Dump, 7 = Automatic
  • DumpFile: Dump dosyasının yazılacağı yol
  • MinidumpsDir: Minidump klasörü yolu
  • AutoReboot: 1 ise BSOD sonrası otomatik yeniden başlar

Sunucularınızda minidump aktif olsun diye aşağıdaki ayarı yapın:

# Minidump yazmayı aktif et ve otomatik yeniden baslatmayi kapat
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" `
    -Name "CrashDumpEnabled" -Value 3

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" `
    -Name "AutoReboot" -Value 0

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" `
    -Name "MinidumpsDir" -Value "C:WindowsMinidump"

AutoReboot değerini 0 yapmanızı özellikle öneririm. Production sunucularda BSOD sonrası otomatik restart bazen iyidir ama eğer döngüsel bir sorun varsa sunucu sürekli restart atıp hiç açılamaz hale gelir. En azından test ortamlarında 0 tutun.

WinDbg Kurulumu ve Temel Kullanım

Minidump analizi için en güçlü araç WinDbg‘dir. Microsoft’un kendi debugger’ı olan bu araç, Windows SDK ile birlikte gelir ya da Microsoft Store’dan direkt indirilebilir.

# Windows Package Manager ile WinDbg Preview kur
winget install Microsoft.WinDbg

WinDbg’yi kurduktan sonra sembol sunucusunu yapılandırmanız şart. Semboller olmadan dump analizi neredeyse anlamsız olur, fonksiyon isimlerini göremezsiniz.

# WinDbg icinde sembol yolu ayarla
.sympath srv*C:Symbols*https://msdl.microsoft.com/download/symbols
.reload

Bu komutu WinDbg’nin komut penceresine yazın. C:Symbols yerel önbellek klasörü, Microsoft’un sembol sunucusundan semboller indirilip buraya saklanır. İnternet erişimi olan sunucularda bu direkt çalışır.

İlk Minidump Analizine Başlamak

WinDbg’yi açın, File > Open Crash Dump ile minidump dosyanızı seçin. Dosya yüklendikten sonra hemen şu komutla başlayın:

!analyze -v

Bu komut WinDbg’nin otomatik analiz motorunu çalıştırır ve size şunları verir:

  • Stop kodu ve açıklaması
  • Hata veren modül veya sürücü
  • Çöküm anındaki stack trace
  • Olası nedenlerin listesi

Örnek bir !analyze -v çıktısı şöyle görünür:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.

Arguments:
Arg1: fffff802`3a1c0048, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read, 1 = write
Arg4: fffff802`3a1c0048, address which referenced memory

SYMBOL_NAME: nvlddmkm+1c0048
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys

Bu çıktı bize nvlddmkm.sys yani NVIDIA display driver’ının hatalı bellek erişimi yaptığını söylüyor. Stop kodu 0xD1 olan bu hata en klasik sürücü kaynaklı BSOD’lardan biridir.

Önemli WinDbg Komutları

Temel analiz komutlarını ezberlemek işinizi çok kolaylaştırır:

# Yüklü moduller ve sürücüleri listele
lm

# Belirli bir modülün detaylarini gör
lm m nvlddmkm

# Stack trace gör
kb

# Tüm thread'lerin stack trace'i
!stacks

# Sistem bilgilerini gör
!sysinfo

# Hangi islem çalışıyordu
!process 0 0

# Belirli bir adresin hangi modüle ait oldugunu bul
ln fffff802`3a1c0048

Sık kullanacağınız birkaç komut daha:

# IRQ seviyelerini kontrol et
!irql

# Bellek havuzu durumu
!poolused

# Sürücü dogrulama durumu
!verifier

# Kritik sistem thread'lerini gör
!thread

Gerçek Dünya Senaryosu 1: IRQL_NOT_LESS_OR_EQUAL

Geçen yıl bir müşteride tam olarak bu senaryoyla karşılaştım. Üretim ortamında çalışan bir Windows Server 2019 Hyper-V sunucusu haftada bir kez rastgele BSOD veriyordu. Stop kodu her seferinde 0x0000000A yani IRQL_NOT_LESS_OR_EQUAL idi.

Minidump analizi:

!analyze -v

BugCheck A, {fffff8034b2c0048, 2, 0, fffff8034b2c0048}

DRIVER_IRQL_NOT_LESS_OR_EQUAL

FAULTING_IP:
netvsc+15048
fffff803`4b2c0048 488b4808 mov rcx,qword ptr [rax+8]

SYMBOL_NAME: netvsc+15048
MODULE_NAME: netvsc
IMAGE_NAME: netvsc.sys

netvsc.sys Hyper-V’nin sanal ağ adaptörü sürücüsüydü. Stack trace’e bakalım:

kb

 # Child-SP          RetAddr           : Args to Child                                             : Call Site
00 ffffd001`23456780 fffff803`12345678 : 00000000`0000000a fffff803`4b2c0048 : nt!KeBugCheckEx
01 ffffd001`23456788 fffff803`4b2c0048 : 00000000`00000002 00000000`00000000 : nt!KiBugCheckDispatch+0x69
02 ffffd001`234567f0 fffff803`4b2c1234 : netvsc+0x15048
03 ffffd001`23456860 fffff803`4b2c5678 : netvsc!VmbusSendPacketMultiPageBuffer+0x234

VmbusSendPacketMultiPageBuffer fonksiyonu yüksek interrupt seviyesinde sayfalanabilir belleğe erişmeye çalışıyordu. Çözüm: netvsc.sys sürücüsünü güncellemek. Windows Update’te bekleyen Hyper-V entegrasyon servisleri güncellemesi vardı, onu uyguladık ve sorun çözüldü.

Gerçek Dünya Senaryosu 2: PAGE_FAULT_IN_NONPAGED_AREA

Bu stop kodu (0x50) en çok RAM sorunlarında, bozuk sürücülerde ve bazı antivirus çakışmalarında görülür.

!analyze -v

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.

Arguments:
Arg1: fffffa8005c23000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation.
Arg3: fffff88007a3b4c2, if non-zero, the instruction address which referenced the bad memory.
Arg4: 0000000000000000

FAULTING_IP:
cbfs6+b4c2
fffff880`07a3b4c2 488b4010 mov rax,qword ptr [rax+10h]

IMAGE_NAME: cbfs6.sys

cbfs6.sys bir üçüncü taraf uygulama tarafından yüklenen dosya sistemi filtre sürücüsüydü. Bu müşteride bir backup yazılımının sürücüsüydü. Firmware güncellemesinden sonra uyumsuz hale gelmişti.

Bu tür durumlarda şu komutu da çalıştırın:

# Sistem üzerindeki üçüncü taraf sürücüleri listele
Get-WmiObject Win32_SystemDriver | 
    Where-Object {$_.PathName -notlike "*Windows*"} | 
    Select-Object Name, PathName, State |
    Format-List

Gerçek Dünya Senaryosu 3: CRITICAL_PROCESS_DIED

Bu stop kodu (0xEF) özellikle Windows Server 2016+ ile sık karşılaşılan bir durum. Kritik bir sistem işlemi beklenmedik şekilde sonlandığında çıkar.

!analyze -v

CRITICAL_PROCESS_DIED (ef)
A critical system process died

PROCESS_NAME: lsass.exe

lsass.exe öldüğünde Windows çöküyor çünkü authentication için kritik. Bu durumda saldırı mı, bellek sızıntısı mı, yoksa sürücü çakışması mı olduğunu anlamak için daha derin bakmak gerekir:

# Çöken prosesin handle bilgilerine bak
!handle 0 f

# Proses bellek durumunu incele
!vm 1

# Exception kayıtlarını kontrol et
.exr -1
.cxr -1

Bu senaryoda genellikle event log’larla beraber inceleme yapmak gerekir. Minidump analizi event log ile birleştiğinde çok daha güçlü bir tablo ortaya çıkar.

Driver Verifier ile Proaktif Hata Yakalama

Eğer BSOD’ların kaynağını bulamıyorsanız, Driver Verifier çok güçlü bir araçtır. Kernel modu sürücülerini daha sıkı kurallarla çalıştırır ve hatayı daha erken, daha açık bir şekilde yakalatır.

# Tüm üçüncü taraf sürücülerde dogrulama aktif et
verifier /flags 0x009BB /all

# Belirli bir sürücüde aktif et
verifier /flags 0x009BB /driver nvlddmkm.sys

# Mevcut dogrulama durumunu gör
verifier /query

# Dogrulama istatistiklerini gör  
verifier /querysettings

Uyarı: Driver Verifier production ortamında çalıştırmayın. Bu araç kasıtlı olarak sürücüleri daha hassas hale getirir ve test ortamına özgüdür. Aktif ettikten sonra sistemi yeniden başlatın ve sorunlu senaryoyu tekrar etmeye çalışın.

Otomatik Minidump Analizi: PowerShell ile Toplu İnceleme

Birden fazla dump dosyanız varsa her birini tek tek WinDbg’ye yüklemek yorucu olabilir. PowerShell ile toplu analiz yapabilirsiniz:

# Minidump klasöründeki tüm dosyaları listele
$dumpPath = "C:WindowsMinidump"
$dumps = Get-ChildItem -Path $dumpPath -Filter "*.dmp" | Sort-Object LastWriteTime -Descending

foreach ($dump in $dumps) {
    Write-Host "Dosya: $($dump.Name)" -ForegroundColor Yellow
    Write-Host "Tarih: $($dump.LastWriteTime)"
    Write-Host "Boyut: $([math]::Round($dump.Length/1KB, 2)) KB"
    Write-Host "---"
}

WinDbg komut satırı arayüzü olan cdb.exe ile otomatik analiz yapabilirsiniz:

# WinDbg ile otomatik analiz script'i
$windbgPath = "C:Program Files (x86)Windows Kits10Debuggersx64cdb.exe"
$symbolPath = "srv*C:Symbols*https://msdl.microsoft.com/download/symbols"
$dumpDir = "C:WindowsMinidump"
$outputDir = "C:DumpAnalysis"

New-Item -ItemType Directory -Force -Path $outputDir | Out-Null

Get-ChildItem -Path $dumpDir -Filter "*.dmp" | ForEach-Object {
    $outputFile = Join-Path $outputDir "$($_.BaseName).txt"
    
    & $windbgPath -z $_.FullName `
        -y $symbolPath `
        -c "!analyze -v; q" `
        -logo $outputFile `
        -nosqm
    
    Write-Host "Analiz tamamlandi: $outputFile"
}

Bu script her dump dosyası için bir metin çıktısı üretir ve C:DumpAnalysis klasörüne kaydeder.

Event Log ile Korelasyon

Minidump analizi tek başına yeterli değil. BSOD öncesi sistem event log’larını da incelemeniz gerekir:

# BSOD tarihine yakin kritik event'leri bul
$bsodTime = (Get-Item "C:WindowsMinidump*.dmp" | 
    Sort-Object LastWriteTime -Descending | 
    Select-Object -First 1).LastWriteTime

$startTime = $bsodTime.AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Level = 1,2  # Critical ve Error
    StartTime = $startTime
    EndTime = $bsodTime
} | Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List
# BSOD event'lerini (Event ID 1001) bul
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 1001
    ProviderName = 'Microsoft-Windows-WER-SystemErrorReporting'
} | Select-Object -First 10 | Format-List

Bu komutlar size hem sistemin çökmeden önceki durumunu hem de Windows’un kaydettiği hata raporlarını gösterir.

Uzak Sunucularda Remote Analiz

Production ortamında sunucuya her zaman fiziksel erişiminiz olmayabilir. WinDbg ile uzaktan debug mümkün ama dump dosyasını yerel makineye çekip analiz etmek daha pratik:

# Uzak sunucudan dump dosyasını kopyala
$remoteServer = "SRVPROD01"
$remoteDumpPath = "\$remoteServerC$WindowsMinidump"
$localPath = "C:RemoteDumps$remoteServer"

New-Item -ItemType Directory -Force -Path $localPath | Out-Null

# Son 7 gunun dump'larini kopyala
Get-ChildItem -Path $remoteDumpPath -Filter "*.dmp" | 
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
    Copy-Item -Destination $localPath

Write-Host "Kopyalanan dosyalar:"
Get-ChildItem -Path $localPath

Sık Karşılaşılan Stop Kodları ve Anlamları

Bazı stop kodları o kadar sık karşımıza çıkar ki neredeyse refleks olarak ne olduğunu bilmek gerekir:

  • 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED): Genellikle sürücü uyumsuzluğu, son yüklenen sürücüyü kontrol edin
  • 0x0000003B (SYSTEM_SERVICE_EXCEPTION): Kernel servis çağrısında hata, sürücü veya donanım sorunu
  • 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL): Sürücü yanlış IRQL seviyesinde belleğe erişti
  • 0x00000050 (PAGE_FAULT_IN_NONPAGED_AREA): Geçersiz bellek referansı, RAM veya sürücü sorunu
  • 0x0000001E (KMODE_EXCEPTION_NOT_HANDLED): Kernel modu işlemcisi exception yakalamadı
  • 0x0000007F (UNEXPECTED_KERNEL_MODE_TRAP): Donanım arızası veya aşırı ısınma
  • 0x0000009F (DRIVER_POWER_STATE_FAILURE): Güç durumu geçişlerinde sürücü hatası
  • 0x000000EF (CRITICAL_PROCESS_DIED): Kritik sistem işlemi sonlandı
  • 0xC0000005 (ACCESS_VIOLATION): Yasaklı bellek bölgesine erişim

Önleyici Tedbirler

Analiz kadar önemli olan konu, BSOD’ların tekrarını önlemek. Şu uygulamaları rutin haline getirin:

# Sürücü imza dogrulama durumunu kontrol et
bcdedit /enum | Select-String "nointegritychecks"

# Signed olmayan sürücüleri listele
Get-AuthenticodeSignature -FilePath (
    Get-ChildItem "C:WindowsSystem32drivers*.sys" | 
    Select-Object -ExpandProperty FullName
) | Where-Object {$_.Status -ne "Valid"} | 
    Select-Object Path, Status
# Bellek testini zamanlanmis gorev olarak kur (maintenance window'da)
$action = New-ScheduledTaskAction -Execute "mdsched.exe"
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At "02:00AM"
Register-ScheduledTask -TaskName "WeeklyMemoryTest" `
    -Action $action -Trigger $trigger -RunLevel Highest

Ayrıca şu kontrolleri periyodik yapın:

  • Windows Update: Sürücü güncellemeleri özellikle
  • Firmware güncellemeleri: NIC, RAID controller, HBA kart firmware’leri
  • Sıcaklık izleme: 0x7F stop kodu görüyorsanız donanım sıcaklıklarına bakın
  • Disk sağlığı: Bellek dökümü yazılamazsa dump oluşmuyor bile

Sonuç

BSOD analizi başta korkutucu görünse de aslında çok sistematik bir süreç. Doğru araçlarla (WinDbg, sembol sunucusu, Event Log) ve doğru adımlarla (dump ayarları, !analyze -v, stack trace inceleme) olayın kaynağına ulaşmak mümkün. Üstelik bu analiz sizi hem sürücü sorunlarından, hem donanım hatalarından, hem de bazen güvenlik ihlallerinden haberdar eder.

En önemli tavsiyem: Sunucularınızda minidump yazımının aktif olduğundan emin olun ve dump dosyalarını en az 30 gün saklayın. Çünkü bazı sorunlar haftalar sonra tekrarlar ve o eski dump dosyası çok değerli olabilir. Bir BSOD sizi aydınlatmak için fırsat kolluyor, siz de onu iyi değerlendirin.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir