Merhaba,
Uzun bir aradan sonra debugging ile ilgili serime devam ediyorum. Artık dump dosyalarını nasıl inceleyeceğimize geçeceğiz. Dump Alma ( Hang Mode - I )
yazımdaki yöntemle yanıt vermeyen bir uygulamanın dump'ını aldığınızı farz ediyorum.

Start –> All Programs –> Debugging Tools for Windows(x86) –> WinDbg uygulamasını açın.
File menüsünden “Open Crash Dump” seçeneğini tıklayın. Açılan gezgin penceresinden daha önce oluşturduğunuz dmp uzantılı dosyayı bulun ve açın.
“Save information for workspace” sorusunu her zaman hayır olarak yanıtlayın.

Biraz bekledikten sonra aşağıdaki gibi bir çıktı alacaksınız :

Debugger’ın Versiyon bilgisi :
Microsoft (R) Windows Debugger Version 6.13.0003.956 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Yüklenen dump dosyasının yeri ve adı :
Loading Dump File [H:\BLOG\dumps\20101229_112225_Hang_Mode\FULLDUMP_HangMode_UITest.exe__061c_2010-12-29_11-22-28-575_158c.dmp]

Dump dosyasının tipi :
User Mini Dump File with Full Memory: Only application data is available
Comment: 'HangMode'

Sembol bilgileri :
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:

Debugging, doğru sembol dosyaları olmadan çok zor yapılabilir çünkü; nerdeyse herşeyi disassemble edilmiş koddan bulmaya çalışırsınız.
Aşağıdaki bölümlerde konuyu daha fazla ele alacağım. Şu kadarını hatırlamanız yeterli : Sembol dosyası olmadan debugging yapılmaz.

