Windows’ta Memory Dump Analizi ile Sorun Giderme

Yazar:komut.io ekibi Windows Sunucu İzleme ve Performans Yönetimi
0 Yorum

Üretim ortamında bir Windows sunucusu sabah 3’te çöktüğünde ve ekibin önünde sadece bir .dmp dosyası kaldığında, o dosyayı okuyabilmek ile okuyamamak arasındaki fark bazen saatler süren kesinti anlamına gelir. Memory dump analizi, birçok sysadmin’in “gerektiğinde bakacağım” deyip ertelediği, ama ilk ciddi krizde keşke daha önce öğrenmiş olsaydım dedirtecek kadar değerli bir beceri. Bu yazıda teorik kalmayacağız; gerçek senaryolar, gerçek komutlar ve kazanılmış deneyimlerle Windows memory dump analizini baştan sona ele alacağız.

Memory Dump Nedir ve Neden Önemli?

Windows bir BSOD (Blue Screen of Death) aldığında ya da bir uygulama process’i beklenmedik şekilde sonlandığında, sistemin o anki bellek içeriğini diske yazması mümkün. Bu yazılan içeriğe memory dump diyoruz. İçinde o an çalışan thread’ler, yüklü driver’lar, kernel yapıları, stack frame’leri ve hangi işlemin ne yaptığına dair paha biçilmez bilgiler bulunuyor.

Bunu bir kaza soruşturmasındaki kara kutu kaydına benzetebiliriz. Sistem neden çöktü sorusunun cevabı çoğunlukla o dosyanın içinde.

Dump dosyaları üç ana kategoriye giriyor:

  • Complete Memory Dump: Fiziksel RAM’in tamamını yazar. En büyük ama en bilgilisi.
  • Kernel Memory Dump: Sadece kernel mod belleğini yazar. Çoğu BSOD analizi için yeterli.
  • Minidump: Küçük, temel bilgileri içerir. Hızlı ön değerlendirme için kullanışlı.
  • Automatic Memory Dump: Windows 8 ve sonrasında default. Kernel dump’a benzer ama boyutu sistem tarafından yönetilir.

Hangi dump türünün alınacağını şu registry key’den kontrol edebilirsiniz:

reg query "HKLMSYSTEMCurrentControlSetControlCrashControl"

Çıktıda CrashDumpEnabled değerine bakın. 0 dump yok, 1 complete, 2 kernel, 3 small/minidump, 7 automatic demek.

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

Analiz yapabilmek için önce sistemin dump ürettiğinden emin olmak gerekiyor. Bunu gözden kaçıran ekipler, olay olduktan sonra ellerinde hiçbir şey kalmadığını fark ediyor. Özellikle Türkiye’deki birçok kurumsal ortamda dump ayarlarının fabrika default’unda bırakıldığını görüyorum; bu büyük bir risk.

Ayarları PowerShell ile kontrol edip düzenleyebiliriz:

# Mevcut crash dump ayarlarını görüntüle
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl"

# Kernel dump aktif et, debug bilgisi yaz, otomatik yeniden başlat
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "CrashDumpEnabled" -Value 2
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "AutoReboot" -Value 1
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "LogEvent" -Value 1

Dump dosyasının yazılacağı yeri ve paging file boyutunu da kontrol etmelisiniz. Paging file, dump yazımı için kritik. Eğer paging file yoksa ya da çok küçükse Windows dump yazamaz.

# Paging file bilgisini kontrol et
Get-WmiObject -Class Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize

# Sistem drive'ındaki boş alanı kontrol et
Get-PSDrive C | Select-Object Used, Free

Dump dosyası varsayılan olarak %SystemRoot%MEMORY.DMP yoluna yazılır. Bunu farklı bir diske yönlendirmek, özellikle sistem disk’i küçükse iyi bir pratik.

WinDbg Kurulumu ve Temel Kullanım

Windows dump analizinin kalbi WinDbg. Microsoft’un kendi debugger’ı. Windows SDK’nın bir parçası olarak geliyor ama artık Microsoft Store üzerinden de WinDbg Preview olarak indirebilirsiniz. Preview sürümü daha modern arayüze sahip ve aktif geliştiriliyor.

Kurulumdan sonra ilk yapmanız gereken symbol path’i ayarlamak. Symbol dosyaları olmadan WinDbg size adres değerleri gösterir ama bunların ne anlama geldiğini söyleyemez. Microsoft’un public symbol server’ı hayat kurtarıcı.

