Windows Debugging 104

Biraz pratik yapmanin zamani geldi. Diyelim ki donan bir sunucunuz var ve problem yasanirken sunucuyu dumpladiniz. Dumpi açtiniz ve simdi neye bakmaniz lazim?

!Analyze –v ile pek bir yere varamazsiniz. Zaten bugcheck i yaratan siz oldugunuz için nedenini biliyorsunuz.

Ilk önce bellek tarafina bakmak mantikli olabilir. Genelde x86 mimarisinde bellek sorunlari ile karsilasabilirsiniz. Bu virtual memory in mantiksal olarak 4GB a kisitli olmasindan kaynaklanir. Bildiginiz gibi Processor deki islem yapilan, registry dedigimiz belleklerin boyutu 32bit dir ve 32bit ile binary de (her hane 0 veya 1 olabilir) 2³² , yani 4GB adresleyebiliriz.

 

Bu 4GB virtual memory i sistem default da 2 ye böler. 2GB Kernel adres alanina ve 2 GB da user mode alanina. Kernel tarafinda yaklasik 512MB paged poolumuz ve 256 MB non paged poolumuz mevcuttur. Mesela /3GB switchini örnegin Windows Server 2003 de boot.ini de kullaniyorsak user mode tarafina arti 1GB verdigimiz için Kernel tarafi 1GB da yarilanir ve ayni sekilde poolarda yariya düser. Yani /3GB li bir sunucuda non paged poolumuz örnegin yaklasik 128MB düser. Hep yaklasik deniliyor çünkü poolarin boyutlari boot da hesaplaniyor (Örnegin var olan physical memory, yani RAM e göre ). Virtual memory i physical memory veya pagefile ile karistirmayin.

 Belki system event log unda srv den event 2019 veya 2020 eventleri görebilirsiniz, yani non paged, veya paged pool bitiyordur. Bunu bilmeseniz de bu komutu girdikten sonra bellek hakkinda daha net bilgi edinmis olacaksiniz:

!vm

Virtual memory usage ini gösterektir. Burada physical memoryi, kullanilan pagefile (lar), poolarin kullanimi gibi farkli bilgileri görebilirsiniz. Örnegin poollarda bir sorun var ise zaten bu sorun dökümde yer alacaktir. O zaman kimin ne kadar poolardan yedigini görmek isteyeceksinizdir.

!poolused 2 komutu ile non paged pool kullanimina göre siralanmis sekilde pool tag leri göreceksiniz, ve

!poolused 4 komutu ile paged pool kullanimina göre siralanmis sekilde ayni pool tag leri göreceksiniz.

Süpheli bir pooltag görüyorsaniz ama hangi sürücünün oldugunu bilmiyorsaniz kendisini örnegin System32 klasöründe cmd de ‘’findstr /m /l [pooltag] *.sys’’ olarak arattirabilirsiniz. Genelde pooltagler ile sürücülerin isimleri uyusur. Ondan sonraki adim genelde o sürücünün üreticicisinin sayfasinda arastirma yapmak veya hemen güncellemek olabilir. Hemen ama listenin basinda duran her seyden süphelenmeden önce düzgün çalisan bir test makinesinin farkli durumlarda (örnegin backup alirken, antivirüs scan i çalisirken, çok veri network/lokalde kopyalarken vs. ) dumpini alarak pratik yapabilirsiniz.

Genel olarak !vm size bellek tarfinda olan sorunlari gösterebilir.

Bellek tarafinda özellikle yine /3GB kullaniliyorsa basiniza gelebilecek bir problem free system page table entry lerin (PTE) bitmesi dir. PTE leri performance monitor de Memory altinda da takip edebilirsiniz. PTE ler kesinlikle 10,000 in altina düsmemeli. Daha düsük sayida çok farkli alakasiz duran problemler yasanabilir. PTE leri basitçe tanimlayacak olursak sözü geçen virtual memory ile physical memory pagefile arasindaki mapleri yapmak için kullaniriz. Örnegin bir processin belli bir bilgisini RAM de nerede bulabilecegimizi ögrenmek için. Ancak Memory Mapping çok daha genis bir konu. Yaygin olarak boot.ini ye /userva switch i eklenerek (/3GB var ise) usermode dan adreslenebilir bellek alarak, PTE lere verilen bellegi artirmamiz mümkün. Yine boot da bu switch okunur ve /userva da verilen degere göre PTE lere verilir. Her PTE 4KB lik bir kayittir, yani sadece 1 MB verecek olursaniz /userva da, 256 PTE daha elde etmis olursunuz. Userva sadece PTE lere gider, yani polarin alanlarini artiramazsiniz. Ayrica sadece /3GB ile kullanilabilir. Perfmon da kimin kaç PTE kullandigini göremezsiniz. PTE kullanimini detayli görmek istiyorsaniz ilk önce registry de

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

altinda bir DWORD yaratin, adi

TrackPtes

olsun ve degeri de 1. Reboot etmeniz lazim. Bundan sonra sisten PTE leri track edecektir ve o sistemi yine dumpladiginizda, dump da bu komut ile kullanimi görebileceksiniz:

!sysptes 4

Ayrica bir 0x0000003F mavi ekranini alirsaniz da (NO_MORE_SYSTEM_PTES) bu yöntem ile sonuca varabilirsiniz. Hat daha Registry i ayarladiktan sonra bir sonraki crash dump Bugcheck 0x000000D8, yani DRIVER_USED_EXCESSIVE_PTES olabilir. O zaman !analyze-v ile de hemen sonuca ulasabilirsiniz.

Ayni konuda son bir nokta daha var: Bugcheck 0x000000DB: DRIVER_CORRUPTED_SYSPTES crash dump i aliyorsaniz, TrackPtes degerini 3 koyun. Bir sonraki crash dump da muhtemelen Bugcheck 0x000000DA: SYSTEM_PTE_MISUSE alacaksiniz ve yine !analyze –v sizi çözüme götürecek.

Boot.ini için sözü geçen /3GB ve /userva için örnekleri mesela bu makalede bulabilirsiniz:

https://support.microsoft.com/kb/810371

Basar Güner