6

If I have a process dump file, is there anyway of knowing if the dump was generated on a x64 machine or x86 machines?

Silverlight Student
  • 3,968
  • 10
  • 37
  • 53
  • Related or potential duplicate: https://stackoverflow.com/questions/43308814/is-there-a-windbg-command-to-find-out-if-a-process-is-a-32-bit-one-or-a-64-bit-o – Thomas Weller Aug 23 '17 at 18:19

4 Answers4

3

You can use the .effmach command to know the architecture that the dump was created on. Note that there is the WOW64 scenario where the dump arch is x64 but you should actually debug it with a x86 approach (see !wow64exts.sw command).

0:000> .effmach Effective machine: x64 (AMD64)

shluvme
  • 713
  • 7
  • 24
  • 1
    `.effmach` cannot be used to find out the bitness of the dump. It can only be used to find out the current bitness used for debugging. Try `!sw` on a 64 bit dump and then `.effmach` and it will no longer show the correct result. – Thomas Weller Oct 14 '15 at 22:08
  • 2
    You are correct, but if you're running on a WOW'd dump then before the !sw command the .effmach command will return the correct bitness which answered the authors question. Moreover, if you've followed us till now then you'll for sure know the bitness of the dump ;) – shluvme Oct 15 '15 at 14:52
2

Unfortunately, above answers don't work in most cases.

Dupmchk.exe will say "x86 compatible" for both x86 and x64 OS if the target process was built as x86 binary. And !peb command also gives you useless "PEB NULL..." for minidumps which we use most of the time.

You would better check the full path of "Kernel32.dll" since x64 OS will load "C:\Windows\Syswow64\Kernel32.dll" instead while x86 OS will load the plain "C:\Windows\System32\Kernel32.dll" for x86 executables. Loaded modules and their paths are recoreded in minidump and easily checked by dumpchk.exe, windbg and Visual Studio.

UJ Choi
  • 21
  • 2
  • Some customers want paths removed for privacy reasons and therefore use `.dump /marR`. – Thomas Weller Oct 14 '15 at 22:14
  • I also thought this was a valid strategy. It worked for me on Windows XP - Windows 7... However, Windows 8 changed things and munges SysWOW64 paths into System32 only. I thought it was weird that *all* my customers were running the 32bit version of Windows 8+... – Mark Jun 01 '17 at 17:12
2

You can look at the environment variables. Output of command !peb, among other things, contains list of environment variables. If you see variables PROCESSOR_ARCHITEW6432 or ProgramW6432 defined, the OS is 64 bit. Otherwise, it is 32 bit.

seva titov
  • 11,720
  • 2
  • 35
  • 54
  • when i run !peb command its gives me PEB NULL... Any idea what does this mean? – Silverlight Student Nov 11 '11 at 18:48
  • It means that dump does not contain process environment block (PEB). PEB is added when you use `.dump /mp' or `.dump /ma` or `.dump /mf` commands in debugger, or you use ADPlus (http://support.microsoft.com/kb/q286350). – seva titov Nov 11 '11 at 22:06
1

You can use the dumpchk.exe utility that ships with Debugging tools for Windows. Simply pass the dump file as the argument.

In the generated report, you'll have the OS version and the CPU flavor, for example :

Windows 7 Version 7601 (Service Pack 1) UP Free x64

Product: WinNt, suite: SingleUserTS

Community
  • 1
  • 1
Thierry Franzetti
  • 1,763
  • 12
  • 12
  • 1
    *If* it shows x64, then it must have been taken on a x64 OS but the opposite is not true. A 32 bit dump taken on a x64 system will show x86. – Thomas Weller Oct 14 '15 at 22:11