在Windows上获取进程的可执行文件路径

最新推荐文章于 2023-12-31 21:01:35 发布

mkdym

最新推荐文章于 2023-12-31 21:01:35 发布

阅读量6.9k

点赞数

文章标签： windows 进程路径

本文链接：https://blog.youkuaiyun.com/mkdym/article/details/8688597

版权

本文讲述了在Windows上遇到通过GetModuleFileNameEx获取进程路径失败的问题，尤其是涉及到动态磁盘时。经过排查，发现是QueryDosDeviceW函数在动态磁盘环境下的局限性导致。作者通过尝试使用GetProcessImageFileName和WMI（Windows Management Instrumentation）最终找到了解决方案：先尝试GetModuleFileNameEx，若失败则尝试GetProcessImageFileName，如果两者都失败，则利用WMI获取进程路径。同时，文章提出了对WMI在代码中使用较少的疑问以及对NtQueryInformationProcess可能存在的类似问题的思考。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在Windows上根据进程PID获取其可执行文件的路径，是一个常见的问题。通常我们采用广为人知的API——GetModuleFileNameEx。此函数兼容性极佳，最低支持版本为Windows2000，在许多场合它都工作正常。于是我也在代码中理所应当的使用了它。

忽然某时，我在日志中发现这厮留了一句Error：GetModuleFileNameEx fail, error code is 299。MSDN告诉我这句：Only part of a ReadProcessMemory or WriteProcessMemory request was completed。亲，这是什么意思？MSDN的错误解释有时搞得人真是一头雾水，还是先问问度娘（度娘不行了，再问谷歌）。查得，当我们调用GetModuleFileNameEx函数时，为了获得指定进程的全路径，它内部需要访问进程的PEB头。而64位进程的PEB头地址是保存在64位长度的地址中的，32位进程是保存在32位长度的地址中的，当32位进程访问64位进程的PEB头的时候，采取的是截断访问——只取低32位地址。于是GetModuleFileNameEx就有时正确，有时错误了。日志的主人刚好是个32位进程，也正好跑在了64位系统上。这个Error就这么被触发了。如果编译成64位进程，问题当然就不会存在，可是现实就是不那么让人如愿。
信念——问题的解决是必须的、一定的，只是时间长短而已。
既然上

最低0.47元/天解锁文章