Dump’ın alındığı makina ve sistem bilgileri :
Windows 7 Version 7600 MP (2 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 6.1.7600.16385 (win7_rtm.090713-1255)
Machine Name:
Debug session time: Wed Dec 29 11:22:28.000 2010 (UTC + 2:00)
System Uptime: 6 days 18:34:10.924
Process Uptime: 0 days 0:40:35.000

Bu bilgiler işinize yarayabilir. İşletim Sisteminin sürümü, makina adı, dump'ın ne zaman alındığı. Bu bilgileri kullanarak Sistem ve Uygulama günlüklerini kontrol edebilirsiniz.
Yakın zamanda herhangi bir problem olup olmadığını denetleyebilirsiniz. Sistem ve Proses'in ne kadar zamandır çalıştığı da bir fikir verebilir. Sorunun sıklığına dair fikir edinebilirsiniz.

Sembol uyarıları ve exception bilgisi :

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(158c.14f8): Wake debugger - code 80000007 (first/second chance not available)

Debugger (invasive moddayken) process'te bir thread yaratır ve DebugBreak fonksiyonunu çağırır. Bu da process'in
breakpoint exception'ı vermesine sebep olur. Dolayısıyla hang modda alınmış dump dosyalarında 0x80000007 numaralı olayın olması normal.

Şu anda debugger context’inin set edildiği thread’in register bilgileri :

eax=00000000 ebx=0022f2bc ecx=00000000 edx=00000000 esi=00000002 edi=00000000
eip=77b300ed esp=0022f26c ebp=0022f308 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0x15:
77b300ed 83c404          add     esp,4

WinDbg ekranının sol alt köşesinde "0:000>" ibaresini göreceksiniz. Aslında bu ProcessID:ThreadID ikilisini gösterir. User mode dumplarda ProcessID hep 0 olacaktır.
Dolayısıyla gördüğünüz "0:000", bu process'in 0 numaralı thread'inde olduğunuzu ifade eder. Kernel dumplarında Process Context'ini değiştirebilirsiniz.
ProcessID:ThreadID metin kutusunun sağında yer alan metin editör kontrolünü kullanarak WinDbg'ye istediğimiz komutları yollayacağız.

İlk komutlar

Dumpı alınmış process'in kaç tane thread'i olduğuna bakalım.
0:000> yazan kısımın sağ tarfındaki textbox'ı kullanacağız.
~ yazın ve enter'a basın
Aşağıdakine benzer bir çıktı alacaksınız.

0:000> ~
.  0  Id: 158c.14f8 Suspend: 1 Teb: 7efdd000 Unfrozen
   1  Id: 158c.104c Suspend: 1 Teb: 7efda000 Unfrozen
   2  Id: 158c.a1c Suspend: 1 Teb: 7efd7000 Unfrozen

Bu çıktı bize process içinde 3 thread olduğunu gösteriyor : 0, 1 ve 2. threadler. Windbg, thread'leri 0 dan başlayarak numaralandırır. Ayrıca, gerçek numaralarını da gösterir.
Örneğin, 158c.14f8 bize thread'in 158c ProcessID'li process'in 14f8 numaralı thread'i olduğunu anlatıyor. Teb: 7efdd000 ise TEB veri yapısının adresini gösterir.

CreateThread Function ,
TEB Structure

Bir thread'in call stack'ini listelemek
Bu kez komut penceresine ( ProcessID:ThreadID metin kutusunun sağında yer alan metin editör kontrolü ) k komutunu girip enter'a basın.
Aşağıdakine benzer bir çıktı ile karşılaşacaksınız.

0:000> k
ChildEBP RetAddr 
WARNING: Stack unwind information not available. Following frames may be wrong.
0022f308 7614162d ntdll!NtWaitForMultipleObjects+0x15
0022f350 76141921 kernel32!WaitForMultipleObjectsEx+0x8e
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82
0022f3bc 61e42c6f UITest+0x1b1d
0022f3c8 61e42e51 mfc100u+0x1b2c6f
0022f3e4 61e76d36 mfc100u+0x1b2e51
0022f408 61ecc444 mfc100u+0x1e6d36
0022f458 61d0cceb mfc100u+0x23c444
0022f46c 61ecbc47 mfc100u+0x7cceb
0022f538 61ecbbba mfc100u+0x23bc47
0022f558 61eca019 mfc100u+0x23bbba
0022f5d0 61eca2a5 mfc100u+0x23a019
0022f5f4 61dc0ddb mfc100u+0x23a2a5
0022f63c 774a6238 mfc100u+0x130ddb
0022f668 774a68ea user32!gapfnScSendMessage+0x270
0022f6e0 774acd1a user32!gapfnScSendMessage+0x922
0022f724 774acd81 user32!GetWindow+0x21a
0022f748 74354e95 user32!SendMessageW+0x4c
0022f768 74354ef7 comctl32!GetEffectiveClientRect+0x306c
0022f784 74354d89 comctl32!GetEffectiveClientRect+0x30ce
0022f7e4 774a6238 comctl32!GetEffectiveClientRect+0x2f60
0022f810 774a68ea user32!gapfnScSendMessage+0x270
0022f888 774a7d31 user32!gapfnScSendMessage+0x922
0022f8e8 774a7dfa user32!LoadStringW+0x11f
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x11e
0022f938 61eced28 mfc100u+0x250ac0
0022f944 61e6c3ad mfc100u+0x23ed28
0022f99c 61d0cc9c mfc100u+0x1dc3ad
0022f9ac 61eccec5 mfc100u+0x7cc9c
0022f9c0 61eb8a28 mfc100u+0x23cec5
0022f9d8 61eb922d mfc100u+0x228a28
0022f9e4 61eb8a78 mfc100u+0x22922d
0022f9f0 61eb895d mfc100u+0x228a78
0022fa2c 61e6cae3 mfc100u+0x22895d
0022fa78 00d41197 mfc100u+0x1dcae3
0022fbfc 61ede3c3 UITest+0x1197
0022fc10 00d42425 mfc100u+0x24e3c3
0022fca4 76143677 UITest+0x2425
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0x12
0022fcf0 77b49d15 ntdll!RtlInitializeExceptionChain+0x63
0022fd08 00000000 ntdll!RtlInitializeExceptionChain+0x36

Dikkat edilmesi gerekenler :
"WARNING: Stack unwind information not available. Following frames may be wrong." mesajı bize debugger'ın sembol dosyalarını bulamadığını o yüzden
callstack'i düzgün çıkaramadığını söylüyor.

Sembol dosyalarına erişmek :

Debugger'ın, sembol dosyalarına erişimini anlatan temel makaleyi okuyabilirsiniz :
Use the Microsoft Symbol Server to obtain debug symbol files

Adım adım ayarların yapılması :
#1 Bilgisayarınızda bir dizin açın. Bu dizin debugger'ın indirdiği sembol dosyalarını tutacaktır.
Örneğin :
H:\BLOG\symbols

#2 Windbg'de "File" menüsünden "Symbol File Path" seçeneğini tıklayın. Açılan pencere içine aşağıdakileri girin :
SRV*H:\BLOG\symbols*http://msdl.microsoft.com/download/symbols

Not : Sizin lokal sembol cache dizininiz farklı olabilir. Bu durumda "H:\BLOG\symbols" yerine o dizini girin.

#3 "Reload" checkbox'ını işaretleyin ve "OK" butonuna basın.

Şimdi k komutunu tekrar çalıştırın. Bu kez oldukça farklı bir callstack göreceksiniz :

0:000> k
ChildEBP RetAddr 
0022f26c 75b30962 ntdll!ZwWaitForMultipleObjects+0x15
0022f308 7614162d KERNELBASE!WaitForMultipleObjectsEx+0x100
0022f350 76141921 kernel32!WaitForMultipleObjectsExImplementation+0xe0
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Senaryolar.dll -
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
*** ERROR: Module load completed but symbols could not be loaded for UITest.exe
WARNING: Stack unwind information not available. Following frames may be wrong.
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82
0022f3bc 61e42c6f UITest+0x1b1d
0022f3c8 61e42e51 mfc100u!_AfxDispatchCmdMsg+0x3b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]
0022f3e4 61e76d36 mfc100u!CCmdTarget::OnCmdMsg+0x124 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]
0022f408 61ecc444 mfc100u!CPropertySheet::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgprop.cpp @ 814]
0022f458 61d0cceb mfc100u!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]
0022f46c 61ecbc47 mfc100u!CDialogEx::OnCommand+0x2f [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 290]
0022f538 61ecbbba mfc100u!CWnd::OnWndMsg+0x66 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]
0022f558 61eca019 mfc100u!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]
0022f5d0 61eca2a5 mfc100u!AfxCallWndProc+0xb5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]
0022f5f4 61dc0ddb mfc100u!AfxWndProc+0x37 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]
0022f634 774a6901 mfc100u!AfxWndProcBase+0x56 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 420]
0022f6e0 774acd1a user32!UserCallWinProcCheckWow+0x120
0022f724 774acd81 user32!SendMessageWorker+0x581
0022f748 74354e95 user32!SendMessageW+0x7f
0022f768 74354ef7 comctl32!Button_NotifyParent+0x3d
0022f784 74354d89 comctl32!Button_ReleaseCapture+0x113
0022f7e4 774a6238 comctl32!Button_WndProc+0xa18
0022f810 774a68ea user32!InternalCallWinProc+0x23
0022f888 774a7d31 user32!UserCallWinProcCheckWow+0x109
0022f8e8 774a7dfa user32!DispatchMessageWorker+0x3bc
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x5f6
0022f938 61eced28 mfc100u!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]
0022f944 61e6c3ad mfc100u!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]
0022f99c 61d0cc9c mfc100u!CDialog::PreTranslateMessage+0xcf [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 82]
0022f9ac 61eccec5 mfc100u!CDialogEx::PreTranslateMessage+0x29 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 275]
0022f9c0 61eb8a28 mfc100u!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]
0022f9d8 61eb922d mfc100u!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]
0022f9e4 61eb8a78 mfc100u!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]
0022f9f0 61eb895d mfc100u!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]
0022fa00 61ecedfd mfc100u!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]
0022fa2c 61e6cae3 mfc100u!CWnd::RunModalLoop+0xc8 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]
0022fa78 00d41197 mfc100u!CDialog::DoModal+0x12d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]
0022fbfc 61ede3c3 UITest+0x1197
0022fc10 00d42425 mfc100u!AfxWinMain+0x49 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
0022fca4 76143677 UITest+0x2425
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0xe
0022fcf0 77b49d15 ntdll!__RtlUserThreadStart+0x70
0022fd08 00000000 ntdll!_RtlUserThreadStart+0x1b

