Note: 32-bit stack from 64-bit dump
CARE: Crash Analysis Report Environment
DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.
Twitter @ DumpAnalysis You can now follow portal and blog news at DumpAnalysis on Twitter
LinkedIn Group Dr. Watson Enthusiasts All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)
2010 (0x7DA) - The Year of Dump Analysis 2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade
Just a short note that might be useful if you get a 64-bit dump of a 32-bit process from x64 Windows. As a reminder I wrote already about separate dump types and tools for 32-bit and 64-bit processes.
Since then I’ve been looking for a simple solution in case we get a 64-bit dump so we could look at 32-bit thread stacks, etc. Yesterday I accidentally found wow64exts.dll extension in 64-bit WinDbg. I should have been looked at \winxp folder before :-)
The whole discussion and solution can be found on Crash Dump Analysis forum:
http://www.dumpanalysis.org/forum/viewtopic.php?t=39
Now if by accident a customer sends a 64-bit dump of a 32-bit process (some Citrix services like IMA service are still 32-bit in x64 CPS4) then we can look at threads without asking for a new dump and therefore avoid roundtrips and shorten time to problem resolution.
- Dmitry Vostokov -
_1125.png)
Coming Soon:
Debugging Notebook: Essential Concepts, WinDbg Commands and Tools
Crash Dump Analysis for System Administrators and Support Engineers
New Magazines:
Debugged! MZ/PE: MagaZine for/from Practicing Engineers
New Books:
Memory Dump Analysis Anthology, Volume 3
First Fault Software Problem Solving: A Guide for Engineers, Managers and Users
x64 Windows Debugging: Practical Foundations
Also available:
Windows Debugging: Practical Foundations
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
February 14th, 2007 at 3:50 am
The preferred way to do this is “.effmach x86″, btw; then use “.effmach .” to return to the native processor mode.
The builtin engine commands supersede the older wow64exts extension dll.
February 22nd, 2007 at 12:08 pm
Thanks, it works, but it still uses wow64exts
0:000> .effmach x86
Effective machine: x86 compatible (x86)
0:000:x86> ~*kv
. 0 Id: 9ac.d7c Suspend: 0 Teb: 00000000`7efdb000 Unfrozen
Need to load wow64exts.dll to retrieve context!
February 22nd, 2007 at 12:18 pm
Moreover you you need to load that extention manually:
1 Id: 9ac.668 Suspend: 0 Teb: 00000000`7efad000 Unfrozen
Need to load wow64exts.dll to retrieve context!
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
0010001f 00000000 00000000 00000000 00000000 0×0
0:000:x86> .load wow64exts
0:000:x86> ~*kv
…
…
…
1 Id: 9ac.668 Suspend: 0 Teb: 00000000`7efad000 Unfrozen
ChildEBP RetAddr Args to Child
03a0fad8 7db40553 00000270 00000001 03a0fb00 ntdll_7d600000!ZwWaitForSingleObject+0×15
03a0fb14 7db4092c 00000270 0000027c 00000000 mswsock!SockWaitForSingleObject+0×19d
03a0fc04 71c0470c 00000001 03a0fe84 03a0fc7c mswsock!WSPSelect+0×380
03a0fc54 77215d7a 00000001 03a0fe84 03a0fc7c WS2_32!select+0xb9
03a0ffb0 7721d925 03a0ffec 7d4dfff1 003349e8 WININET!ICAsyncThread::SelectThread+0×22a
03a0ffb8 7d4dfff1 003349e8 00000000 00000000 WININET!ICAsyncThread::SelectThreadWrapper+0xd
03a0ffec 00000000 7721d918 003349e8 00000000 kernel32!BaseThreadStart+0×34