Capturing Dump Using Windbg

Copy this script and save as .reg file. Dump files will be saved in c:\dump folder.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]
"Auto"="1"
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"c:\\Program Files\\Debugging Tools for Windows (x86)\\windbg.exe\" -p %ld -e %ld -g -Q -c \".dump /mfhtpu /u c:\\dump.dmp;q\""

!htrace: The difference between the two snapshot is too large

Click on Debug > Break (or just CTRL+Break)

Type “!htrace –diff” without the quotation marks and then press Enter.

Note: By default, Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2 keep a history of 4000 handles open and close operations.
With !htrace you can enable to keep a much higher history by doing the following:

Type “!htrace –enable 0x20000” without the quotation marks and then press Enter.
In this example, we are increasing the handle history to 128000 (decimal, 0x20000 hexadecimal).


Link:- http://blogs.technet.com/b/yongrhee/archive/2011/12/19/how-to-troubleshoot-a-handle-leak.aspx

DllMain and RPC Call

This post is calling RPC function from DllMain()

ntdll!ZwWaitForSingleObject+0x15 (FPO: [3,0,0])
ntdll!RtlpWaitOnCriticalSection+0x1a3 (FPO: [Non-Fpo])
ntdll!RtlEnterCriticalSection+0xa8 (FPO: [Non-Fpo])
RPCRT4!PerformRpcInitialization+0x22 (FPO: [Non-Fpo])
RPCRT4!RpcStringBindingComposeW+0x14 (FPO: [Non-Fpo])
somedll!InternalDllMain+0x41 (FPO: [Non-Fpo]) (CONV: stdcall) [f:\sp\vctools\vc7libs\ship\atlmfc\src\mfc\dllmodul.cpp @ 119]
somedll!__DllMainCRTStartup+0x6c (FPO: [Non-Fpo]) (CONV: cdecl) [f:\sp\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 365]
somedll!_DllMainCRTStartup+0x1d (FPO: [3,0,0]) (CONV: stdcall) [f:\sp\vctools\crt_bld\self_x86\crt\src\dllcrt0.c @ 328]
ntdll!LdrpCallInitRoutine+0x14
ntdll!LdrpRunInitializeRoutines+0x367 (FPO: [Non-Fpo])
ntdll!LdrpLoadDll+0x44b (FPO: [Non-Fpo])
ntdll!LdrLoadDll+0x198 (FPO: [Non-Fpo])
kernel32!LoadLibraryExW+0x1b2 (FPO: [Non-Fpo])
kernel32!LoadLibraryW+0x11 (FPO: [Non-Fpo])
someexe!somefunction

Assembly for PerformRpcInitialization(This is not full assembly but only which is required for this post)

RPCRT4!PerformRpcInitialization:
7da3933f 8bff mov edi,edi
7da39341 55 push ebp
7da39342 8bec mov ebp,esp
7da39344 83ec28 sub esp,28h
7da39347 56 push esi
7da39348 33f6 xor esi,esi
7da3934a 3935dc00ad7d cmp dword ptr [RPCRT4!RpcHasBeenInitialized (7dad00dc)],esi
7da39350 0f842eec0000 je RPCRT4!PerformRpcInitialization+0x17 (7da47f84)

RPCRT4!PerformRpcInitialization+0x236:
7da39356 33c0 xor eax,eax

RPCRT4!PerformRpcInitialization+0x238:
7da39358 5e pop esi
7da39359 c9 leave
7da3935a c3 ret

RPCRT4!PerformRpcInitialization+0x17:
7da47f84 687800ad7d push offset RPCRT4!GlobalMutex (7dad0078)
7da47f89 ff15b402a37d call dword ptr [RPCRT4!_imp__RtlEnterCriticalSection (7da302b4)]
7da47f8f 3935dc00ad7d cmp dword ptr [RPCRT4!RpcHasBeenInitialized (7dad00dc)],esi7da47f95 0f85ba010000 jne RPCRT4!PerformRpcInitialization+0x227 (7da48155)