1. adımda açtığınız dizine bakarsanız bir çok alt dizinle dolduğunu göreceksiniz.

H:\BLOG\symbols>dir
Volume in drive H is TOSHIBA
Volume Serial Number is 4504-0DA4

Directory of H:\BLOG\symbols

29.12.2010  16:50    <DIR>          .
29.12.2010  16:50    <DIR>          ..
29.12.2010  16:53    <DIR>          wntdll.pdb
29.12.2010  16:53                 0 pingme.txt
29.12.2010  16:53    <DIR>          wkernelbase.pdb
29.12.2010  16:54    <DIR>          wkernel32.pdb
29.12.2010  16:54    <DIR>          mfc100u.i386.pdb
29.12.2010  16:54    <DIR>          wuser32.pdb
29.12.2010  16:54    <DIR>          comctl32.pdb
               1 File(s)              0 bytes
               8 Dir(s)  11.803.426.816 bytes free

Yukarıdaki callstack'e baktığınızda debugger'ın, UITest.exe ve senaryolar.dll modüllerinin sembol dosyalarını bulamadığını görüyoruz.
Aslında, işletim sistemi ile gelen ve Microsoft'tan satın alınmış ürünlerin sembol dosyaları indirilecektir. Sizin, debugger'a diğer modüllerin sembol dosyalarını
nereden bulabileceğini belirtmeniz gerekir. Bunun için yine Windbg'de, "File" menüsünden "Symbol File Path" seçeneğini tıklayın. Varolan ifadenin sonuna noltalı virgül
ekleyin ve sembol dosyalarının bulunduğu dizini girin. Örneğin, benim için bu :
H:\BLOG\DebugSenaryolari\Release dizini. Ve, sembol path ifadem de aşağıdaki gibi olacaktır :
SRV*H:\BLOG\symbols*http://msdl.microsoft.com/download/symbols;H:\BLOG\DebugSenaryolari\Release

"Reload" checkbox'ını işaretleyin ve "OK" butonuna basın. Bir kez daha k komutunu çalıştırın. Bu kez tüm modüllerin sembol dosyasına ulaşılmış olunmalı :

0:000> k
ChildEBP RetAddr 
0022f26c 75b30962 ntdll!ZwWaitForMultipleObjects+0x15
0022f308 7614162d KERNELBASE!WaitForMultipleObjectsEx+0x100
0022f350 76141921 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0022f36c 65aa10e2 kernel32!WaitForMultipleObjects+0x18
0022f3b0 00d41b1d Senaryolar!DeadLockDurumuYarat+0x82 [d:\work\blog\debugsenaryolari\senaryolar\aski.cpp @ 40]
0022f3bc 61e42c6f UITest!CUITestDlg::OnBnClickedButtonDeadlock+0xd [d:\work\blog\debugsenaryolari\uitest\uitestdlg.cpp @ 168]
0022f3c8 61e42e51 mfc100u!_AfxDispatchCmdMsg+0x3b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 82]
0022f3e4 61e76d36 mfc100u!CCmdTarget::OnCmdMsg+0x124 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 381]
0022f408 61ecc444 mfc100u!CPropertySheet::OnCmdMsg+0x1d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgprop.cpp @ 814]
0022f458 61d0cceb mfc100u!CWnd::OnCommand+0x92 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2675]
0022f46c 61ecbc47 mfc100u!CDialogEx::OnCommand+0x2f [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 290]
0022f538 61ecbbba mfc100u!CWnd::OnWndMsg+0x66 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2081]
0022f558 61eca019 mfc100u!CWnd::WindowProc+0x24 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2067]
0022f5d0 61eca2a5 mfc100u!AfxCallWndProc+0xb5 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 248]
0022f5f4 61dc0ddb mfc100u!AfxWndProc+0x37 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 410]
0022f634 774a6901 mfc100u!AfxWndProcBase+0x56 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxstate.cpp @ 420]
0022f6e0 774acd1a user32!UserCallWinProcCheckWow+0x120
0022f724 774acd81 user32!SendMessageWorker+0x581
0022f748 74354e95 user32!SendMessageW+0x7f
0022f768 74354ef7 comctl32!Button_NotifyParent+0x3d
0022f784 74354d89 comctl32!Button_ReleaseCapture+0x113
0022f7e4 774a6238 comctl32!Button_WndProc+0xa18
0022f810 774a68ea user32!InternalCallWinProc+0x23
0022f888 774a7d31 user32!UserCallWinProcCheckWow+0x109
0022f8e8 774a7dfa user32!DispatchMessageWorker+0x3bc
0022f8f8 774c2292 user32!DispatchMessageW+0xf
0022f924 61ee0ac0 user32!IsDialogMessageW+0x5f6
0022f938 61eced28 mfc100u!CWnd::IsDialogMessageW+0x32 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 197]
0022f944 61e6c3ad mfc100u!CWnd::PreTranslateInput+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4659]
0022f99c 61d0cc9c mfc100u!CDialog::PreTranslateMessage+0xcf [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 82]
0022f9ac 61eccec5 mfc100u!CDialogEx::PreTranslateMessage+0x29 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxdialogex.cpp @ 275]
0022f9c0 61eb8a28 mfc100u!CWnd::WalkPreTranslateTree+0x23 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3258]
0022f9d8 61eb922d mfc100u!AfxInternalPreTranslateMessage+0x41 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]
0022f9e4 61eb8a78 mfc100u!CWinThread::PreTranslateMessage+0xd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]
0022f9f0 61eb895d mfc100u!AfxPreTranslateMessage+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]
0022fa00 61ecedfd mfc100u!AfxInternalPumpMessage+0x2d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]
0022fa2c 61e6cae3 mfc100u!CWnd::RunModalLoop+0xc8 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4714]
0022fa78 00d41197 mfc100u!CDialog::DoModal+0x12d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 638]
0022fbfc 61ede3c3 UITest!CUITestApp::InitInstance+0xf7 [d:\work\blog\debugsenaryolari\uitest\uitest.cpp @ 72]
0022fc10 00d42425 mfc100u!AfxWinMain+0x49 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 37]
0022fca4 76143677 UITest!__tmainCRTStartup+0x158 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547]
0022fcb0 77b49d42 kernel32!BaseThreadInitThunk+0xe
0022fcf0 77b49d15 ntdll!__RtlUserThreadStart+0x70
0022fd08 00000000 ntdll!_RtlUserThreadStart+0x1b

