如何找出我的 .exe 的入口点函数？答案

【问题标题】：How do I find out my .exe's entry-point function?如何找出我的 .exe 的入口点函数？
【发布时间】：2014-07-09 06:40:53
【问题描述】：

我觉得问这个问题很愚蠢，但请耐心等待，并在评论“它是main()，duh”之前阅读症状。

我正在使用 Visual Studio Express 2012 开发一个项目。迄今为止，我们只为 Win32 (x86) 平台构建，但我正在将 .exe 构建转换为 64 位。我现在有一个完全链接的 .exe，但在此过程中发生了一件有趣的事情：不再调用入口点。

（C++，控制台）程序的入口点是在文件范围内声明的具有以下签名的 C++ 函数：int main(int argc, char * argv[])。从第一天起，这个函数就在 x86 可执行文件中愉快地工作了。它没有在 x64 上被调用：

链接器不会抱怨它找不到入口点。
加载程序不会抱怨它找不到入口点。
当我从命令行运行 exe 时，它会立即启动并退出，退出代码为 127。
gdb，例如，说“在启动期间程序退出，代码为 0xc000007b。”
在 stdout 或 stderr 上没有任何输出。
如果我在main 中加入有趣的东西，比如int * p(nullptr); *p = 5;，程序不会崩溃（即使没有这个，我也可以肯定main() 没有运行）。

什么可能导致此问题？我该如何调试它？由于我的代码都没有运行过，因此我不确定在调试器中的何处设置断点...

【问题讨论】：

“我把有趣的东西放在 main 中，比如 int * p(nullptr); *p = 5;，程序不会崩溃” 这并不能证明什么
main 不是程序中要执行的第一个代码。要执行的第一个代码是编译器生成的用于调用静态构造函数等的代码。在that之前运行的代码属于操作系统；它负责加载您的代码所依赖的库。此错误似乎发生在操作系统代码中。

【解决方案1】：

0xc000007b 是 STATUS_INVALID_IMAGE_FORMAT。也就是说，操作系统甚至永远不会加载足够远的二进制文件来开始执行它。

您的编译设置可能有问题。但是，通常当我看到这个错误时，问题出在 64 位应用程序试图动态链接到 32 位 DLL。

检查您的库，并验证您的路径指向任何 DLL 的 64 位版本。

【讨论】：

【解决方案2】：

errlook 实用程序显示 127 是“找不到指定的过程”。在 <winerror.h> 中搜索该文本得到 ERROR_PROC_NOT_FOUND。

这听起来像是一个 DLL 问题。

现在我不喜欢将“入口点”一词应用于main，因为应该调用入口点，即您提供给链接器以设置入口点的地址？ 启动功能可能会更好。这不仅仅是在狡辩：微软的技术作家们已经把自己彻底搞糊涂了，以至于现在 20 年来关于 PE 入口点的不正确且自相矛盾的文档可以庆祝了。我想，他们永远不会做对。

gdb 在我的经验中非常不可靠，不是检查是否调用某事的好工具。这是不可靠的，至少当它检测到我是用户时。而是在main 中做一个消息框或其他容易识别和保证的东西。

【讨论】：

【解决方案3】：

您可以通过 /ENTRY 编译器标志找到（并修改）exe 的入口点。

在 Visual Studio 开发环境中设置此链接器选项

【讨论】：

-1 混淆main 和您为Microsoft 的链接器设置的机器代码级入口点/entry 不是一个好主意。我没有关注您提供的链接，但很可能是微软关于入口点的错误和误导性文档，现在已经运行了 20 多年。不要相信它：使用适当的工具来检查。
由于他使用的是 Visual Studio，我认为此信息可能有用，因为这是使用其编译器标志覆盖入口点的方法。但是，您说得对，它遗漏了很多细节。