Comments on: Crash Dump Analysis Patterns (Part 56) https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Wed, 06 May 2026 11:14:00 +0000 http://wordpress.org/?v=2.3.3 By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-767745 Dmitry Vostokov Tue, 23 Dec 2025 22:07:46 +0000 https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-767745 Wild Code memory dump analysis pattern example: 0:000> db @$scopeip L10 04fd0002 48 61 70 70 79 20 48 6f-6c 69 64 61 79 73 21 00 Happy Holidays!. 0:000> u @$scopeip 04fd0002 48 dec eax 04fd0003 61 popad 04fd0004 7070 jo 04fd0076 04fd0006 7920 jns 04fd0028 04fd0008 48 dec eax 04fd0009 6f outs dx,dword ptr [esi] 04fd000a 6c ins byte ptr es:[edi],dx 04fd000b 6964617973210000 imul esp,dword ptr [ecx+79h],2173h Wild Code memory dump analysis pattern example:

0:000> db @$scopeip L10
04fd0002 48 61 70 70 79 20 48 6f-6c 69 64 61 79 73 21 00 Happy Holidays!.

0:000> u @$scopeip
04fd0002 48 dec eax
04fd0003 61 popad
04fd0004 7070 jo 04fd0076
04fd0006 7920 jns 04fd0028
04fd0008 48 dec eax
04fd0009 6f outs dx,dword ptr [esi]
04fd000a 6c ins byte ptr es:[edi],dx
04fd000b 6964617973210000 imul esp,dword ptr [ecx+79h],2173h

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-741695 Dmitry Vostokov Sat, 12 Mar 2016 19:25:41 +0000 https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-741695 Sometimes <p align="left"><code>0:000> k ChildEBP RetAddr 03ced1b0 771d6aec ntdll!KiFastSystemCallRet 03ced1b4 75406a8e ntdll!NtWaitForMultipleObjects+0xc 03ced250 7734be76 KERNELBASE!WaitForMultipleObjectsEx+0x100 03ced298 7734bee4 kernel32!WaitForMultipleObjectsExImplementation+0xe0 03ced2b4 7736072f kernel32!WaitForMultipleObjects+0x18 03ced320 773609ca kernel32!WerpReportFaultInternal+0x186 03ced334 77360978 kernel32!WerpReportFault+0x70 03ced344 773608f3 kernel32!BasepReportFault+0x20 03ced3d0 7720820a kernel32!UnhandledExceptionFilter+0x1af 03ced3d8 771ae364 ntdll!__RtlUserThreadStart+0x62 03ced3ec 771ae1fc ntdll!_EH4_CallFilterFunc+0x12 03ced414 771d72b9 ntdll!_except_handler4+0x8e 03ced438 771d728b ntdll!ExecuteHandler2+0x26 03ced45c 771af9d7 ntdll!ExecuteHandler+0x24 03ced4e8 771d7117 ntdll!RtlDispatchException+0x127 03ced4e8 63050001 ntdll!KiUserExceptionDispatcher+0xf 03ceda64 771e73e2 ModuleA!FunctionA+0xc1 03ceda84 0141b848 ntdll!_SEH_epilog4_GS+0xa 03cedcb4 767cbbf4 ModuleB!FunctionB+0x188 03cedcc8 767cbcb5 gdi32!NtGdiOpenDCW+0xc 03cedf70 013bc7df gdi32!hdcCreateDCW+0x517 03cee0c8 7734c413 ModuleB!FunctionC+0xff 03cee0e0 7734c3c2 kernel32!WaitForSingleObjectExImplementation+0x75 03cee0f4 65e66c9c kernel32!WaitForSingleObject+0x12 WARNING: Frame IP not in any known module. Following frames may be wrong. 00000000 00000000 0x65e66c9c</code> We see Incorrect Stack Trace pattern since it doesn't make sense that waiting functions call GDI and other modules. Also the return address for ModuleA!FunctionA looks coincidental: 63050001. Although we are able to see code we are not able to disassemble it backwards: <p align="left"><code>0:000> u 63050001 ModuleA!FunctionA+0xc1: 63050001 a1056383c4 mov eax,dword ptr ds:[C4836305h] 63050006 108d4c241051 adc byte ptr [ebp+5110244Ch],cl 6305000c ff15b4a00563 call dword ptr [ModuleA!_imp__OutputDebugStringA (6305a0b4)] 63050012 8b4e14 mov ecx,dword ptr [esi+14h] 63050015 85c9 test ecx,ecx 63050017 740e je ModuleA!FunctionA+0xe7 (63050027) 63050019 8b11 mov edx,dword ptr [ecx] 6305001b 8b4204 mov eax,dword ptr [edx+4]</code> <p align="left"><code>0:000> ub 63050001 ^ Unable to find valid previous instruction for 'ub 63050001'</code> <p align="left"><code>0:000> ub 63050001-1 ^ Unable to find valid previous instruction for 'ub 63050001-1'</code> <p align="left"><code>0:000> ub 63050001-2 ^ Unable to find valid previous instruction for 'ub 63050001-2'</code> <p align="left"><code>0:000> ub 63050001-3 ModuleA!FunctionA+0xa4: 6304ffe4 ffd2 call edx 6304ffe6 84c0 test al,al 6304ffe8 7541 jne ModuleA!FunctionA+0xeb (6305002b) 6304ffea 6818c20563 push offset ModuleA!`string' (6305c218) 6304ffef 68bcc10563 push offset ModuleA!`string' (6305c1bc) 6304fff4 8d442418 lea eax,[esp+18h] 6304fff8 6800010000 push 100h 6304fffd 50 push eax</code> Sometimes

0:000> k
ChildEBP RetAddr
03ced1b0 771d6aec ntdll!KiFastSystemCallRet
03ced1b4 75406a8e ntdll!NtWaitForMultipleObjects+0xc
03ced250 7734be76 KERNELBASE!WaitForMultipleObjectsEx+0x100
03ced298 7734bee4 kernel32!WaitForMultipleObjectsExImplementation+0xe0
03ced2b4 7736072f kernel32!WaitForMultipleObjects+0x18
03ced320 773609ca kernel32!WerpReportFaultInternal+0x186
03ced334 77360978 kernel32!WerpReportFault+0x70
03ced344 773608f3 kernel32!BasepReportFault+0x20
03ced3d0 7720820a kernel32!UnhandledExceptionFilter+0x1af
03ced3d8 771ae364 ntdll!__RtlUserThreadStart+0x62
03ced3ec 771ae1fc ntdll!_EH4_CallFilterFunc+0x12
03ced414 771d72b9 ntdll!_except_handler4+0x8e
03ced438 771d728b ntdll!ExecuteHandler2+0x26
03ced45c 771af9d7 ntdll!ExecuteHandler+0x24
03ced4e8 771d7117 ntdll!RtlDispatchException+0x127
03ced4e8 63050001 ntdll!KiUserExceptionDispatcher+0xf
03ceda64 771e73e2 ModuleA!FunctionA+0xc1
03ceda84 0141b848 ntdll!_SEH_epilog4_GS+0xa
03cedcb4 767cbbf4 ModuleB!FunctionB+0x188
03cedcc8 767cbcb5 gdi32!NtGdiOpenDCW+0xc
03cedf70 013bc7df gdi32!hdcCreateDCW+0x517
03cee0c8 7734c413 ModuleB!FunctionC+0xff
03cee0e0 7734c3c2 kernel32!WaitForSingleObjectExImplementation+0x75
03cee0f4 65e66c9c kernel32!WaitForSingleObject+0x12
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 00000000 0x65e66c9c

We see Incorrect Stack Trace pattern since it doesn’t make sense that waiting functions call GDI and other modules. Also the return address for ModuleA!FunctionA looks coincidental: 63050001. Although we are able to see code we are not able to disassemble it backwards:

0:000> u 63050001
ModuleA!FunctionA+0xc1:
63050001 a1056383c4 mov eax,dword ptr ds:[C4836305h]
63050006 108d4c241051 adc byte ptr [ebp+5110244Ch],cl
6305000c ff15b4a00563 call dword ptr [ModuleA!_imp__OutputDebugStringA (6305a0b4)]
63050012 8b4e14 mov ecx,dword ptr [esi+14h]
63050015 85c9 test ecx,ecx
63050017 740e je ModuleA!FunctionA+0xe7 (63050027)
63050019 8b11 mov edx,dword ptr [ecx]
6305001b 8b4204 mov eax,dword ptr [edx+4]

0:000> ub 63050001
^ Unable to find valid previous instruction for 'ub 63050001'

0:000> ub 63050001-1
^ Unable to find valid previous instruction for 'ub 63050001-1'

0:000> ub 63050001-2
^ Unable to find valid previous instruction for 'ub 63050001-2'

0:000> ub 63050001-3
ModuleA!FunctionA+0xa4:
6304ffe4 ffd2 call edx
6304ffe6 84c0 test al,al
6304ffe8 7541 jne ModuleA!FunctionA+0xeb (6305002b)
6304ffea 6818c20563 push offset ModuleA!`string' (6305c218)
6304ffef 68bcc10563 push offset ModuleA!`string' (6305c1bc)
6304fff4 8d442418 lea eax,[esp+18h]
6304fff8 6800010000 push 100h
6304fffd 50 push eax

]]> By: Crash Dump Analysis » Blog Archive » Wild code and partial stack reconstruction https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-92196 Crash Dump Analysis » Blog Archive » Wild code and partial stack reconstruction Fri, 04 Sep 2009 14:15:01 +0000 https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-92196 [...] recently got a chance to see an instance of Wild Code pattern in kernel [...] […] recently got a chance to see an instance of Wild Code pattern in kernel […]

]]> By: Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 84) https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-74533 Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 84) Fri, 15 May 2009 18:19:27 +0000 https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-74533 [...] the assembly code looks almost wild (not like generated by your favourite compiler). For example (that also shows .NET runtime native [...] […] the assembly code looks almost wild (not like generated by your favourite compiler). For example (that also shows .NET runtime native […]

]]> By: Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 66) https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-30971 Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 66) Fri, 20 Jun 2008 13:06:55 +0000 https://www.dumpanalysis.org/blog/index.php/2008/03/27/crash-dump-analysis-patterns-part-56/#comment-30971 [...] provided specific recommendation hints. When looking at the crash point we see an instance of Wild Code [...] […] provided specific recommendation hints. When looking at the crash point we see an instance of Wild Code […]

]]>