Due to many requests for memory dumps corresponding to crash dump analysis pat-terns we've started modeling software behaviour and defects. Every pattern will have an example application(s), service(s) or driver(s) or combination of them. Their execution results in memory layout that corresponds to memory or trace analysis patterns. Here we introduce an example model for Multiple Exceptions (user mode) pattern (Volume 1, page 255). The following source code models 3 threads where each having an exception during their execution on Windows XP, Windows 7 and Windows Server 2008 R2:
// MultipleExceptions-UserMode
// Copyright (c) 2010 Dmitry Vostokov
// GNU GENERAL PUBLIC LICENSE
// http://www.gnu.org/licenses/gpl-3.0.txt
#include <windows.h>
#include <process.h>
void thread_one(void *)
{
*(int *)NULL = 0;
}
void thread_two(void *)
{
*(int *)NULL = 0;
}
int main(int argc, WCHAR* argv[])
{
_beginthread(thread_two, 0, NULL);
_beginthread(thread_one, 0, NULL);
DebugBreak();
return 0;
}
In fact, thread_one and thread_two can be replaced with just one function be-cause they are identical. Visual C++ compiler does that during code optimization. On Windows 7 and W2K8 R2 I created LocalDumps (Volume 1, page 606) registry key to save full crash dumps. On Windows XP I set Dr. Watson as a postmortem debugger (via drwtsn32 -i command and configured it to save full user dumps via drwtsn32 command that brings Dr. Watson GUI). Vista had some peculiar behaviour so I postpone its discussion for another volume. The application can be downloaded from here (zip file contains source code, x86 and x64 binaries together with corresponding PDB files):
http://www.dumpanalysis.org/PatternModels/MultipleExceptions-UserMode.zip
Now we provide modeling results for x64 W2K8 R2 running on 2 processor machine. Windows 7 and Windows XP results are very similar. If we run x64 executable it crashes and a memory dump file is saved (x86 crash dump is similar). Default analysis command gives these results:
0:000> !analyze -v
[...]
FAULTING_IP:
MultipleExceptions_UserMode!thread_two+0
00000001 '3f8b1000 c704250000000000000000 mov dword ptr [0],0
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000007fefddc2442
(KERNELBASE!DebugBreak+0x0000000000000002)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000000
[...]
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint
has been reached.
[...]
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
[...]
STACK_TEXT:
00000001'3f8b1000 MultipleExceptions_UserMode!thread_two+0x0
00000001'3f8b10eb MultipleExceptions_UserMode!_callthreadstart+0x17
00000001'3f8b1195 MultipleExceptions_UserMode!_threadstart+0x95
00000000'778cf56d kernel32!BaseThreadInitThunk+0xd
00000000'77b03281 ntdll!RtlUserThreadStart+0x1d
[...]
We see a debug break on the first thread:
0:000> kL
Child-SP RetAddr Call Site
00000000'002eec78 000007fe'fdd913a6 ntdll!NtWaitForMultipleObjects+0xa
00000000'002eec80 00000000'778d3143 KERNELBASE!WaitForMultipleObjectsEx+0xe8
00000000'002eed80 00000000'77949025
kernel32!WaitForMultipleObjectsExImplementation+0xb3
00000000'002eee10 00000000'779491a7 kernel32!WerpReportFaultInternal+0x215
00000000'002eeeb0 00000000'779491ff kernel32!WerpReportFault+0x77
00000000'002eeee0 00000000'7794941c kernel32!BasepReportFault+0x1f
00000000'002eef10 00000000'77b6573c kernel32!UnhandledExceptionFilter+0x1fc
00000000'002eeff0 00000000'77ae5148 ntdll! ?? ::FNODOBFM::'string'+0x2365
00000000'002ef020 00000000'77b0554d ntdll!_C_specific_handler+0x8c
00000000'002ef090 00000000'77ae5d1c ntdll!RtlpExecuteHandlerForException+0xd
00000000'002ef0c0 00000000'77b1fe48 ntdll!RtlDispatchException+0x3cb
00000000'002ef7a0 000007fe'fddc2442 ntdll!KiUserExceptionDispatcher+0x2e
00000000'002efd58 00000001'3f8b103c KERNELBASE!DebugBreak+0×2
00000000'002efd60 00000001'3f8b13fb MultipleExceptions_UserMode!main+0×2c
00000000'002efd90 00000000'778cf56d
MultipleExceptions_UserMode!__tmainCRTStartup+0×15b
00000000'002efdd0 00000000'77b03281 kernel32!BaseThreadInitThunk+0xd
00000000'002efe00 00000000'00000000 ntdll!RtlUserThreadStart+0×1d
Two other threads show exception processing too:
0:000> × 1s; kL ntdll!NtDelayExecution+0xa: 00000000`77b201fa c3 ret Child-SP RetAddr Call Site 00000000'0076ef78 000007fe'fdd91203 ntdll!NtDelayExecution+0xa 00000000'0076ef80 00000000'77949175 KERNELBASE!SleepEx+0xab00000000'0076f020 00000000'779491ff kernel32!WerpReportFault+0×4500000000'0076f050 00000000'7794941c kernel32!BasepReportFault+0×1f00000000'0076f080 00000000'77b6573c kernel32!UnhandledExceptionFilter+0×1fc00000000'0076f160 00000000'77ae5148 ntdll! ??00000000'0076f190 00000000'77b0554d ntdll!_C_specific_handler+0×8c00000000'0076f200 00000000'77ae5d1c ntdll!RtlpExecuteHandlerForException+0xd00000000'0076f230 00000000'77b1fe48 ntdll!RtlDispatchException+0×3cb00000000'0076f910 00000001'3f8b1000 ntdll!KiUserExceptionDispatcher+0×2e00000000'0076fec8 00000001'3f8b10eb MultipleExceptions_UserMode!thread_two 00000000'0076fed0 00000001'3f8b1195 MultipleExceptions_UserMode!_callthreadstart+0×17 00000000'0076ff00 00000000'778cf56d MultipleExceptions_UserMode!_threadstart+0×95 00000000'0076ff30 00000000'77b03281 kernel32!BaseThreadInitThunk+0xd 00000000'0076ff60 00000000'00000000 ntdll!RtlUserThreadStart+0×1d
0:001> × 2s; kL ntdll!NtDelayExecution+0xa: 00000000'77b201fa c3 ret Child-SP RetAddr Call Site 00000000'0086e968 000007fe'fdd91203 ntdll!NtDelayExecution+0xa 00000000'0086e970 00000000'77949175 KERNELBASE!SleepEx+0xab00000000'0086ea10 00000000'779491ff kernel32!WerpReportFault+0×4500000000'0086ea40 00000000'7794941c kernel32!BasepReportFault+0×1f00000000'0086ea70 00000000'77b6573c kernel32!UnhandledExceptionFilter+0×1fc00000000'0086eb50 00000000'77ae5148 ntdll! ?? ::FNODOBFM::'string +0×236500000000'0086eb80 00000000'77b0554d ntdll!_C_specific_handler+0×8c00000000'0086ebf0 00000000'77ae5d1c ntdll!RtlpExecuteHandlerForException+0xd00000000'0086ec20 00000000'77b1fe48 ntdll!RtlDispatchException+0×3cb00000000'0086f300 00000001'3f8b1000 ntdll!KiUserExceptionDispatcher+0×2e00000000'0086f8b8 00000001'3f8b10eb MultipleExceptions_UserMode!thread_two 00000000'0086f8c0 00000001'3f8b1195 MultipleExceptions_UserMode!_callthreadstart+0×17 00000000'0086f8f0 00000000'778cf56d MultipleExceptions_UserMode!_threadstart+0×95 00000000'0086f920 00000000'77b03281 kernel32!BaseThreadInitThunk+0xd 00000000'0086f950 00000000'00000000 ntdll!RtlUserThreadStart+0×1d
We look at unhandled exception filter parameter to get exception pointers information (Volume 2, page 75):
0:002> kv
Child-SP RetAddr : Args to
Child : Call Site
[...]
00000000'0086ea70 00000000'77b6573c : 00000000'0086ebb0We see that default analysis command showed the break instruction exception record and error code from the first thread but IP and stack trace from other threads having NULL pointer access violation exception.
We continue our modeling of software behaviour with the ubiquitous Memory Leak (process heap) pattern (Volume 1, page 356). Instead of leaking small heap allocations that are easy to debug with user mode stack trace database our model program leaks large heap allocations (Volume 2, page 137):
// MemoryLeak-ProcessHeap
// Copyright (c) 2010 Dmitry Vostokov
// GNU GENERAL PUBLIC LICENSE
// http://www.gnu.org/licenses/gpl-3.0.txt
#include <windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
// create extra 25 heaps initially
for (int i = 0; i < 25; ++i)
HeapCreate(0, 0, 0);
// create a heap to leak within
HANDLE hHeap = HeapCreate(0, 0, 0);
while (true)
{
HeapAlloc(hHeap, 0, 1024*1024);
Sleep(1000);
}
return 0;
}
The program creates extra process heaps to simulate real life heap leaks that usually don't happen in a default process heap. Then, it slowly leaks 0×100000 bytes every second. The application can be downloaded from this link (zip file contains source code, x86 and x64 binaries together with corresponding PDB files):
http://www.dumpanalysis.org/PatternModels/MemoryLeak-ProcessHeap.zip
Here we present the results from x64 Windows Server 2008 R2 but x86 variants (we tested on x86 Vista) should be the same.
First we run the application and save a dump of it after a few seconds (we used Task Manager). Heap statistics shows 9 virtual blocks for the last 0000000001e00000 heap:
0:000> !heap -s
LFH Key : 0x000000d529c37801
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR VirtblocksVirtual block: 0000000001350000 - 0000000001350000 (size 0000000000000000)
Virtual block: 0000000001540000 - 0000000001540000 (size 0000000000000000)
Virtual block: 0000000001760000 - 0000000001760000 (size 0000000000000000)
Virtual block: 00000000019c0000 - 00000000019c0000 (size 0000000000000000)
Virtual block: 0000000001c10000 - 0000000001c10000 (size 0000000000000000)
Virtual block: 0000000001e80000 - 0000000001e80000 (size 0000000000000000)
Virtual block: 0000000001f90000 - 0000000001f90000 (size 0000000000000000)
Virtual block: 00000000020a0000 - 00000000020a0000 (size 0000000000000000)
Virtual block: 00000000021b0000 - 00000000021b0000 (size 0000000000000000)
0000000001e00000 00001002 512 8 512 3 1 1 9 0
------------------------------------------------------------------------------------
We then wait for a few minutes and save a memory dump again. Heap statistics clearly shows virtual block leaks because now we have 276 of them instead of previous 9 (we skipped most of them in the output below):
0:000> !heap -s
LFH Key : 0x000000d529c37801
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR VirtblocksVirtual block: 0000000001350000 - 0000000001350000 (size 0000000000000000)
Virtual block: 0000000001540000 - 0000000001540000 (size 0000000000000000)[... skipped ...]
Virtual block: 00000000131b0000 - 00000000131b0000 (size 0000000000000000)
Virtual block: 00000000132c0000 - 00000000132c0000 (size 0000000000000000)
Virtual block: 00000000133d0000 - 00000000133d0000 (size 0000000000000000)
Virtual block: 00000000134e0000 - 00000000134e0000 (size 0000000000000000)
Virtual block: 00000000135f0000 - 00000000135f0000 (size 0000000000000000)
Virtual block: 0000000013700000 - 0000000013700000 (size 0000000000000000)
Virtual block: 0000000013810000 - 0000000013810000 (size 0000000000000000)
Virtual block: 0000000013920000 - 0000000013920000 (size 0000000000000000)
Virtual block: 0000000013a30000 - 0000000013a30000 (size 0000000000000000)
Virtual block: 0000000013b40000 - 0000000013b40000 (size 0000000000000000)
Virtual block: 0000000013c50000 - 0000000013c50000 (size 0000000000000000)
Virtual block:0000000013d600000000000013d60000 (size 0000000000000000)
0000000001e00000 00001002 512 8 512 3 1 12760We see that the size of these blocks is 0×101000 bytes (with hindsight, extra 1000 is probably bookkeeping info):
0:000> !address0000000013d60000ProcessParametrs 00000000002b1f20 in range 00000000002b0000 00000000002d9000 Environment 00000000002b1320 in range 00000000002b0000 00000000002d9000 0000000013d60000 : 0000000013d60000 -Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 000010000000000000101000Usage RegionUsageHeap HandleMEM_COMMIT0000000001e00000
We want to know which thread allocates them and we search for the heap ad-dress 0000000001e00000 through virtual memory to find any execution residue on the thread raw stacks:
0:000> s -q 0 LFFFFFF 0000000001e0000000000000'001cf608 00000000'01e00000 00000000'01e0000000000000'001cf610 00000000'01e00000 00000000'0000085800000000'001cf630 00000000'01e00000 00000000'0000000a00000000'001cf6c8 00000000'01e00000 00000000'0000000000000000'001cf6e0 00000000'01e00000 00000000'01e00a8000000000'001cf720 00000000'01e00000 00000000'0000002000000000'001cf778 00000000'01e00000 00000000'01e0000000000000'001cf780 00000000'01e00000 00000000'0000000000000000'001cf798 00000000'01e00000 00000000'01e0200000000000'001cf7b0 00000000'01e00000 02100301'0000000000000000'001cf7c8 00000000'01e00000 00000000'01c1000000000000'001cf808 00000000'01e00000 00000000'0000000100000000'001cf830 00000000'01e00000 00000000'0000000200000000'001cf940 00000000'01e00000 00000000'00000000 00000000'002d8378 00000000'01e00000 004c0044'005c0064 00000000'01e00028 00000000'01e00000 00000000'01e00000 00000000'01e00030 00000000'01e00000 00000000'00000080
Address range 00000000'001cfxxxx belongs to the main thread:
0:000> kL Child-SP RetAddr Call Site00000000'001cf898 000007fe'fdd91203 ntdll!NtDelayExecution+0xa00000000'001cf8a0 00000001'3f39104f KERNELBASE!SleepEx+0xab00000000'001cf940 00000001'3f3911ea MemoryLeak_ProcessHeap!wmain+0×4f00000000'001cf970 00000000'778cf56d MemoryLeak_ProcessHeap!__tmainCRTStartup+0×15a00000000'001cf9b0 00000000'77b03281 kernel32!BaseThreadInitThunk+0xd00000000'001cf9e0 00000000'00000000 ntdll!RtlUserThreadStart+0×1d
0:000> dps 00000000'001cf608 00000000'001cf940
00000000'001cf608 00000000'01e00000
00000000'001cf610 00000000'01e00000
00000000'001cf618 00000000'00000858
00000000'001cf620 00000000'00000000
00000000'001cf628 00000000'77b229ac ntdll!RtlAllocateHeap+0×16c00000000'001cf7a8 00000000'01e80000
00000000'001cf7b0 00000000'01e00000
00000000'001cf7b8 02100301'00000000
00000000'001cf7c0 00000000'001f0000
00000000'001cf7c8 00000000'01e00000
00000000'001cf7d0 00000000'01c10000
00000000'001cf7d8 00000000'01e02000
00000000'001cf7e0 00000000'00270000
00000000'001cf7e8 03020302'00000230
00000000'001cf7f0 00000000'77be7288 ntdll!RtlpInterceptorRoutines
00000000'001cf7f8 00000000'00000000
00000000'001cf800 00000000'00100010
00000000'001cf808 00000000'01e00000
00000000'001cf810 00000000'00000001
00000000'001cf818 00000000'00100000
00000000'001cf820 00000000'00000000
00000000'001cf828 00000000'77b229ac ntdll!RtlAllocateHeap+0×16cWe see traces of RtlAllocateHeap function but it could be a coincidence (imagine that we don't have access to the source code and can't do live debugging to put break-points). We advise enabling user mode stack trace database as explained for another example process[55]. Then we launch our application again and save a new user dump. We repeat the same procedure to examine the raw stack:
0:000> !heap -s
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0x000000c21e1b31e6
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
0000000001bc0000 08000002 1024 168 1024 5 1 1 0 0 LFH
0000000000010000 08008000 64 4 64 1 1 1 0 0
0000000000020000 08008000 64 64 64 61 1 1 0 0
0000000000100000 08001002 1088 152 1088 2 2 2 0 0 LFH
0000000001d90000 08001002 512 8 512 3 1 1 0 0
0000000001f90000 08001002 512 8 512 3 1 1 0 0
00000000021c0000 08001002 512 8 512 3 1 1 0 0
0000000002130000 08001002 512 8 512 3 1 1 0 0
0000000002370000 08001002 512 8 512 3 1 1 0 0
0000000001e80000 08001002 512 8 512 3 1 1 0 0
0000000000110000 08001002 512 8 512 3 1 1 0 0
0000000002510000 08001002 512 8 512 3 1 1 0 0
0000000002760000 08001002 512 8 512 3 1 1 0 0
0000000001cc0000 08001002 512 8 512 3 1 1 0 0
0000000002030000 08001002 512 8 512 3 1 1 0 0
0000000002960000 08001002 512 8 512 3 1 1 0 0
0000000002670000 08001002 512 8 512 3 1 1 0 0
0000000002b90000 08001002 512 8 512 3 1 1 0 0
00000000022f0000 08001002 512 8 512 3 1 1 0 0
00000000028b0000 08001002 512 8 512 3 1 1 0 0
0000000001f10000 08001002 512 8 512 3 1 1 0 0
0000000002450000 08001002 512 8 512 3 1 1 0 0
00000000025f0000 08001002 512 8 512 3 1 1 0 0
0000000002a40000 08001002 512 8 512 3 1 1 0 0
0000000002c90000 08001002 512 8 512 3 1 1 0 0
0000000002d90000 08001002 512 8 512 3 1 1 0 0
0000000002e80000 08001002 512 8 512 3 1 1 0 0
0000000002fc0000 08001002 512 8 512 3 1 1 0 0
00000000030b0000 08001002 512 8 512 3 1 1 0 0
Virtual block: 0000000003130000 - 0000000003130000 (size 0000000000000000)
Virtual block: 0000000003240000 - 0000000003240000 (size 0000000000000000)
Virtual block: 0000000003350000 - 0000000003350000 (size 0000000000000000)
Virtual block: 0000000003460000 - 0000000003460000 (size 0000000000000000)
Virtual block: 0000000003570000 - 0000000003570000 (size 0000000000000000)
Virtual block: 0000000003680000 - 0000000003680000 (size 0000000000000000)
Virtual block: 0000000003790000 - 0000000003790000 (size 0000000000000000)
Virtual block: 00000000038a0000 - 00000000038a0000 (size 0000000000000000)
Virtual block: 00000000039b0000 - 00000000039b0000 (size 0000000000000000)
Virtual block: 0000000003ac0000 - 0000000003ac0000 (size 0000000000000000)
Virtual block: 0000000003bd0000 - 0000000003bd0000 (size 0000000000000000)
Virtual block: 0000000003ce0000 - 0000000003ce0000 (size 0000000000000000)
0000000002270000 08001002 512 8 512 3 1 1 12 0
0:000> s -q 0 LFFFFFF 0000000002270000 00000000'0029f648 00000000'02270000 00000000'000000a8 00000000'0029f660 00000000'02270000 00000000'77b99bc7 00000000'0029f6e8 00000000'02270000 00000000'02270000 00000000'0029f6f0 00000000'02270000 00000000'00000858 00000000'0029f710 00000000'02270000 00000000'0000000a 00000000'0029f758 00000000'02270000 00000000'0029f918 00000000'0029f7c0 00000000'02270000 00000000'03ce0040 00000000'0029f858 00000000'02270000 00000000'02270000 00000000'0029f860 00000000'02270000 00000000'00000000 00000000'0029f878 00000000'02270000 00000000'02272000 00000000'0029f890 00000000'02270000 02100301'00000000 00000000'0029f8f8 00000000'02270000 00000000'03ce0040 00000000'0029fa20 00000000'02270000 00000000'00000000 00000000'01be8a08 00000000'02270000 0064006e'00690057 00000000'02270028 00000000'02270000 00000000'02270000 00000000'02270030 00000000'02270000 00000000'00000080 0:000> dqs 00000000'0029f648 00000000'0029fa20 00000000'0029f648 00000000'02270000 00000000'0029f650 00000000'000000a8 00000000'0029f658 00000000'00000a80 00000000'0029f660 00000000'02270000 00000000'0029f668 00000000'77b99bc7 ntdll!RtlStdLogStackTrace+0x47 00000000'0029f670 00000000'002a0000 00000000'0029f678 00000000'0000007e 00000000'0029f680 00000000'02270a80 00000000'0029f688 00000000'00000000 00000000'0029f690 00000000'02270208 00000000'0029f698 00070000'77b99bc7 00000000'0029f6a0 00000000'77b6cd8a ntdll! ?? ::FNODOBFM::'string'+0xf35a 00000000'0029f6a8 00000000'77b0fd07 ntdll!RtlCreateHeap+0x56e 00000000'0029f6b0 000007fe'fdd9c6a4 KERNELBASE!HeapCreate+0x54 00000000'0029f6b8 00000001'3faa1030 MemoryLeak_ProcessHeap!wmain+0x30 00000000'0029f6c0 00000001'3faa11ea MemoryLeak_ProcessHeap!__tmainCRTStartup+0x15a 00000000'0029f6c8 00000000'778cf56d kernel32!BaseThreadInitThunk+0xd 00000000'0029f6d0 00000000'77be7288 ntdll!RtlpInterceptorRoutines 00000000'0029f6d8 00000000'00000000 00000000'0029f6e0 00000000'00000860 00000000'0029f6e8 00000000'02270000 00000000'0029f6f0 00000000'02270000 00000000'0029f6f8 00000000'00000858 00000000'0029f700 00000000'00000000 00000000'0029f708 00000000'77b229ac ntdll!RtlAllocateHeap+0x16c 00000000'0029f710 00000000'02270000 00000000'0029f718 00000000'0000000a 00000000'0029f720 00000000'00000858 00000000'0029f728 00000000'00000860 00000000'0029f730 00000000'00000000 00000000'0029f738 00000000'0029f820 00000000'0029f740 00000000'77be7288 ntdll!RtlpInterceptorRoutines 00000000'0029f748 00000000'00000002 00000000'0029f750 00000000'00100030 00000000'0029f758 00000000'02270000 00000000'0029f760 00000000'0029f918 00000000'0029f768 00000000'00000020 00000000'0029f770 00000000'00000002 00000000'0029f778 00000000'00000005 00000000'0029f780 00000000'000750f0 00000000'0029f788 00000000'77ba25b2 ntdll!RtlpRegisterStackTrace+0x92 00000000'0029f790 00000000'000750b8 00000000'0029f798 00000000'00000003
00000000'0029f7a0 00000000'00000000
00000000'0029f7a8 00000000'77ad7a0a ntdll!RtlCaptureStackBackTrace+0x4a
00000000'0029f7b0 00000000'00000002
00000000'0029f7b8 00000000'00100030
00000000'0029f7c0 00000000'02270000
00000000'0029f7c8 00000000'03ce0040
00000000'0029f7d0 00000000'00100020
00000000'0029f7d8 00000000'77ba2eb7 ntdll!RtlpStackTraceDatabaseLogPrefix+0x57
00000000'0029f7e0 00000000'03ce0040
00000000'0029f7e8 00000000'00000000
00000000'0029f7f0 00000000'00100020
00000000'0029f7f8 00000000'000750f0
00000000'0029f800 00000000'77b6ed2d ntdll! ?? ::FNODOBEM:: 'string' +0x1a81b
00000000'0029f808 00000001'3faa1044 MemoryLeak_ProcessHeap!wmain+0×44
00000000'0029f810 00000001'3faa11ea MemoryLeak_ProcessHeap!__tmainCRTStartup+0×15a
00000000'0029f818 00000000'778cf56d kernel32!BaseThreadInitThunk+0xd
00000000'0029f820 00000000'77b03281 ntdll!RtlUserThreadStart+0×1d00000000'0029f990 00000000'00000000 00000000'0029f998 00000000'00000012 00000000'0029f9a0 ffffffff'ff676980 00000000'0029f9a8 00000000'0029f9a0 00000000'0029f9b0 00000000'00000048 00000000'0029f9b8 00000000'00000001 00000000'0029f9c0 00000000'00000000 00000000'0029f9c8 00000000'00000000 00000000'0029f9d0 00000000'00000000 00000000'0029f9d8 00000000'00000000 00000000'0029f9e0 00000000'00000000 00000000'0029f9e8 00000000'00000000 00000000'0029f9f0 00000000'00000000 00000000'0029f9f8 00000000'00000000 00000000'0029fa00 00000000'00000000 00000000'0029fa08 00000000'00000001 00000000'0029fa10 00000000'00000000 00000000'0029fa18 00000001'3faa104f MemoryLeak_ProcessHeap!wmain+0×4f 00000000'0029fa20 00000000'02270000
Now we see this stack trace fragment from the user mode stack trace database on the raw stack shown above:
00000000'0029f800 00000000'77b6ed2d ntdll! ?? ::FNODOBFM::'string'+0x1a81b
00000000'0029f808 00000001'3faa1044It looks like HeapAlloc function was called from wmain indeed with 0×100000 parameter:
0:000< ub 00000001'3faa1044
MemoryLeak_ProcessHeap!wmain+0x26:
00000001'3faa1026 xor edx,edx
00000001'3faa1028 xor ecx,ecx
00000001'3faa102a call qword ptr
[MemoryLeak_ProcessHeap!_imp_HeapCreate (00000001'3faa7000)]
00000001'3faa1030 mov rbx,rax
00000001'3faa1033 xor edx,edx
00000001'3faa1035 mov r8d,100000h
00000001'3faa103b mov rcx,rbx
00000001'3faa103e call qword ptr [MemoryLeak_ProcessHeap!_imp_HeapAlloc
(00000001'3faa7008)]The stack trace fragment from x86 Vista user dump is even more straightforward:
0040fa00 77946e0c ntdll!RtlAllocateHeap+0×1e3
0040fa04 0022103a MemoryLeak_ProcessHeap!wmain+0×3aOf course, we could simply disassemble wmain function after identifying our thread but in real life functions are longer and leaking allocations could have happened from frames not present on the current stack traces.
Here we model Message Hooks pattern (page 76) using MessageHistory tool[56]. It uses window message hooking mechanism to intercept window messages. Download the tool and run either MessageHistory.exe or MessageHistory64.exe and push its Start but-ton. Whenever any process becomes active, either mhhooks.dll or mhhooks64.dll gets injected into the process virtual address space. Then we run WinDbg x86 or WinDbg x64, run notepad.exe and attach the debugger noninvasively to it:
*** wait with pending attach
Symbol search path is: srv*
Executable search path is:
WARNING: Process 2932 is not attached as a debuggee
The process can be examined but debug events will not be received
(b74.f44): Wake debugger - code 80000007 (first chance)
USER32!NtUserGetMessage+0xa:
00000000'76f9c92a c3 ret
0:000> .symfix
0:000> .reload
0:000> k
Child-SP RetAddr Call Site
00000000'0028f908 00000000'76f9c95e USER32!NtUserGetMessage+0xa
00000000'0028f910 00000000'ff511064 USER32!GetMessageW+0x34
00000000'0028f940 00000000'ff51133c notepad!WinMain+0x182
00000000'0028f9c0 00000000'76e7f56d notepad!DisplayNonGenuineDlgWorker+0x2da
00000000'0028fa80 00000000'770b3281 kernel32!BaseThreadInitThunk+0xd
00000000'0028fab0 00000000'00000000 ntdll!RtlUserThreadStart+0x1d
If we don't select "Noninvasive" in "Attach to Process" dialog box we need to switch from the debugger injected thread to our main notepad application thread:
0:001> .symfix 0:001> .reload 0:001> k Child-SP RetAddr Call Site 00000000'024bfe18 00000000'77178638 ntdll!DbgBreakPoint 00000000'024bfe20 00000000'76e7f56d ntdll!DbgUiRemoteBreakin+0x38 00000000'024bfe50 00000000'770b3281 kernel32!BaseThreadInitThunk+0xd 00000000'024bfe80 00000000'00000000 ntdll!RtlUserThreadStart+0x1d
0:001> × 0s USER32!NtUserGetMessage+0xa: 00000000'76f9c92a c3 ret 0:000> k Child-SP RetAddr Call Site 00000000'000af9e8 00000000'76f9c95e USER32!NtUserGetMessage+0xa 00000000'000af9f0 00000000'ff511064 USER32!GetMessageW+0x34 00000000'000afa20 00000000'ff51133c notepad!WinMain+0x182 00000000'000afaa0 00000000'76e7f56d notepad!DisplayNonGenuineDlgWorker+0x2da 00000000'000afb60 00000000'770b3281 kernel32!BaseThreadInitThunk+0xd 00000000'000afb90 00000000'00000000 ntdll!RtlUserThreadStart+0x1d
We then inspect the raw stack data to see any execution residue and find a few related function calls:
0:000> !teb
TEB at 000007fffffdd000
ExceptionList: 0000000000000000
StackBase: 0000000000290000
StackLimit: 000000000027f000
SubSystemTib: 0000000000000000
FiberData: 0000000000001e00
ArbitraryUserPointer: 0000000000000000
Self: 000007fffffdd000
EnvironmentPointer: 0000000000000000
ClientId: 0000000000000b74 . 0000000000000f44
RpcHandle: 0000000000000000
Tls Storage: 000007fffffdd058
PEB Address: 000007fffffdf000
LastErrorValue: 0
LastStatusValue: c0000034
Count Owned Locks: 0
HardErrorMode: 0
0:000> dps 000000000027f000 0000000000290000
[...]
00000000'0028e388 00000000'008bd8e0
00000000'0028e390 00000000'00000000
00000000'0028e398 00000000'00000001
00000000'0028e3a0 00000000'00000282
00000000'0028e3a8 00000000'76f966b2 USER32!SendMessageToUI+0x6a
00000000'0028e3b0 00000000'001406b0
00000000'0028e3b8 00000000'004000f8
00000000'0028e3c0 00000000'00000001
00000000'0028e3c8 00000001'800014b8hook00000000'0028e438 00000000'76f96a06 USER32!ImeWndProcWorker+0×3af 00000000'0028e440 00000000'00000282 00000000'0028e448 00000000'00000000 00000000'0028e450 00000000'00000001 00000000'0028e458 00000000'004000f8 00000000'0028e460 00000000'00000000 00000000'0028e468 00000000'00000001 00000000'0028e470 00000000'00000000 00000000'0028e478 00000000'00000000 00000000'0028e480 00000000'00000000 00000000'0028e488 00000000'76f9a078 USER32!_fnDWORD+0×44 00000000'0028e490 00000000'00000000 [...] 00000000'0028f770 00000000'001406b0 00000000'0028f778 000007ff'fffdd000 00000000'0028f780 00000000'0028f8c8 00000000'0028f788 00000000'008bd8e0 00000000'0028f790 00000000'00000018 00000000'0028f798 00000000'76f885a0USER32!DispatchHookW+0×2c00000000'0028f7a0 000022b2'00000000 00000000'0028f7a8 00000000'00000001 00000000'0028f7b0 000007fe'ff2d2560 MSCTF!IMCLock::'vftable' 00000000'0028f7b8 00000000'00407c50 00000000'0028f7c0 00000000'000c0e51 00000000'0028f7c8 00000000'00000000 00000000'0028f7d0 00000000'00000000 00000000'0028f7d8 00000000'00000113 00000000'0028f7e0 00000000'00000113 00000000'0028f7e8 00000000'00000001 00000000'0028f7f0 00000000'00000000 00000000'0028f7f8 00000000'76f9c3df USER32!UserCallWinProcCheckWow+0×1cb 00000000'0028f800 00000000'ff510000 notepad!CFileDialogEvents_QueryInterface <PERF> (notepad+0×0) 00000000'0028f808 00000000'00000000 00000000'0028f810 00000000'00000000 00000000'0028f818 00000000'00000000 00000000'0028f820 00000000'00000000 00000000'0028f828 00000000'00000038 00000000'0028f830 00000000'00000000 00000000'0028f838 00000000'00000000 00000000'0028f840 00000000'00000000 00000000'0028f848 00000000'770cfdf5ntdll!KiUserCallbackDispatcherContinue00000000'0028f850 00000000'00000048 00000000'0028f858 00000000'00000001 00000000'0028f860 00000000'00000000 [...]
We also see a 3rd-party module in proximity having "hook" in its module name: mhhooks64. We disassemble its address to see yet another message hooking evidence:
0:000> .asm no_code_bytes Assembly options: no_code_bytes
0:000> ubmhhooks64!CallWndProc+0×2ae: 00000001'8000148e imul rcx,rcx,30h 00000001'80001492 lea rdx,[mhhooks64!sendMessages (00000001'80021030)] 00000001'80001499 mov dword ptr [rdx+rcx+28h],eax 00000001'8000149d mov r9,qword ptr [rsp+50h] 00000001'800014a2 mov r8,qword ptr [rsp+48h] 00000001'800014a7 mov edx,dword ptr [rsp+40h] 00000001'800014ab mov rcx,qword ptr [mhhooks64!hCallWndHook (00000001'80021028)] 00000001'800014b2 call qword ptr [mhhooks64!_imp_00000001'800014b8(00000001'80017280)]CallNextHookEx
We encountered several crash dumps with the code running on heap with the following similar stack traces:
1: kd> k *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 02cdfbfc 0056511a 0x634648 02cdfc24 005651a1 ModuleA!ClassA::×ClassA+0x5a 02cdfc30 00562563 ModuleA!ClassA::'scalar deleting destructor'+0x11 [...] 02cdffec 00000000 kernel32!BaseThreadStart+0x37
To model this situation we came up with an idea was to corrupt a class member by overriding its vtable[57] pointer with a heap entry address. Because the virtual destructor address is a first virtual method table entry in our class memory layout we made sure that it points to the same heap address by making vtable pointer a dereference fixpoint (Volume 4, page 46). Here is a source code based on how Visual C++ compiler implements objects in memory:
class Member {
public:
virtual × Member() { data = 1; };
public:
int data;
};
class Compound {
public:
Compound(): pm(NULL) { pm = new Member(); }
virtual × Compound() { delete pm; }
void Corrupt() {
unsigned int * pbuf = new unsigned int[0x10];
*pbuf = reinterpret_cast<unsigned int>(pbuf); // to ensure that
//the code would run through pbuf pointer
*reinterpret_cast<unsigned int *> (pm) =
reinterpret_cast<unsigned int>(pbuf);
}
Member *pm;
};
int _tmain(int argc, _TCHAR* argv[])
{
Compound *pc = new Compound();
pc->Corrupt();
delete pc;
return 0;
}
In a crash dump we therefore see the similar stack trace:
0:000> .ecxr eax=001f4c28 ebx=7efde000 ecx=001f4c18 edx=001f4c28 esi=00000000 edi=00000000 eip=001f4c28 esp=003cf7d0 ebp=003cf7e8 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206284c1f00 sub byte ptr [edi+ebx],cl ds:002b:7efde000=00 0:000> k *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 003cf7cc001f4c28011d10e5003cf7e80×1f4c28011d114fDestructors!Compound::×Compound+0×35 003cf7f4 011d121e Destructors!Compound::'scalar 003cf82c 011d1498 Destructors!wmain+0×8e 003cf874 77043677 Destructors!__tmainCRTStartup+0xfa 003cf880 77719d72 kernel32!BaseThreadInitThunk+0xe 003cf8c0 77719d45 ntdll!__RtlUserThreadStart+0×70 003cf8d8 00000000 ntdll!_RtlUserThreadStart+0×1b
We now check the correctness of the stack trace by examining the return addresses:
0:000> .asm no_code_bytes
Assembly options: no_code_bytes
0:000> ub 011d10e5
Destructors!Compound::×Compound+0×21:
011d10d1 cmp dword ptr [ebp-4],0
011d10d5 je Destructors!Compound::×Compound+0×3a (011d10ea)
011d10d7 push 1
011d10d9 mov ecx,dword ptr [ebp-4]
011d10dc mov edx,dword ptr [ecx]
011d10de mov ecx,dword ptr [ebp-4]
011d10e1 mov eax,dword ptr [edx]
011d10e3 call eax
0:000> ub 011d114f
Destructors!Compound::Corrupt+0×3e:
011d113e int 3
011d113f int 3
Destructors!Compound::`scalar
011d1140 push ebp
011d1141 mov ebp,esp
011d1143 push ecx
011d1144 mov dword ptr [ebp-4],ecx
011d1147 mov ecx,dword ptr [ebp-4]
011d114a call Destructors!Compound::~Compound (011d10b0)
Then we examine the crash address:
0:000> u 001f4c28After that we check that it resides in a heap segment:
0:000> dt _PEB 7efde000 Destructors!_PEB [...] +0x088 NumberOfHeaps : 2 +0x08c MaximumNumberOfHeaps : 0x10 +0x090 ProcessHeaps : 0x777e4740 -> 0x004b0000 Void [...] 0:000> dd 0x777e4740 l2 777e4740 004b0000 001f0000 0:000> !heap 001f0000 Index Address Name Debugging options enabled 2: 001f0000 Segment at 001f0000 to 00200000 (00005000 bytes committed)
Now we check vtable to see that it was normal for Compound object but corrupt for Member object:
0:000> .frame 1 01 003cf7e8 011d114f Destructors!Compound::×Compound+0x35 0:000> dv /i /V prv local 003cf7dc @ebp-0x0c this = 0x001f4c08
0:000> dt Destructors!Compound 0x001f4c08 +0x000 __VFN_table : 0x011daa0c +0x004 pm : 0x001f4c18 Member 0:000> dps 0x001f4c08 l1 001f4c08 011daa0c Destructors!Compound::'vftable' 0:000> dps 0x001f4c18 l1 001f4c18 001f4c28 0:000> dps 001f4c28 l1 001f4c28 001f4c28
The application, its source code and PDB file are available for download:
http://www.dumpanalysis.org/downloads/Destructors.zip
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.