RPCRT4!PerformRpcInitialization+0x2e:
7da47f9b 6888c1a37d push offset RPCRT4!`string' (7da3c188)
7da47fa0 ff155c01a37d call dword ptr [RPCRT4!_imp__LoadLibraryW (7da3015c)]7da47fa6 85c0 a test eax,eax

If you see lines marked in bold, it could lead into another loadlibrary call, hence deadlock could happen.

If rpc is not initialized then it will endup into loadlibrary(). Hence it will try to acquire loaderlock which is already hold by our process hence deadlock!!!

Good Links

A Crash Course on the Depths of Win32™ Structured Exception Handling

Exception Handling

First and second chance exception handling

Distinction between the first and second chance exception: the debugger gets the first chance to see the exception (hence the name). If the debugger allows the program execution to continue and does not handle the exception, the program will see the exception as usual. If the program does not handle the exception, the debugger gets a second chance to see the exception. In this latter case, the program normally would crash if the debugger were not present.

If you do not want to see the first chance exception in the debugger, you should disable first chance exception handling for the specific exception code. Otherwise, when the first chance exception occurs, you may need to instruct the debugger to pass on the exception to the program to be handled as usual.

Does a first chance exception mean there is a problem in my code?
First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.


References:
First and second chance exception handling

Dump Generation

Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes.
Collecting user-mode dumps

WER Settings Click Here!!!

How to Use the Userdump.exe Tool to Create a Dump File

How to use ADPlus to troubleshoot "hangs" and "crashes"

ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use) and unhandled exception monitoring. It also can serve as a general process dump utility that you can embed in other scripts.
ProcDump v1.72

Dr. Watson

You can use windbg and .dump command with appropriate switch

How to use Dumpchk.exe to check a Memory Dump file

Configuring Automatic Debugging

Specifying the Debugger for Unhandled User Mode Exceptions

How to: Launch the Debugger Automatically

Finding crash information using the MAP file

Forcing a System Crash from the Keyboard

extern "C" function assumed not to throw execption

Hi,

Today I have noticed that function declared with extern "C", are not assumed to throw.

If this function does throw execption, results are unexpected.

It could corrupt whole data section, anything can happen

More Reference:- Clickhere!!!

Clickhere!!!

Argument of KiUserExceptionDispatcher() function

For hardware generated exceptions (such as access violations), one can look for ntdll!KiUserExceptionDispatcher on the stack, which takes a PCONTEXT and PEXCEPTION_RECORD as argument.

Stack Trace:

0021e9fc 77db5f79 fffffffe 0021f878 0021eb04 ntdll!_except_handler4+0x8e

0021ea20 77db5f4b 0021eae8 0021f878 0021eb04 ntdll!ExecuteHandler2+0x26

0021ead0 77db5dd7 0121eae8 0021eb04 0021eae8 ntdll!ExecuteHandler+0x24

0021ead0 77d8e13d 0121eae8 0021eb04 0021eae8 ntdll!KiUserExceptionDispatcher+0xf

0021ee20 77d8e04d 00000000 00000000 00000001 ntdll!RtlpWaitOnCriticalSection+0xc5

0:000> .exr 0x21eae8

ExceptionAddress: 77d8e13d (ntdll!RtlpWaitOnCriticalSection+0x000000c5)

ExceptionCode: c0000005 (Access violation)

ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000001

Parameter[1]: 00000014

Attempt to write to address 00000014

0:000> .cxr 0x21eb04

eax=00000000 ebx=fffffffc ecx=00000000 edx=00000004 esi=737b19a0 edi=737b19a4

eip=77d8e13d esp=0021edd0 ebp=0021ee20 iopl=0 nv up ei pl nz ac po cy

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010213

ntdll!RtlpWaitOnCriticalSection+0xc5:

77d8e13d 83401401 add dword ptr [eax+14h],1 ds:0023:00000014=????????

0:000> dt -r1 0x21eb04 CONTEXT

ntdll!CONTEXT

+0x000 ContextFlags : 0x1003f

+0x004 Dr0 : 0

+0x008 Dr1 : 0

+0x00c Dr2 : 0

+0x010 Dr3 : 0

+0x014 Dr6 : 0

+0x018 Dr7 : 0

+0x01c FloatSave : _FLOATING_SAVE_AREA

   +0x000 ControlWord : 0xffff027f

   +0x004 StatusWord : 0xffff0000

   +0x008 TagWord : 0xffffffff

   +0x00c ErrorOffset : 0

   +0x010 ErrorSelector : 0

   +0x014 DataOffset : 0

   +0x018 DataSelector : 0xffff0000

   +0x01c RegisterArea : [80] ""

   +0x06c Cr0NpxState : 0

+0x08c SegGs : 0

+0x090 SegFs : 0x3b

+0x094 SegEs : 0x23

+0x098 SegDs : 0x23

+0x09c Edi : 0x737b19a4

+0x0a0 Esi : 0x737b19a0

+0x0a4 Ebx : 0xfffffffc

+0x0a8 Edx : 4

+0x0ac Ecx : 0

+0x0b0 Eax : 0

+0x0b4 Ebp : 0x21ee20

+0x0b8 Eip : 0x77d8e13d

+0x0bc SegCs : 0x1b

+0x0c0 EFlags : 0x10213

+0x0c4 Esp : 0x21edd0

+0x0c8 SegSs : 0x23

+0x0cc ExtendedRegisters : [512] "???"

0:000> dt -r1 0x21eae8 EXCEPTION_RECORD

ntdll!EXCEPTION_RECORD

+0x000 ExceptionCode : 0xc0000005

+0x004 ExceptionFlags : 0

+0x008 ExceptionRecord : (null)

+0x00c ExceptionAddress : 0x77d8e13d

+0x010 NumberParameters : 2

+0x014 ExceptionInformation : [15] 1

0:000> !error 0xc0000005

Error code: (NTSTATUS) 0xc0000005 (3221225477) - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

You can see the exception code is 0xc0000005 which is Access Violation
So whenever you find the KiUserExceptionDispatcher() function in call stack you can check for CONTEXT structure and EXCEPTION_RECORD structure, to find the exception code.

References:
Debugger tricks: Find all probable CONTEXT records in a crash dump

IRP

Working With An Incomplete Or Invalid IRP Click here!!!

Solving 11 Likely Problems In Your Multithreaded Code

Solving 11 Likely Problems In Your Multithreaded Code Click here!!!