Yazıyı fazla uzatmadan tadında bırakalım. Gelecek yazılarımda sembol dosyaları ve sembol ayarları konusunu detaylandıracağım.
Bu arada debugging ile ilgili internette bir çok kaynak mevcut. Ancak, en temel ve yaralı kaynak "Debugging Tools for Windows"un help uygulamasıdır.

Hoşçakalın
-faik

“Ani ölüm” durumundaki sorun da tam olarak bu esasında. Uygulama çalışmaya başladıktan bir süre sonra hata alıp kapansaydı geçen yazıdaki
adımları uygulayabilirdik. Ancak, “ani ölümlerde” debugger’ı uygulamaya bağlayacak kadar dahi zaman olmaz.

Çözüm : IFEO ( Image File Execution Options ),
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

İşletim Sistemi, bir uygulamayı çalıştırırken bu Kayıt Defteri Anahtarını (KDA = registry key) muhakkak okur ve çalıştıracağı uygulama ile
aynı adlı bir subkey olup olmadığını kontrol eder. Varsa eğer bu key’e ait kayıt defteri değerlerini (registry values) sorgular ve ona göre aksiyon alır.
Örneğin, debugger değeri içinde yer alan uygulama çalıştırılır.

Artık AniÖlüm.exe uygulamasını her çalıştırdığınızda cdb.exe de çalışacak ve AniÖlüm.exe her exception ürettiğinde c:\dumps
dizini altına dump dosyası üretecek. Şimdi bunun denemesini yapalım. AniÖlüm.exe uygulamasını çalıştırın ve c:\dumps dizininin içine bakın.
Aşağıdaki dosyaları görmeniz gerekir (sizde dosya isimleri farklı ama aynı formatta olacaktır).

Hoşçakalın

-faik

AniÖlüm.zip

Merhaba,

Artık dump alma ile ilgili temel adımlara alıştığınızı umuyorum. Bu kez exception oluşturan uygulamaların dump’larının nasıl alınabileceğine değineceğim.

"Dump Alma ( Hang Mode - I )" makalesindeki UITest.exe’yi kullanacağız. Uygulamayı çalıştıralım ve “AccessViolation” butonuna basalım. İşletim sistemi, versiyonuna bağlı olarak bir takım kurtarma girişimlerinde bulunabilir, size seçenekler sunabilir. Ama, sonuçta uygulama kapanacaktır :

1st/2nd Chance Exception

Olanları şöyle özetleyebiliriz :

#1 Exception throw edilir ve İşletim Sistemi uygulamaya exception’ı handle edip edemeyeceğini sorar. Bu durumu “1st chance exception” olarak da adlandırıyoruz. Eğer uygulamaya bir debugger bağlı ise o zaman debugger bir dump alabilir. Eğer debugger adplus ile çalıştırılmışsa cdb.exe, bir minidump (aşağıda anlatacağım) dosyası üretir. Exception durumlarında debugger’ların ne yapabileceklerini özelleştirebilirsiniz. Dolayısıyla, debugger istediğiniz başka bir eylemi de gerçekleştirebilir. Örneğin, aslında adplus, cdb.exe’nin sadece minidump oluşturmasını değil aynı zamanda log dosyasına da exception’la ilgili bilgiler yazmasını sağlar.

#2 Uygulama exception’ı handle edebiliyorsa kontrol uygulamada kalır ve uygulamaya çalışmaya devam eder.

#3 Eğer uygulama exception’ı handle edemezse o zaman işletim sistemi uygulamayı kapatmaya karar verir. Bu duruma da “2nd chance exception” denir. Aynı şekilde, eğer bir debugger uygulamaya bağlı ise debugger istenen eylemi gerçekleştirecektir. Örneğin, adplus ile çalıştırılmış cdb.exe bu durumda bir fulldump dosyası üretecektir. Sonra da uygulama kapanır. Aslında, bu aşamada bir dump daha yazılır. O da “1st chance process shutdown” exception’ından kaynaklanan dumptır.

Adım adım crash dump alma

#1 UITest.exe uygulamasını çalıştırın.

#2 Elevated ( Run as Administrator ) bir komut satırı açalım.

#3 “C:\Program Files\Debugging Tools for Windows (x86)” dizinine geçelim.

#4 Aşağıdaki komutu yazıp çalıştıralım :

Adplus -crash -pn UITest.exe -o c:\dumps -quiet

Komut çalışınca aşağıdaki gibi bir yazı görebilirsiniz. “quiet” modda çalıştırdığımız için sembol dizini uyarısı komut satırına yazılıyor. Sonra da debugger’ın uygulamaya başarıyla bağlandığı belirtiliyor.

#5 Taskbar’da minimized olarak cdb.exe’nin çalışmaya başladığını göreceksiniz. Hatırlarsanız hang mod dump alırken bu uygulama kısa bir süre gözüküyordu sonra da kapanıyordu. Artık uygulama kapanana kadar cdb.exe de açık kalacak. Cdb.exe’yi maximize ederseniz aşağıdaki gibi yazıların olduğu bir komut satırı göreceksiniz :

#6 Şimdi “AccessViolation” butonuna basın. Cdb.exe ve UITest.exe uygulamalarının kapanmasını bekleyin.

#7 c:\dumps dizinine bakın. İçinde adı “Crash_Mode__Date_05-12-2010__Time_15-26-0505” e benzer bir dizin oluştuğunu göreceksiniz. Bu dizinlerin debugger tarafından açıldığını biliyoruz. Hang mod dump alırken de benzer formatlı isimlerin olduğu dizinlerin yaratıldığını görmüştük.

