Windows Debugging 105

Baktiniz memory açisindan bir problem yok. O zaman lock lara bakalim. En temelinde farkli sistem objelerimiz vardir ve bu objelere bir anda mesela sadece bir thread bir islem yapabilir. Eger bir anda sadece ve sadece bir thread bir obje ile bir islem yapabiliyorsa buna genel olarak exclusive lock diyebiliriz. Belki ama ayni objeyi üzerinde birden fazla thread ayni anda islem yapabiliyordur, buna da shared lock deriz. Basit bakis açisi ve simdilik önemli olan bu ikisini ayirabilmektir. Örnegin bir thread bir obje ile bir islem yapiyorsa o obje lock durumdadir ve ayni obje ile çalismasi gereken baska bir thread ilk thread i beklemek durumda olur. Simdi bazen burada ilginç durumlar olusabilir. Mesela objeyi tutan thread de islemini yapabilmek için baska bir thread in tutugu baska bir lock u bekliyor olabilir. Basit bakarsak mesela karsilikli birbirini bekleyen iki thread bir deadlock durumunu olusturur. Thread ler bu durumu kendileri çözümleyemezler. Ancak gerçek hayatta durum genelde daha karisik olur, yani komplike lock senaryolari gerçeklesebilir. Dumpda da bunlari ayiklamak gerekebilir.

Lock lari dump da listelemek bir basit komutdur:

!locks

Bizim için ilginç olabilecekler Exclusively owned olanlardir.Burada threadler siralanir ve lock u tutan thread arkasinda <*> ile isaretlenmistir. Diger threadler bekleyenlerdir.

Threadler -01 eklenmis sekilde listelenir. Bu son üç haneye ihtiyacimiz yok. Örnegin 8add3a58-01 de bizi ilgilendiren 8add3a58 dir. Bu sekilde de o thread hakkinda daha net bilgi almak istiyorsak çalistiracagimiz komut budur: !thread 8add3a58

Burada Threadin stackini görebilirsiniz (asagidan yukariya ilerleyen sekilde), hangi processin oldugunu ve ne kadar zamandir çalistigi hakkinda bilgi edinebilirsiniz. Eger farkli k (kv,kd, kpn vs.) komutlarini çalistirmak isterseniz ilk önce konteksti o thread e çevirmeniz gerekir, bizim örnek ile: .thread 8add3a58

K komutlarinda bosluk birakmadan arkasina n koyarsaniz, thread stack inde frame number lari da görebilirsiniz, örnegin: kpn

Simdi de konteksti o threadin içinde bir daha belli bir frame e, yani stack de ki bir satira çevirebiliriz. Mesela 8ci satir için bu komutu girmeniz gerekir: .frame 8

Stack ile ilgili k komutlari nasil yardimci oluyorsa, framede de d komutlari (dv, du, dt vs.)yardimci olabilir.

Mesela fark ediyorsunuz ki çok sayida lock var ve direk veya baska locklar üzerinden çogunluk belli bir locku yani belli bir thread i bekliyor. Bunun hangi processin oldugu ve ne zamandir çalistigi yardimci olabilir ama belki stack de ilginç bir sey görebilirsiniz. Stack deki functioncalll arda farkli bir sürücü çalisiyordur mesela ve detaylarini bu komut ile görebilirsiniz: lmvm (LMVM)

Frame de ismi özel karaktersizdir ve bu string i lmvm komutunun bosluk birakarak arkasina koyarsiniz. Mesela Kernel de nt! Ile baslayan calllar görebilirsiniz. Bunu yapan modül hakkinda bilgi edinmek istiyorsaniz komutunuz bu sekilde olur: lmvm nt

Bu örnekte kullanilan kernel (.exe) dosyasi hakkinda detaylari görebilirsiniz.

Dump da lock görmeniz kadar normal bir sey yoktur. Ondan locklari inceleyiniz, ama illaki hata bulacaksiniz seklinde yaklasmayiniz.

 

Sözü geçen k ve d komutlari hakkinda windbg in help ini kullanin, arastirin. Simdiye kadar help e bakmadiysaniz zaman i çoktan gelmis. Bundan böyle windbg help i hep kullanacaksiniz.

Benim tavsiyem adi geçen bütün komutlarda help e hem referans hem de daha detayli bilgi için bakmaniz.

Basar Güner