# WinDbg'yi komut satırından başlatırken symbol path vermek
windbg -y "srv*C:Symbols*https://msdl.microsoft.com/download/symbols" -z C:WindowsMEMORY.DMP

WinDbg açıldıktan sonra symbol path’i GUI üzerinden de ayarlayabilirsiniz ama otomasyonu düşünüyorsanız komut satırı daha pratik. C:Symbols local cache olarak kullanılıyor; bir kez indirilince tekrar sunucuya gidilmiyor.

Dump dosyasını açtıktan sonra ilk çalıştırmanız gereken komut:

!analyze -v

Bu komut WinDbg’nin otomatik analiz motorunu devreye alır ve size başlangıç noktası verir. Verbose mod (-v) çok daha fazla detay sağlar. Çıktı uzun olabilir ama şu bölümlere odaklanın:

  • FAULTING_IP: Hatanın oluştuğu instruction pointer
  • BUGCHECK_STR: BSOD hata kodu
  • PROCESS_NAME: Problemi tetikleyen process
  • STACK_TEXT: Call stack, en kritik kısım

Gerçek Senaryo 1: DRIVER_IRQL_NOT_LESS_OR_EQUAL

Bu BSOD kodu, Türkiye’deki kurumsal ortamlarda en sık karşılaştığım hatalardan biri. Genellikle bir driver’ın yanlış IRQL seviyesinde belleğe erişmeye çalışması sonucu oluyor. VPN client’ları, eski network driver’ları ve üçüncü parti güvenlik yazılımları başlıca suçlular.

Dump’ı açıp !analyze -v çalıştırdıktan sonra şüpheli driver’ı belirlemek için:

# Yüklü driver'ları listele, en son yüklenenler üstte
lm t n

# Belirli bir modülün detaylarını gör
lm v m <module_name>

# Driver'ın timestamp'ini kontrol et (eski driver'lar sorun çıkarır)
!lmi <module_name>

lm t n komutu yüklü tüm modülleri timestamp ile birlikte listeler. Eğer !analyze size bir driver adı vermişse, o driver’ın ne zaman derlendiğine ve sürümüne bakın. Tarihi 5 yıldan eski bir kernel driver görürseniz, muhtemelen sorunun kaynağını buldunuz demektir.

Stack trace’e bakmak için:

# Aktif thread'in stack trace'i
kb

# Tüm thread'lerin stack trace'lerini göster
!stacks

Gerçek Senaryo 2: Uygulama Process Dump Analizi

BSOD değil de bir uygulama sürekli çöküyorsa, user-mode dump analizi yapmanız gerekiyor. Task Manager üzerinden ya da ProcDump aracı ile bu dump’ı üretebilirsiniz.

ProcDump, Sysinternals ailesinden ve gerçekten vazgeçilmez bir araç. Belirli bir process crash olduğunda otomatik dump almasını söyleyebilirsiniz:

# w3wp.exe (IIS worker process) crash olduğunda dump al
procdump -e -ma w3wp.exe C:Dumps

# Process %90 CPU'yu geçtiğinde dump al (performans sorunları için)
procdump -c 90 -ma w3wp.exe C:Dumps

# Belirli bir exception tipinde dump al
procdump -e 1 -f "System.OutOfMemoryException" -ma w3wp.exe C:Dumps

Bu dump dosyasını WinDbg’de açtıktan sonra .NET uygulama ise SOS extension’ı yüklemeniz gerekiyor:

# .NET 4.x için SOS yükle
.loadby sos clr

# .NET Core / .NET 5+ için
.load C:pathtosos.dll

# Managed thread'leri listele
!threads

# Heap istatistiklerini gör
!dumpheap -stat

# En çok yer kaplayan objeleri bul
!dumpheap -stat -type System.String

!dumpheap -stat komutu OutOfMemoryException analizinde altın değerinde. Hangi tipten kaç nesne üretildiğini ve toplam ne kadar bellek kapladığını gösterir. Bir kerinde bir IIS uygulamasında DataTable nesnelerinin binlerce adet üretilip dispose edilmediğini bu komutla dakikalar içinde tespit ettim.

Gerçek Senaryo 3: Beklenmedik Yeniden Başlatmalar

Sistem BSOD almadan yeniden başlıyor ve event log’da da anlamlı bir şey görünmüyorsa, bu genellikle donanım sorunu ya da kernel panic’in dump yazılmadan tamamlanması demek. Ama önce dump ayarlarını kontrol etmek gerekiyor.