Şimdi bu dizinin içine bakalım. Aynı tipte log dosyalarının olduğunu göreceksiniz. Ancak hang moddan farklı olarak 3 tane “dmp” uzantılı dosya olduğunu göreceksiniz.

PID-4376__UITEST.EXE__1st_chance_AccessViolation__mini_1760_2010-05-12_15-31-56-867_1118.dmp

PID-4376__UITEST.EXE__2nd_chance_AccessViolation__full_1760_2010-05-12_15-31-57-101_1118.dmp

PID-4376__UITEST.EXE__1st_chance_Process_Shut_Down__full_1760_2010-05-12_15-32-06-054_1118.dmp

İsimlere dikkat ederseniz, “1st chance” “2nd chance” ve “full”/”mini” sözcüklerinin kullanıldığını göreceksiniz. 1st/2nd chance’ten sonra exception’nın tipi de yazılacaktır. Bizim örneğimiz “AccessViolation” exception’ı olduğu için “_AccessViolation_” sözcüğü eklenmiş.

Meraklısına not : Henüz dmp dosyalarını incelemeye başlamadık. Ancak, nelerle uğraşacağımızı merak ediyorsanız “PID-XXXX__UITEST.EXE__Date_MM-DD-YYYY__Time_HH-MM-SEC.log” dosyasını inceleyebilirsiniz.

Exception üreten ancak kapanmayan uygulamalar

Aslında neredeyse tüm uygulamalar bu sınıfa girer çünkü; büyük olasılıkla çalıştıkları süre zarfında bir exception’la karşılaşabilirler. Exception handle edilebiliyorsa sorun yok. Uygulama çalışmaya devam eder. Duruma göre throw edilen bu exception’nın önemi olabilir ve biz de bu anda bir dump almak isteyebiliriz.

Bir deneme yapmak için yukarıdaki tüm adımları tekrarlayın. Sadece 6. adımda “AccessViolation Handled” butonuna basın. Sadece bir “1st chance access violation” minidump dosyası oluştuğunu göreceksiniz.

Minidump/FullDump dosyaları

Fulldump : Uygulamanın kullandığı tüm sanal bellek alanı, yüklenmiş tüm modülleri, handle tablosunu içerir.

Minidump : Bu kadar çok bilgiyi içermez, sadece threadlerin callstack’lerini ve yüklenmiş modüllerle ilgili bir takım bilgileri barındırır.

Hoşçakalın

-faik

Merhaba,

Geçen sefer yanıt vermeyen ve işlemci zamanını az kullanan uygulamadan nasıl dump alınacağına değinmiştim. Bu kez yanıt vermeyen ancak işlemci zamanını çok kullanan bir uygulamadan nasıl dump alınabileceğini anlatacağım.

İlk yazımda belirttiğim gibi uygulama yanıt vermez durumu gelince yapmamız gereken ne kadar işlemci zamanı kullandığına göz atmak olmalı.

Geçen yazıda yayınladığım UITest.exe uygulamasını açın ve “Yüksek İşlemci” butonuna basın.

Sonra, UITest.exe uygulamasını tutup çekmeye çalışın. Bir kez daha UITest.exe’nin başlığına “Not Responding” açıklamasının eklendiğini göreceğiz.

Görev Yöneticisini açın ve “Processes (işlemler)” sekmesinden “UITest.exe” uygulamasını bulun ve CPU kolonundaki değeri kontrol edin. Görmenizi beklediğim değer en az 100 / İşlemciSayısı dır.

Örneğin, bir işlemciniz varsa 100, ikiyse 50, gibi. İleride dump analizini tartıştığımızda nedenlerini daha ayrıntılı göreceğiz.

UITest.exe uygulamasını sonlandırmadığınız sürece bu seviyedeki işlemci kullanımı devam edecektir.

Bu tip durumlarda uyguladığımız bir yöntem var : Birden fazla defa hang mode dump almak. Bu yöntemin arkasında yatan düşünce alınan dump dosyalarını karşılaştırıp hangi fonksiyonun bu soruna neden olduğunu görebilmek. Bu yöntemin başarısı, işlemci kullanımının yüksek olduğu süre ve alınan dump sayısı ile bağlantılıdır.

Eğer işlemci kullanımı -UITest.exe örneğinde olduğu gibi- uygulama kapanana kadar yüksek devam ediyorsa bu durumda peşpeşe alınacak 4 dump yararlı olacaktır. Çünkü; genellikle sebep sonsuz döngüdür. Dumplarda callstack’lerin ortak fonksiyonlarını inceleyeceğiz.

Öte yandan, yanıt vermeme durumu belli bir süre devam ediyorsa ve sonra uygulama normal çalışmasına devam ediyorsa bu yönetimin başarı şansı düşecektir. Çünkü; bu tip yüksek işlemci sıçramalarının sebebi çoğunlukla artan istek sayısıdır. Bu durumda alacağımız dumplar arasında ortak callstack’ler bulamayabiliriz bile.

Şimdi adımları bir kez birlikte gözden geçirelim :

#1 Uygulamanın tepkisiz ve çok işlemci zamanı kullandığından emin olalım.

#2 Elevated ( Run as Administrator ) bir komut satırı açalım.

#3 “C:\Program Files\Debugging Tools for Windows (x86)” dizinine geçelim.

#4 Aşağıdaki komutu yazıp çalıştıralım :

adplus -hang -pn UITest.exe -o c:\dumps -quiet

Komut çalışınca aşağıdaki gibi bir yazı görebilirsiniz. “quiet” modda çalıştırdığımız için sembol dizini uyarısı komut satırına yazılıyor. Sonra da debugger’ın uygulamaya başarıyla bağlandığı belirtiliyor.

#5 Komutu çalıştırdığınız anda taskbar’da kısa süreliğine “cdb.exe“ adlı bir programın açılıp kapandığını göreceksiniz. Cdb.exe kapandıktan sonra 4. Adımı tekrarlayın. Bu yüntemle 4 kez dump oluşturun.

#6 İşlem bittikten sonra c:\dump dizinine gidin. 4 yeni dizin oluşturulduğunu göreceksiniz. Hatırlarsanız her dizinin içeriğini geçen yazıda gözden geçirmiştik.

