是否有Windbg命令来确定进程是32位进程还是64位进程？ [英] Is there a Windbg command to find out if a process is a 32-bit one or a 64-bit one?
问题描述
是否有Windbg / NTSD命令告诉我在实时调试会话中附加的进程是32位的还是64位的？
Is there a Windbg/NTSD command to tell me if a process I have attached to in a live debugging session is a 32-bit one or a 64-bit one?
您能同时告诉我吗？
- 非托管流程？
和
- 受管理的人吗？
对于托管对象，我可以在C＃中以编程方式找到它，但是我仍然想知道是否有Windbg命令。
For a managed one, I can find that out programmatically in C# but still I'd like to know if there's a Windbg command for this.
更新
我要调试的目标进程是Microsoft Word（winword.exe）。 Office版本是2016，但是我不确定它是32位还是64位二进制文件。以下是一些观察结果：
The target process I am debugging is Microsoft Word (winword.exe). The Office version is 2016 but I am not sure if it is a 32-bit or a 64-bit binary. Here are some observations:
-
目标位置是 C：\Program Files（x86）\Microsoft Office \root\Office16\WinWord.exe
管道（ | ）命令只告诉我PID，进程是否连接到调试器以及映像的加载路径（如上面的＃1所述）。
The pipe (|) command tells me nothing more than PID, whether the process is attached to the debugger or not and the path from where the image is loaded (as noted in #1 above).
我正在64位计算机上调试它。因此，r显示了64位寄存器。
I am debugging this on a 64-bit machine. So, r reveals 64-bit registers.
附加到运行正常，运行正常的进程时，没有崩溃（我刚刚打开MS Word，然后说附加到进程），当前线程（ k ）的调用堆栈读取 wow64cpu！CpupSyscallStub + 0x9 表示最顶部的调用。这与＃1表示该进程是32位进程。
Upon attaching to a live, healthy process with no crashes (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, with #1 suggests that the process is a 32-bit process.
已经尝试过的命令
- ！peb（进程环境块）：告诉我们处理器架构，而不是被调试进程的小细节。
- !peb (Process Environment Block): Tells us the PROCESSOR ARCHITECTURE, not the bitness of the process being debugged.
- |
- vertarget
- r (indicates register size for my processor and does not tell me about the process)
但是我想知道是否有办法找出答案。
But I'm wondering if there's a way to find out.
推荐答案
32位/ 64位决策
为了快速测试，我经常使用
32 bit / 64 bit decision
For a quick test I often use
lm m wow64
检查WOW64是否层已加载。如果是这样，那是32位处理。
which checks if the WOW64 layer was loaded. If so, it's a 32 bit process.
这种方法在很多情况下都可以使用，因为今天的OS可能是64位。但是，您也可以在32位操作系统上进行32位转储，在这种情况下，这种方法将无法正常工作。
This approach works in many cases, because OS is likely 64 bit today. However, you could also have a 32 bit dump of a 32 bit OS, in which case this approach does not work well.
一种更具权威性的方法是
A more authorative approach is
.load wow64exts
!info
不幸的是，它提供了大量输出，因此很难在脚本中使用。
which gives a lot of output unfortunately, so it'll be hard to use in a script.
32位输出看起来像
0:000> !info
PEB32: 0xe4d000
PEB64: 0xe4c000
Wow64 information for current thread:
TEB32: 0xe50000
TEB64: 0xe4e000
[...]
如果是64位是
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
[...]
我没有可用的32位Windows OS转储，但我认为可以肯定地说
I don't have a 32 bit Windows OS dump available, but I assume it's safe to say that
- 如果PEB32不为0，则为32位进程。
- 如果PEB64为0，则为32位操作系统
如果知道模块名称，还可以检查文件头：
If you know the module name, you can also inspect the file headers:
0:000> .shell -ci "!dh -f notepad" findstr "machine"
8664 machine (X64)
.shell: Process exited
不起作用的东西
vertarget 注释不适用于32位应用程序的64位崩溃转储。
Things that do not work
vertarget as suggested in the comments does not work well for 64 bit crash dumps of 32 bit applications.
$ ptrsize 真是太好了，但这取决于调试器模式：
$ptrsize would have been 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
类似于WOW64层，您可以检查.NET：
Similar to the WOW64 layer, you can check for .NET: 当然可以加载这样的DLL是直接通过本机代码通过 Of course it might be possible to load such a DLL via 这篇关于是否有Windbg命令来确定进程是32位进程还是64位进程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
.NET decision
lm m mscorwks
lm m clr
lm m coreclr
LoadLibrary（）而不是使用.NET进行的，但是我认为这对想欺骗您的人是一种罕见的用法。LoadLibrary() from native code directly and not using .NET, but I think that's a rare usage of someone who wants to fool you.
