是否有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:
.NET decision
Similar to the WOW64 layer, you can check for .NET:
lm m mscorwks
lm m clr
lm m coreclr
当然可以加载这样的DLL是直接通过本机代码通过 LoadLibrary()
而不是使用.NET进行的,但是我认为这对想欺骗您的人是一种罕见的用法。
Of course it might be possible to load such a DLL via LoadLibrary()
from native code directly and not using .NET, but I think that's a rare usage of someone who wants to fool you.
这篇关于是否有Windbg命令来确定进程是32位进程还是64位进程?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!