Gelecek yazımda crash mod dump almaktan bahsedeceğim.

Hoşçakalın

-faik

İçinde UITest.exe ve senaryolar.dll adlı iki dosya bulunuyor. UITest.exe uygulamasını kullanarak sorunlu durumları yaratacağız ve geçen yazıda kurduğumuz

“Debugging Tools for Windows” araçlarıyla da dump dosyalarını üreteceğiz.

Hatayı gidermek için VC++ 2010 x86 Çalışma Zamanı Kütüphanelerini ( Runtime Libraries ) kurun. Kurulum dosyalarına aşağıdaki adresten ulaşabilirsiniz :

Microsoft Visual C++ 2010 Redistributable Package (x86)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84

İşletim sisteminizin kaç bit olduğu önemli değil. Uygulama 32-bit olduğu için x86 paketini kurmanız yeterli olacaktır.

Kurulum tamamlandıktan sonra UITest.exe uygulamasını çalıştırdığınızda aşağıdaki formu göreceksiniz :

Hatırlarsanız, ilk yazımda sorunları 2 ana gruba ayırmıştım ve bu durumlarda ne çeşit dump dosyaları üretilmesi gerektiğini anlatmıştım.

#1 Yanıt Vermeyen uygulamalar : Hang dump

#2 Hata sonucunda kapanan uygulamalar : Crash Dump

UITest.exe uygulamasını kısaca anlattıktan sonra konuştuklarımızı hayata geçirelim :

# “Deadlock”, “Orphant CriticalSection”, “Yüksek İşlemci” uygulamayı yanıt vermez hale getirecek işlemleri başlatan butonlar.

# “AccessViolation” ve “Stackoverflow” faktöriyel 11 ve yukarısı değerler için uygulamanın kapanmasına yol açar.

# “AccessViolation Handled”, uygulamanın “Access Violation” exception’ını üretmesine yol açar ancak uygulama kapanmaz.

Not : Bu deyimlerin doğru Türkçe karşılıklarını bulamadım. Uygun karşılıklar biliyorsanız bana bildirirseniz sevinirim.

 ADPlus.vbs

“C:\Program Files\Debugging Tools for Windows (x86)” dizininde adplus.vbs adlı bir VBScript dosyası bulunmaktadır. Bu script, cdb.exe

adlı debugger uygulamasını verdiğimiz parametrelere göre çalıştırır. Dump almak için en sık kullanacağınız araçlardan olacaktır. 
 

Sık kullanacağınız parametreler :

Bir defada hang ve crash parametrelerinden sadece birini kullanabilirsiniz.

"-p" ve "-pn" parametrelerini birlikte ve istediğiniz kadar kullanabilirsiniz. Dolayısıyla bir komutla birden fazla uygulamanın dump'ını aynı anda alabilirsiniz.

Adplus scriptini çalıştırırken “-quiet” parametresini kullanmadıysanız 4 uyarı/bilgi mesajı alabilirsiniz.

Cscript’i default script çalıştırıcısı yapmak isteyip istemediğinizin sorulması :

CScript’in varsayılan script çalıştırıcısı olup olmaması tamamen size kalmış bir tercih. Ben herhangi bir değişikliğe neden olmamak için bu adımda “Hayır/No” yu seçiyorum. No’yu seçerseniz gelebilecek uyarı :

Sembol ( daha sonraki yazılarda değineceğiz ) dizininin tanımsız olduğunu belirten uyarı :

Hang modda dump alma

1. Bir komut satırı açın ve “C:\Program Files\Debugging Tools for Windows (x86)” dizinine geçin.

ÖNEMLİ : Eğer Windows Vista ve sonrası bir işletim sistemi kullanıyorsanız elevated privilege olan bir komut satırı kullanın. Diğer bir bir değişle, komut satırını Administrator olarak çalıştırın.

2. Eğer henüz çalıştırmadıysanız UITest.exe uygulamasını başlatın.

3. “Deadlock” isimli butona basın.

4. 2-3 saniye kadar bekleyin sonra uygulamayı sağa sola çekmeğe çalışın. Başlığa “(Not Responding)” ibaresinin eklendiğini göreceksiniz.

5. c:\ sürücüsünde ( veya size uygun gelen başka bir sürücüde ) yeni bir dizin açın. C:\dumps adlı bir dizin açtığınızı farzediyorum.

6. Komut satırına geri dönün ve aşağıdaki komudu çalıştırın :

Adplus -hang -pn UITest.exe -o c:\dumps –quiet

İşlem 1-2 saniye içinde tamamlanacaktır.

7. Dump alma tamamlandıktan sonra UITest.exe’nin kapanmadığını, hala açık olduğunu göreceksiniz. Bu daha önce belirttiğimiz “hang” çalışma biçimidir. İsterseniz Görev Yöneticisi’ndeki ( Task Manager ) process sekmesinden cdb.exe ve cscript.exe olup olmadığını da kontrol edebilirsiniz. Bu da hang mod davranışının gereği. Debugger dump dosyasını ürettikten sonra kapanır.

8. Şimdi c:\dumps dizinine bakalım. ”c:\dumps”ın altına yeni bir dizin yaratıldığını göreceksiniz. Dizin adının şöyle bir formatı olacak : Hang_Mode__Date_AY-GÜN-YIL__Time_Saat-Dakika-SaniyeSalise

Bu dizinin altında bir dizin daha göreceksiniz : CDBScripts. CDBScripts dizini içinde PID-UygulamanınProcessIDsi__UITEST.EXE.cfg adlı bir dosya göreceksiniz. Bu dosya adplus scriptinin çalışmasıyla ilgili bir takım bilgi ve parametreleri içerir. Hang_Mode__Date_AY-GÜN-YIL__Time_Saat-Dakika-SaniyeSalise isim formatındaki bir üst dizine geri dönelim.

Burada 4 tane dosya göreceksiniz. Dosya isimleri sizde tarih,saat ve ProcessID’leri farklı olacağı için aynı olmayacaktır ancak isimlerin formatı aynı kalacak.

