WinDbg ile Windows BSOD Crash Dump Dosyalarının Analiz Edilmesi

Hepimizin mutlaka bir kez başına gelmiştir. Windows sunucunuz yada bilgisayarınız bir anda “Mavi Ekran” (BSOD) dediğimiz kritik bir sistem hatası oluşturup çökerek(crash) kendini restart etmiş, akabinde veri kaybına ve uygulama problemlerine sebep olmuştur. Yaşamaktan çekindiğimiz böyle bir durumda en büyük sıkıntı sorunun kaynağını bulmak ve tekrar etmesini önlemektir. Bu makalede BSOD ile sonuçlanan sistem hatalarının olası köküne inmek için kullanabileceğimiz Crash Dump dosyalarından ve WinDbg aracından bahsedeceğim.

 

Aşağıdaki örnek BSOD hatasına baktığınızda da fark etmişsinizdir. Bir sistem crash durumunda zar zor yakaladığımız bu tanıdık görüntünün genelde bize pek yardımcı olmadığını söyleyebiliriz. STOP 0x000 ile başlayan hata kodlarını araştırdığımızda da çoğunlukla sorunun nedeni adına tahminlerden öte bir yere varamıyoruz. Ama bu noktada umudu kesmek yerine problemin analizi için memory dump dosyalarını ve Windows debugger aracını devreye sokabiliriz.

 

 

 

 

Memory Dump

 

Öncelikle, memory dump nedir ve WinDbg debug aracı ne işe yarar kısaca açıklayalım:

 

Memory dump dosyası, oluşturulduğu anda sisteminin fiziksel bellekte tuttuğu verilerin diskteki bir yansıması gibidir. Bellekte yüklü binary ve executable dosyalar gibi birçok veriyi barındırır. BSOD ekranında görebileceğiniz gibi crash durumunda işletim sistemi otomatik olarak fiziksel bellekten bir memory dump oluşturmaktadır. Bizim açımızdan bu dosyalar gerçek hatayı ayıklamak için kullanılabilir. Bunun dışında uygulama geliştiricileri ve computer forensic analiz uzmanları da memory dump’lardan yararlanmaktadır. Birkaç tipi bulunur:

 

Small (Mini) Memory dump: Bu dump türü en az veriyi içerir. Boyutu 2MB’a kadar çıkabilir. İçerisinde Stop mesajı ve parametrelerini, yüklü driver listesini, hata veren process ve thread bilgilerini, gene bu thread için kernel-mode call stack bilgilerini barındırır. Bellekteki binary ve çalıştırılabilir dosyaları içermez, bu yüzden ayıklama aşamasında bu dosyalara ihtiyaç duyulmaktadır. Hata belirleme konusunda faydalı olabildiği gibi bazı durumlarda yetersiz kalabilir.

 

Kernel Memory dump: Sadece kernel belleğinin içeriğini barındırır. Bu yönüyle hem minidump‘ dan çok daha kapsamlı hemde complete dump kadar büyük alana ihtiyaç duymamaktadır. Sistem fiziksel belleğine göre 150MB ila 2GB civarında bir boyuta sahip olabilir.Sadece kernel ve donanım katmanı(HAL) için ayrılmış bellekle beraber kernel modu programlarının ve kernel sürücülerinin bellekteki verilerini içerir. Bir çok durumda en işe yarayan dump türüdür, hariç tuttuğu bellek içeriği genelde problemle ilgisi pek olası olmayan kısımdır.

 

Complete Memory dump: Adından da anlaşılacağı gibi hata anında bellekte bulunan bütün veri içeriğini barındırmaktadır. Boyutu fiziksel belleğin boyutunun 1MB fazlasıdır. Hata ayıklama için en çok bilgiyi ve ayrıntıyı içerir. Fakat bir dezavantajı, dump oluşturma sırasında işletim sisteminin baştan başlama süresini oldukça uzatmasıdır. 16GB fiziksel bellek içeren bir SQL sunucunun complete memory dump almasını beklemek her zaman pratik olmayabilir.

 

Memory Dump ayarlarını işletim sistemi içerisinden yapabiliriz.  Ayarların konumu aşağıdaki gibidir.
Computer Settings > Advanced System Settings > Advanced > Startup and Recovery  > Settings …

 

Önerilen seçenek Kernel memory dump almaktır. Ayrıca burada gördüğünüz gibi crash durumunda oluşturulan dump dosyasının konumu varsayılan olarak Windows klasörünün altındadır, analiz işlemi için buradan ulaşabiliriz.

 

 

 

 

 
WinDbg Windows Debugging Tool

 

WinDbg, programlama dilleri ile uğraşanların daha aşina olduğu bir terim olan debugging yani hata ayıklama işlevi gören bir araçtır. Sürücüler, kernel mod işletim sistemi ve kullanıcı mod uygulamalardaki hataları ayıklamak için kullanılabilir. Örneğin crash olan bir sistemin memory dump’ını yada IIS üzerinde çalışan ve worker process’i crash olan bir web uygulamasını analiz etmek gibi çeşitli konularda kullanabilirsiniz. Hatta yanıt vermeyen asılı kalmış(hang) diyebileceğimiz uygulamaları incelemek ve memory leak durumlarını tespit için de faydalanılabilmektedir. Grafik arabirimine sahip olduğu için WinDbg, komut satırı üzerinden kullanılan benzerlerine nazaran daha kullanıcı dostudur. Biz aklımızı daha fazla karıştırmadan bu araç ile BSOD durumlarını analiz etmeye odaklanacağız.

 

