GetModuleFileNameA 返回奇怪的结果答案

【问题标题】：GetModuleFileNameA returns weird resultsGetModuleFileNameA 返回奇怪的结果
【发布时间】：2011-04-16 06:58:21
【问题描述】：

我正在尝试使用 GetModuleFileNameA 获取在另一个进程中加载的模块的名称。
我已经使用 dbgHelp 加载了一个符号并获得了它的模块基地址，但是发生了 2 件奇怪的事情：
1. 有时GetModuleFileNameA 会返回系统错误代码 5：访问被拒绝。
2.它返回错误的模块名称。对于我知道在模块 A 中的函数，我得到模块 B 的名称...：/

有人可以帮我吗？
谢谢:)

【问题讨论】：

为什么你还在使用那个函数的 ANSI 版本？
哈哈，函数名末尾的A表示是ANSI版本的函数。 Windows 操作系统在很长一段时间内开始在内部使用 Unicode。 Unicode 版本的函数在其名称后有一个W，而不是A。但是，如果您包含 Windows 标头 (windows.h)，您所要做的就是使用函数的名称 (GetModuleFileName)，并且标头负责将其定义为正确的变体。您应该在未定义 _UNICODE 的情况下进行编译的唯一原因是您是否仍然针对真正旧版本的 Windows。
一点也不。我们说的是 Windows 95 或 98。Windows XP 完全是 Unicode，所有版本的 Windows NT 都是。就像我说的，最简单的事情就是忘记前缀，让头文件自动为您定义正确的版本。今天编写的几乎所有代码都是Unicode。

标签： c++ windows getmodulefilename

【解决方案1】：

请阅读文档。就在GetModuleFileName 的页面上，上面写着

要查找由另一个进程加载的模块的文件，请使用 GetModuleFileNameEx 函数。

GetModuleFileName 仅对进程中的模块有意义。即使两个进程都加载了模块，它也可能位于不同的基地址。您正在有效地喂食 GetModuleFileName 垃圾。重申一下，您需要使用GetModuleFileNameEx

【讨论】：

好的，我试过了，但它返回“INVALID HANDLE”错误。我用“DEBUG_PROCESS”创建进程，但我确定句柄很好。我不知道我是否可以将“PROCESS_QUERY_INFORMATION”和“PROCESS_VM_READ”与DEBUG_PROCESS一起使用，我试过了，程序崩溃了..
hmm...我在 LOAD_DLL_DEBUG_EVENT 中捕获了模块的基地址，可能为时过早。

【解决方案2】：

如果您的进程想要访问另一个进程，则它需要具有这样做的权限。这意味着您的进程需要提升权限，或者它必须是其他进程的所有者。

如果您得到错误的名称，您可能使用了错误的句柄。这也可以解释为什么您有时会被拒绝访问。如果您将句柄传递给错误的模块，您可能无法访问它，即使您确实可以访问您想知道其名称的模块。

【讨论】：

但是有些模块名没问题，难道还是权限问题？我从“SymGetModuleBase”得到模块基地址，怎么会出错？
我刚刚将模块基地址与“Process Hacker”输出的内容进行了比较，这很好......