# Son sistem başlatmalarını ve kapanmalarını gör
Get-EventLog -LogName System -Source "EventLog" -EntryType Information | 
  Where-Object {$_.EventID -in @(6005, 6006, 6008)} | 
  Select-Object TimeGenerated, EventID, Message | 
  Sort-Object TimeGenerated -Descending | 
  Select-Object -First 20

EventID 6008 “unexpected shutdown” anlamına gelir. Bu event’ı gördüğünüzde, hemen ardından gelen event’lara bakın. Birlikte analiz edildiğinde anlamlı ipuçları çıkabiliyor.

Dump varsa, crash zamanındaki sistemi WinDbg’de şöyle inceleyebilirsiniz:

# Crash sırasındaki tüm process'leri listele
!process 0 0

# Belirli bir process'in thread'lerini gör
!process <adres> 7

# CPU'yu en çok kullanan thread'i bul
!runaway

!runaway komutu benim favorilerimden. Thread’lerin toplam CPU sürelerini gösterir. Bir thread anormal şekilde uzun süre CPU kullanıyorsa, muhtemelen sonsuz döngüye girmiş ya da deadlock’a yakalanmıştır.

Minidump ile Hızlı Triage

Her zaman full dump analizi yapmak gerekmez. Özellikle ilk değerlendirmede minidump dosyaları hız açısından avantajlı. C:WindowsMinidump altındaki dosyaları inceleyin.

Eğer çok sayıda minidump varsa ve hepsine tek tek bakmak istemiyorsanız, PowerShell ile hızlıca okuyabilirsiniz:

# Minidump dosyalarını tarih sırasıyla listele
Get-ChildItem "C:WindowsMinidump" -Filter "*.dmp" | 
  Sort-Object LastWriteTime -Descending | 
  Format-Table Name, LastWriteTime, @{N='Size(MB)';E={[math]::Round($_.Length/1MB,2)}}

WinDbg’de minidump açıldığında bazı komutlar tam memory olmadığı için çalışmaz, ama !analyze -v ve temel stack analizi yapılabilir durumda olur.

Symbol Sorunları ve Çözümleri

WinDbg kullanırken en sık karşılaşılan sorun symbol’lerin yüklenmemesi. Semboller yüklenmemişse stack trace anlamsız adresler dizisi haline gelir.

# Symbol durumunu kontrol et
!sym noisy

# Symbol path'i kontrol et ve yenile
.sympath

# Symbol'leri yeniden yükle
.reload /f

# Belirli bir modül için symbol'ü zorla yükle
.reload /f ntoskrnl.exe

.sym noisy modunu açtığınızda WinDbg size symbol aramasının her adımını gösterir. “Symbol not found” hatası alıyorsanız bu mod ile nerede takıldığını görmek çok yardımcı oluyor.

Kurumsal ortamlarda internet erişimi olmayan sunucularda symbol server’a ulaşamama sorunu yaşanıyor. Bu durumda önce internet erişimi olan bir makinede symbol’leri indirip, ardından network share üzerinden kullanmak mantıklı:

# Symbol'leri local'e indir (internet erişimi olan makinede)
symchk /r C:WindowsSystem32 /s srv*C:Symbols*https://msdl.microsoft.com/download/symbols

# Sonra WinDbg'de local path'i kullan
.sympath C:Symbols

Otomasyonla Düzenli Dump Analizi

Büyük ortamlarda dump dosyaları üretildiğinde bunları merkezi bir yere toplamak ve otomatik analiz çalıştırmak zaman kazandırır. WinDbg komut satırından çalıştırılabilir ve çıktı dosyaya yönlendirilebilir:

# WinDbg'yi headless modda çalıştır ve analiz çıktısını dosyaya yaz
windbg -y "srv*C:Symbols*https://msdl.microsoft.com/download/symbols" ^
       -z "C:DumpsMEMORY.DMP" ^
       -c "!analyze -v; .logclose; q" ^
       -logo C:Analysisoutput.txt

Bu komutu bir PowerShell script’ine sarıp yeni dump dosyaları oluştuğunda otomatik tetikleyebilirsiniz:

# Yeni dump dosyası geldiğinde otomatik analiz başlatan watcher
$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = "C:WindowsMinidump"
$watcher.Filter = "*.dmp"
$watcher.EnableRaisingEvents = $true