Artık uygulamanın “yanıt vermez” durumdan çıkamayacağını varsayıyoruz. O yüzden uygulamayı (ALT+F4, Görev Yöneticisinden, vs) sonlandırabiliriz.

Dikkat ettiyseniz UITest.exe uygulamasının işlemci kullanımını hiç denetlemedik. İsterseniz UITest.exe’yi tekrar çalıştırın. “Deadlock” ve “Orphant CriticalSection” butonlarına basın ve uygulamanın işlemci kullanımını task manager veya performance monitor’den takip edin. Bakalım ne sonuç bulacaksınız?

"Orphant CriticalSection” butonunu denerken yukarıdaki adımları tekrarlayarak UITest.exe uygulamasının dump’ını bir kez daha alın.

Gelecek yazımda işlemci zamanı tüketen ve “yanıt vermez” durumdaki uygulamanın dump’ını almaktan bahsedeceğim.

Hoşçakalın
-faik

UITest.zip

Geçen yazımda uygulamaların gösterdiği beklenmedik davranışlar, debugger, dump dosyaları, dump dosyası üretme kavramlarına değinmiştim. Bu yazımda debugger’ın nasıl kurulduğunu, nelere dikkat etmek gerektiğini anlatacağım.

Debugger’ın 3 farklı için platform versiyonu vardır :

i.                     X86, 32-bit debugger. Hem x86 hem de x64 sistemlere kurulabilir.

ii.                   X64, 64-bit debugger. Sadece x64 tabanlı sistemlere kurulabilir.

iii.                  IA64, 64-bit debugger. Sadece Itanium tabanlı sistemlere kurulabilir.

Itanium tabanlı sistemleri çok nadir kullanıldıkları için kapsama dahil etmeyeceğiz.

Pekiyi hangi versiyonu kurmalıyım ?

Burada önemli olan işletim sisteminin kaç bit olduğu değil uygulamanın kaç bit olduğudur. Aşağıdaki tablo bir referans olabilir.

X64 bir sisteme hem 64bit hem de 32bit debugger kurabilirsiniz.

Debugger paketinin adı “Debugging Tools for Windows" olarak geçiyor. Ana sayfası :

Debugging Tools for Windows - Overview

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Bu sayfanın içinden 32 bit ve 64 bit paketlerin indirilebileceği sayfalara ait linkler de bulunmaktadır :

Install Debugging Tools for Windows 32-bit Version

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#a

Install Debugging Tools for Windows 64-bit Version

http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx#

Her iki sayfanın altlarına doğru “Previous Versions” linkleri bulunmaktadır. Eğer buradan indirirseniz tek başına “Debugging Tools for Windows” paketini indirirsiniz. Yakın zamanda bu değişti ve debugger Windows SDK ve Driver Development Kit’in içine alındı.

Merak etmeyin sadece debugger kurmak için bu büyük kit’leri indirmenize gerek yok. Şu adımları izleyebilirsiniz :

Windows SDK'sı içinden Debugger paketini kurmak

#8 Kurulum yapılacak dizini belirleyin.

#9 Esas dikkat edilmesi gereken adım budur! 

Bilgisayar kullanırken kimi zaman kullandığımız uygulamalar beklenmedik davranışlar gösterirler. Bu davranışları iki gruba ayırabiliriz :

#1 Uygulama bir hata ile karşılaşır. Bu durumda ya kapanır ya da uyarı verir ve çalışmaya devam eder.

#2 Uygulama cevap veremez hale gelir.

Uygulamadan kastedilen tüm komut satırı uygulamaları, servisler ve GUI uygulamalarıdır. Uygulamanın .net tabanlı olup olmaması veya hangi programlama dilinde geliştirildiğinin bir önemi yok.

Beklenmeyen davranışın sebebini bulmak için kullanabileceğimiz güçlü bir araç mevcut : Debugger (hata ayıklayıcı). Debugger’ın yaptığı çalışan uygulamanın içine bakmamızı sağlamak. İsterseniz debugger’ı röntgen cihazı gibi de düşünebilirsiniz. Debugger, sorunlu uygulamaya bağlanabilir ve sizin bu uygulamayı incelemenizi sağlar. Tabii, akla gelen soru “Production/live (üretim/canlı) ortamlarında kimin bunu yapma şansı olabilir?” dir. Genellikle de yanıt “kimsenin” olacaktır. İşte tam bu noktada debugger’ın çok sık kullanacağımız bir özelliğinden bahsedebiliriz : dump dosyası  üretmek.

Dump dosyası, uygulamanın kullandığı bellek alanlarını, işlemci içeriğini ve işletim sisteminde tutulan bir takım bilgileri barındırır. Dump dosyası, debugger ile açılabilir. Dolayısıyla dump’ın alındığı anda uygulamanın durumunu daha sonra incelemek mümkün.

Debugger, nasıl başlatıldığına bağlı olarak aşağıdaki durumlarda dump dosyası üretebilir :

#1 Eğer debugger exception durumlarında dump dosyası üretmeye ayarlandıysa debugger uygulamaya bağlandığı andan itibaren onu takip eder ve bir exception olduğunda bir dump dosyası üretir. Debugger uygulama kapanana kadar çalışır ve ona bağlı kalır. Buna “Crash Mode” dump alma denir. “Crash Mode”dan kasıt mutlaka uygulamanın bir exception sonucu kapanması değildir. Her exception üretildiğinde dump alınmasıdır. Maalesef, “crash” sözcüğü bu karışıklığa yol açıyor.

#2 Diğer bir çalıştırma yöntemi ise debugger’in uygulamaya bağlanması ve o anki bilgileri dump dosyasına kaydetmesi, akabinde bağlantıyı kesip, kapanmasıdır. Uygulama çalışmaya devam eder. Debugger’ın bu tip çalıştırılmasına “Hang Mode” denir. Maalesef burada da “hang” sözcüğü farklı bir algıya yol açıyor. Debugger, uygulamanın ne zaman “hang” olduğunu ( cevap vermediğini ) takip etmez, fark edemez, sadece çalıştırıldığı o andaki uygulamanın durumunu kaydeder.

Sanıyorum, ilk yöntem “exception” ikincisi de “snapshot” mode olarak anılsaydı daha doğru olurdu.