Microsoft tarafından ücretsiz sağlanmakta olan aracın Windows 7 SDK ile gelen 32-bit yada 64-bit en son sürümünü buradan indirebilirsiniz. Kurulum aşaması oldukça standart, bu yüzden makalede ayrıca bahsetmeyeceğim. Birkaç kez ileri basarak kurulumun indirip yüklenmesini sağlayabilirsiniz.

 

Bundan sonra bilmeniz gereken tek konu windows sembol (symbol) dosyaları. Sembol dosyaları kısaca bir uygulamanın derlenmesi sırasında oluşturulan fakat çalıştırılması sırasında gerekli olmayan bilgileri içerir. Hata ayıklama sırasında gereken global ve lokal değişken isimleri, adresleri; fonksiyon isimleri , kaynak dosya konum ve satır bilgileri gibi veriler barındırır. Hata ayıklama işleminin başarılı olabilmesi için oldukça önemlidir, çünkü memory dump dosyalarının anlamlı olabilmesi doğru sembol dosyalarının kullanılmasına bağlıdır. 256KB boyutundaki bir minidump dosyası ancak böyle bir anlam ifade edebilir. Hatayı üreten işletim sistemini baz alarak windows sürüm, service pack ve platformuna göre seçilmelidir. Örneğin bir Windows server 2003 x64 SP2 memory dump dosyasını Windows XP client işletim sistemi üzerinde analiz etmek için Windows Server sembol dosyalarına ihtiyacınız olacaktır.

 

WinDbg ile beraber kullanacağımız ilgili sembol dosyalarını 2 şekilde temin edebiliriz. MSDN üzerinden buraya tıklayarak direk indirebilir yada Microsoft Symbol Server kullanarak hata ayıklama sırasında sadece gerekenlerin online olarak indirilmesini sağlayabilirsin. Paket başına 800MB civarı yer kaplayan önceden indirilmiş sembol dosyaları hız konusunda size avantaj sağlar. Ben iki yönetimde denemiş olarak burada Symbol Server üzerinden kullanımı tercih ettim, teknik olarak hata ayıklama işleminde bir farklılık olmayacak. Eğer kurulumu bir dosya paketi gibi olan sembol dosyalarını indirip yüklemeyi seçerseniz yükleme yolunu not alın, birazdan ihtiyacımız olacak.

 

Not: MSDN üzerinde “retail” ve “checked” 2 çeşit sembol dosyası paketleri olduğunu göreceksiniz. Retail olanları tercih ediniz.

 

Hata Ayıklama ve Analiz

 

Bu kadar teorik bilgi yeter, artık işe koyulalım. Kurulumunu yaptığınız WinDbg programına başlat menüsü altından Debugging Tools for Windows klasörü içerisinden ulaşarak çalıştırın. Önce Sembol dosyası yolunu belirlemek için File menüsü altından Symbol File Path üzerine tıklayalım.

 

 

 

Açılan pencere içerisinde sembol dosyalarının konumunu belirleyeceğiz.

Eğer sembol dosyalarının kurulumunu yaptıysak C:Symbol gibi kurulum için seçtiğiniz yolu girebilirsiniz.

Fakat Microsoft Symbol Server tercih ettiyseniz tam olarak aşağıdaki gibi bir konum belirtmeniz gerekecek. C:websymbols yerine size uygun olan klasörü girebilirsiniz. Bu klasöre sadece sembol dosyalarının size gereken kısımları indirilerek tutulacaktır.

 

    SRV*c:websymbols*http://msdl.microsoft.com/download/symbols

 

 

 

 

 

OK butonu ile sembol yolunu onayladıktan sonra memory dump dosyamızı açabiliriz. Hatırlarsanız varsayılan olarak c:windowsmemory.dmp konumunda olabileceğini söylemiştik. Ben makalede gerçek bir durumda oluşmuş minidump dosyası kullandım.

Tekrar File menüsünden Open Crash Dump seçerek ilgili dump dosyasını belirtelim. Dosya açılmadan önce çıkan ” Save Information for workspace ? ” soru dialog kutusuna OK diyerek devam edebiliriz.

 

 

 

 

Gördüğünüz gibi hata ayıklama işlemi bir konsol ekranı içerisinde çalıştı ve bize dump dosyası ile ilgili bilgi üretmeye başladı. Dump dosyasının türü, oluştuğu işletim sistemi gibi verilerden sonra kernel sembolleri yüklenir. Bu aşama symbol server kullananlar için internet hızına bağlı olarak belirli bir süre alabilir.

 

Image ve Kernel sembollerinin yüklemesi sırasında bazı hatalar alabilirsiniz:

 