Register-ObjectEvent $watcher "Created" -Action {
    $file = $Event.SourceEventArgs.FullPath
    $output = "C:Analysis$(Split-Path $file -Leaf).txt"
    
    Start-Process windbg -ArgumentList @(
        "-y", "srv*C:Symbols*https://msdl.microsoft.com/download/symbols",
        "-z", $file,
        "-c", "!analyze -v; .logclose; q",
        "-logo", $output
    ) -Wait -NoNewWindow
    
    Write-EventLog -LogName Application -Source "DumpAnalysis" `
      -EventId 1001 -Message "Analiz tamamlandı: $output"
}

Sık Görülen BSOD Kodları ve İlk Bakış Noktaları

Dump analizinde zaman kazanmak için sık karşılaşılan hata kodlarına özel yaklaşımlar geliştirmek önemli.

SYSTEM_SERVICE_EXCEPTION (0x3B): Genellikle bir driver hatası. !analyze -v sonrasında stack trace’de üçüncü parti driver görünüyorsa ilk şüpheli o.

PAGE_FAULT_IN_NONPAGED_AREA (0x50): Belleğe geçersiz adresle erişim. Driver veya donanım sorunu olabilir.

IRQL_NOT_LESS_OR_EQUAL (0xA): Yüksek IRQL’de paged memory erişimi. Eski ya da buggy driver işareti.

KERNEL_SECURITY_CHECK_FAILURE (0x139): Stack corruption veya güvenlik ihlali. Zararlı yazılım ya da bozuk driver.

Bu kodların her biri için WinDbg analiz akışı şöyle ilerler:

# Temel analiz
!analyze -v

# Hatalı modülü belirle
lm t n

# Stack trace
kn

# Exception parametrelerine bak
.exr -1

# Exception kaydının tamamı
.ecxr

.exr -1 ve .ecxr birlikte kullanıldığında exception’ın tam context’ini görürsünüz. Özellikle PAGE_FAULT hatalarında erişilmeye çalışılan adres ve ne tür bir erişim yapıldığı bu komutlarla netleşiyor.

Dump Analizi Sonrası Aksiyon Planı

Analiz tamamlandıktan sonra bulguları sistematik şekilde kaydetmek ve aksiyon almak gerekiyor. Ben her dump analizi sonrası şu yapıyı kullanıyorum:

  • Root Cause: Hangi modül, hangi fonksiyon
  • Evidence: Stack trace, ilgili modül versiyonu
  • Timeline: Sorun ne zaman başladı, ne değişti
  • Fix: Driver güncellemesi mi, yapılandırma değişikliği mi, donanım değişimi mi
  • Verification: Fix sonrası izleme planı

Bir banka müşterisinde karşılaştığım vakada, ayda bir yaşanan BSOD’un kaynağı 4 yıllık bir HBA driver’ıydı. !analyze -v doğrudan suçlu modülü göstermemişti, ama lm t n ile modüllerin timestamp’lerine bakınca o driver sıyrılıp çıktı. Güncel sürüme geçtikten sonra sorun tamamen ortadan kalktı. Aylarca “donanım sorunu olabilir” denilen şey aslında bir driver versiyonu meselesiydi.

Sonuç

Memory dump analizi öğrenmesi vakit alan ama karşılığını kat kat veren bir beceri. WinDbg’nin ilk açılışında komutlar karmaşık görünebilir, ama !analyze -v ile başlayıp stack trace okumayı öğrendikten sonra geri kalan organik olarak gelişiyor.

Bugün yapabileceğiniz en değerli şey şu: Test ortamınızda bir sunucunun dump ayarlarını kontrol edin, WinDbg’yi kurun, symbol path’i yapılandırın ve mevcut bir minidump dosyası varsa onunla alıştırma yapın. Kriz anında ilk kez dump açmak yerine, sakin bir günde alıştırma yapmak çok daha öğretici.

Türkiye’deki pek çok kurumda bu araçların varlığından habersiz ekipler var. Bir BSOD yaşandığında yapılan ilk şey sunucuyu yeniden başlatmak, dump dosyasını silmek ve “bakacağız” deyip geçmek oluyor. Bu döngüyü kırmak, sonraki krizi birkaç saatte değil birkaç dakikada çözmek demek. O fark, gece 3’te çöken bir production sunucusunda çok şey ifade ediyor.

Bir yanıt yazın

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