Is there a Windbg command to find out if a process is 32-bit or 64-bit?

Question

Is there a Windbg / NTSD command to tell me if the process that I connected in the active debugging session is 32-bit or 64-bit?

Could you tell me both:

• Uncontrolled process?

and

2. Managed?

For managed, I can find this programmatically in C #, but still I would like to know if there is a Windbg command for this.

UPDATE

The target process that I am debugging is Microsoft Word (winword.exe). Office is 2016, but I'm not sure if it is 32-bit or 64-bit binary. Here are a few notes:

• Target location C: \ Program Files (x86) \ Microsoft Office \ root \ Office16 \ WinWord.exe

• The pipe ( | ) command tells me nothing more than the PID, whether the process is connected to the debugger or not, and the path from the image download location (as indicated in # 1 above).

• I am debugging this on a 64 bit machine. So r shows 64-bit registers.

• When connected to a live, healthy process without failures (I just opened MS Word and said “Attach to Process”), the callstack for the current thread ( k ) reads wow64cpu!CpupSyscallStub+0x9 for the top most call. This, from # 1, suggests that the process is a 32-bit process.

Teams have already tried

• ! peb (Process Environment Block): Tells us the ARCHITECTURE of the PROCESSOR, not the bit of the process being debugged.
• |
• vertarget
• r (indicates the size of the register for my processor and does not tell me about this process)

But I wonder if there is a way to find out.

Answer 1

32-bit / 64-bit solution

For a quick test, I often use

 lm m wow64 

which checks if the WOW64 layer has been loaded. If so, this is a 32-bit process.

This approach works in many cases, because today the OS is most likely 64 bits. However, you can also have a 32-bit dump of a 32-bit OS, in which case this approach does not work.

More authoritarian approach

 .load wow64exts !info 

which, unfortunately, gives a lot of results, so it will be difficult to use in a script.

32-bit output looks like

 0:000> !info PEB32: 0xe4d000 PEB64: 0xe4c000 Wow64 information for current thread: TEB32: 0xe50000 TEB64: 0xe4e000 [...] 

In the case of 64 bits, this

 0:000> !info Could not get the address of the 32bit PEB, error 0 PEB32: 0 PEB64: 0x6b33c50000 Wow64 information for current thread: TEB32: 0 TEB64: 0x6b33c51000 [...] 

I don't have a 32-bit dump of Windows OS, but I'm sure

• If PEB32 is not 0, this is a 32-bit process.
• If PEB64 is 0, it is a 32-bit OS

If you know the name of the module, you can also check the file headers:

 0:000> .shell -ci "!dh -f notepad" findstr "machine" 8664 machine (X64) .shell: Process exited 

Things that don't work

vertarget , as suggested in the comments, does not work well for 64-bit crash dumps of 32-bit applications.

$ptrsize would be so nice, but it depends on the debugger mode:

 0:000> ? $ptrsize Evaluate expression: 8 = 00000000`00000008 0:000> .effmach x86 Effective machine: x86 compatible (x86) 0:000:x86> ? $ptrsize Evaluate expression: 4 = 00000004 

.NET Solution

Like the WOW64 layer, you can check .NET:

 lm m mscorwks lm m clr lm m coreclr 

Of course, it would be possible to load such a DLL through LoadLibrary() from native code directly and not use .NET, but I think this is a rare use of someone who wants to trick you.