Üretilen bu dosyalarla ilgili hiç unutulmaması gereken bir nokta var : Dump dosyası uygulamanın “o ana ait” durumunu gösterir, ne bir cycle önce ne de bir cycle sonra :) Yani süreğen bir bilgi barındırmaz. Bu varsayımdan yola çıkarak hangi tip sorunlu durumda debugger’ı hangi halde başlatıp (crash/hang) kaç tane dump dosyasına ihtiyacımız olduğunu belirleyeceğiz.

Beklenilmeyen durumları tekrar gözden geçirelim :

Hata alınan durumlar

#1 Uygulama bir süre düzgün şekilde çalışıyor ancak herhangi bir anda “Beklenmeyen hata oluştu” gibi bir mesaj çıkıyor ve “tamam”a bastığınızda uygulama kapanıyor. Ya da bu uyarı dahi çıkmıyor ve uygulama kapanıyor.

Nasıl dump dosyası toplanır ?

Yapılması gereken uygulama çalışmaya başladıktan sonra debugger’ı “crash” modda çalıştırmak ve uygulama beklenmedik şekilde kapanana kadar beklemek. Amacımız hangi exception’ndan ötürü uygulamanın kapandığını anlamak. Daha sonra dump dosyası içinde exception'a yol açan call stack'i inceleyeceğiz.

#2 Uygulama bir süre düzgün çalışıyor. Ancak, belli bir işlevi çalıştırmak istediğinizde size hata mesajı döndürüyor. Mesajı kapattığınızda uygulama kapanmıyor ve geri kalan işlevler beklendiği gibi çalışmaya devam ediyor.

Nasıl dump dosyası toplanır ?

Hata mesajının gösterildiği anda debugger’i “hang” modda çalıştırmak. Amacımız MessageBox’ı gösteren call stack’i bulmak olacaktır. Buradaki ümidimiz mesaja yol açan fonksiyonların callstack'te hala mevcut olmaları.

#3 Uygulama çalıştıktan bir süre sonra yetersiz kaynaklarla ilgili mesajlar verir veya sistem/uygulama günlüklerine kayıt atmaya başlar. Kimi zaman uygulama kapanmaz ancak kesinlikle beklendiği gibi de davranmaz.

Nasıl dump dosyası alınır?

Bu kez soruya soruyla yanıt vereceğiz. Yapmamız gereken ilk şey dump almak mıdır ? Hayır! Öncelikle hangi kaynağın kullanılıp geri verilmediğini anlamalıyız. Örneğin, artan, uygulamanın sanal bellek alanı mıdır, yoksa işletim sistemi nesneleri ( dosya, thread, vs ) midir? Bunların yanıtı önce task manager’dan bu tip değerleri kontrol etmek, daha sonra uygulamanın çalışmaya başladığı andan itibaren sorun çıkarmaya başladığı zamana kadar performans sayaçları ile log toplayıp bir artış trendi gözlemlemeye çalışmaktır. Eğer bunları yapmaya fırsatımız olmadıysa o zaman bir hang dump almak işe yarayabilir. Elbette, bu dump dosyası büyük ihtimalle sadece neyin fazla kullanıldığını gösterecektir. Buna neden olan sebebi göstermeyecektir. Teorik olarak bir dump’tan sebebi öğrenme ihtimali de var ancak bunun için gerçekten şanslı olmalısınız ve uygulamanın kaynak kodunu yakından tanımalısınız.

Uygulamanın yanıt veremez hale gelmesi

Bu tip durumlarda yanıtlanması gereken iki soru var :

#1 Uygulamanın işlemci kullanımı ne düzeyde?

#2 Yanıt vermeme durumu ne kadar sürüyor?

Eğer işlemci kullanımı yüksek ( örneğin uygulama en az bir işlemcinin tamamını kullanıyorsa > %90 ) ve bu durum bir kez başladı mı uygulama kapanana kadar devam ediyorsa o zaman birer dakika arayla 3 kez “hang” mode dump almak gerekir. Bu durumlar genellikle uygulamanın sonsuz bir döngüye girmesinden kaynaklanır. Dump dosyalarında aynı thread’lere ait callstack’lerdeki ortak payda aranacaktır.

Eğer uygulamanın, işlemci kullanımı yüksek ve bu durum belirli bir süre devam ediyorsa ve sonra işlemci kullanımı normal oranlarına geri dönüyorsa mümkün olduğunca çok dump dosyası toplamak isabetli olacaktır. Eşit aralıklarla 4 tane dump almak iyi bir başlangıçtır. Ancak, bu durumlarda ( anlık yükseliş ) sadece dump dosyalarının içeriği yeterli olmayacaktır. Performans monitor yardımıyla sistemde diğer yükselen değerleri de gözlemlemek gerekir. Örneğin, disk I/O'su da artıyor mu? Sisteme gelen istek sayısında bir artış var mı? Çünkü; genellikle bu durum birim zaman içindeki istek sayısının artmasından kaynaklanır.

Eğer uygulamanın, işlemci kullanımı düşük ( neredeyse 0 ) ve bu durum uygulama kapanana kadar devam ediyorsa ve uygulama hiçbir isteğeye yanıt vermiyorsa o zaman bir kez “hang” dump almak yeterlidir. Bu tip durumlar, genellikle sonsuz bir bekleyişten kaynaklanır. Dump dosyasında thread’lerin callstack’leri incelenerek neyin beklendiğini ve neden yanıt alınamadığı araştırılır.

Eğer uygulamanın işlemci kullanımı düşük ve bu durum bir süre devam edip sonrasında çözülüyorsa o zaman durağan süre boyunca eşit aralıklarla 3-4 kez “hang” mode’da dump almak uygun olacaktır. Bu tip durumlar, genelikle uygulamanın başka bir uygulamadan yanıt beklemesinden kaynaklanır.

Son söz olarak, tek bir defa dump dosyası üretmek her zaman sorunun kaynağını aydınlatmada yardımcı olmayabilir. Aynı işlem ve hatta farklı modlarda tekrar dump almak gerekebilir.

Hoşçakalın

-faik