在WOW64中捕获HANDLE的创build

我正在尝试排除第三方二进制文件的慢启动问题(无源代码)。 它是在64位Windows 7上运行的32位应用程序。

我使用了一个debugging器,在启动过程中挂起0%的CPU使用率时,中断了应用程序,并且似乎在等待ReadFile返回。 ReadFile的第一个参数是句柄值000000f0。 windbg!handle命令告诉我:

 Handle f0 Type File Attributes 0 GrantedAccess 0x120189: ReadControl,Synch Read/List,ReadEA,ReadAttr,WriteAttr HandleCount 2 PointerCount 4 No Object Specific Information available 

我想知道这个对应的设备。 但是Sysinternals Process Explorer在其进程句柄列表中不包含这个句柄。

我用windbg跟踪所有对ntdll!NtCreateFile调用,并打印path并返回句柄:这个句柄不在其中。 在kernel32!CreateNamedPipeWkernel32!CallNamedPipeWkernel32!WaitNamedPipeW永远不会被触发(这很奇怪,因为Process Explorer确实显示了另一个path\Device\NamedPipe\ )。

作为参考,下面是在Windows x64上跟踪NtCreateFile (akak ZwCreateFile )的命令:

 bp ntdll!NtCreateFile "!ustr poi(@r8+10) ; r $t0 = @rcx ; gu ; dd @$t0 L1 ; gc" 

感谢Skywing指出我正确的方向 。

typesFile的HANDLE来自哪里? 不要把其他的HANDLE创build函数委托给NtCreateFile作为实际的系统调用(我猜不是)?

看起来您只能在进行内核调试时获取文件句柄信息。 所以有3个选项。

  1. 做一个本地机器内核调试,这不应该是一个问题,因为你只需要获得文件句柄信息,并保持静态。 请参阅以下内容: http : //msdn.microsoft.com/en-us/library/windows/hardware/ff553382(v=vs.85).aspx
  2. 对VM机器执行远程内核调试。 从这个意义上讲,“安全”是不能炸毁你的机器的。
  3. BSOD你的盒子,看看转储的方式。 再次对你的盒子不是一件很好的事情,但是我过去做过类似的事情,当我需要能够在没有机器状态改变的情况下对机器进行全面的分析。

句柄可以继承,也可以由DuplicateHandle()创建。 您可以尝试调用句柄上的GetFileInformationByHandleEx并查询FileNameInfo。