Eğer aşağıdakine benzer bir hata alırsanız target yani memory dump’ını aldığınız işletim sistemi ile şu an WinDbg kullandığınız source işletim sistemi arasında uyuşmazlık var demektir.

 

 Unable to load image SystemRootsystem32ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
*** ERROR: Module load completed but symbols could not be loaded for ntkrnlpa.exe Loading Kernel Symbols

 

Bazı şartlarda sorun teşkil etmeyeceği gibi özellikle içerdiği kısıtlı veri nedeniyle minidump analizi yaparken bu bir başarısızlığa neden olabilir. Problemi aşmak için hata ayıklama işlemini bizzat crash yaşamış sistem üzerinde yapabilir yada birebir aynı işletim sistemine sahip bir makinada tekrar deneyebilirsiniz.

 

Eğer  “***** Kernel symbols are WRONG. Please fix symbols to do analysis.”  gibi bir hata alırsanız büyük ihtimalle yanlış sembol dosyalarını kullanmaya çalışıyorsunuz, indirdiğiniz paketi kontrol edin. Diğer bir olası neden ise gene minidump dosyaları söz konusu olduğunda hata veren sistemden farklı bir işletim sistemi üzerinde çalışılması olabilir. Örneğin bir Windows 2008 R2 x64 memory dump dosyasını Windows XP 32-bit üzerinde debug etmeye kalktığınızda tahmin edeceğiniz gibi sıkıntı yaşayabilirsiniz.

 

Bu adımda bir hata almadıysak WinDbg bize Bugcheck Analysis işlemiyle BSOD sebebi hatanın olası nedeni hakkında bilgi vermeye başlayacaktır. Sonuca baktığımızda bize snapman.sys sürücüsünü işaret ediyor.

 

 

 

Tabi bu kadarıyla hemen yetinmiyoruz. Daha detaylı analiz işlemini başlatarak derine ineceğiz. Komut satırına  “!analyze -v” yazarak yada konsoldaki mavi linkine tıklayarak  verbose analiz sürecini başlatalım. Bu aşama sembol dosyalarını online kullananlar için gene belirli bir süre alabilir.

 

Ayrıca “!analyze –vv” komutu ile detay seviyesini arttırabilirsiniz. Durmayın, deneyerek farklarını görün.

 

 

 

 

Sonunda inciler bir bir dökülmeye başladı. Çoğu bilgi kendini açıklıyor olsada işimize yarayan neler çıkarabileceğimize bir bakalım:

ATTEMPTED_SWITCH_FROM_DPC (b8)   bilgisi yani ilk eleman ve devam eden argumanlar bug check hata kodunu ve açıklamasını içermektedir. BSOD hatasının sebebi diyebiliriz.*
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT   hatanın ait olduğu genel kategoriyi göstermektedir. Benim durumumda bir sürücü problemi olduğunu anlıyoruz.
FOLLOWUP_IP ile başlayan kısımda ise hataya neden olan sorunlu modülün bilgileri mevcut.
MODULE_NAME: snapman ve IMAGE_NAME: snapman.sys bilgileri ise (her zaman birbirine benzer olmayabilir) bize en başından beri aradığımız faili göstermekte.

 

 

 

 

Sorun netleşmeye başladı. Hatalı modülü biraz açmaya çalışalım “lmvm snapman”  komutuyla yada mavi renkli snapman yazısına tıklayarak ekstra bilgi edinebiliriz.

 

 

 

 

Adı geçen dosyayı incelediğimizde Acronis Image uygulaması snapshot sürücülerinin sistemde sorun yarattığını ve bu nedenden dolayı BSOD hataları ürettiğini görüyoruz. Başladığımız noktadan oldukça ilerideyiz. Artık çözüme ulaşmak için uyumsuzluk yaratan uygulamayı güncellemeyi yada kaldırmayı deneyebiliriz.

 

Son olarak memory dump analizinde yararlanabileceğiniz ekstra komutlardan bahsetmek istiyorum:

 

lmtn  : Size hedef sistemde crash anında yüklü bütün sürücülerin bir listesini verir. lmvm ile ayrıntılarına ulaşabilirsiniz.
.time : BSOD olayının gerçekleştiği zaman bilgilerini verir.
!memusage : fiziksel bellek kullanımı ile ilgili özet bilgiler gösterir
!vm : sanal bellek kullanımı ile ilgili özet bilgiler gösterir
!analyze –show bugcheck_code : bug check koduyla ilgili ayrıntıları gösterir. Yukardaki durumda 0xb8 olacaktır.

 

Ayrıntılar için WinDbg aracı içerisinde yardım bölümüne bakmanızı öneririm, oldukça açıklayıcı ve örneklerle hazırlanmış bir klavuz oluşturulmuş.

 

*Bug Check kodlarının nedenlerini ve açıklamalarını daha ayrıntılı olarak buradaki MSDN sayfasında bulabilirsiniz.

 

Umarım sorun giderme süreçlerinde size yardımcı olabilecek bilgiler sağlayabilmişimdir. Unutmadan Çözümbank mail grubu sayesinde tanıştığım ve bu makaleyi yazmama vesile olan değerli meslektaşıma da buradan teşekkürler.