VS2017中Git克隆的C++程序编译通过但无法启动，WinMain断点未触发

问题描述 #

我有一个原本在某台机器上正常运行的应用，通过Git克隆到另一台配置完全相同的机器（Visual Studio 2017、SDK版本10.0.19041.0、141 Build Tools）。该应用在Debug和Release模式下均能无错误编译，但调试启动生成的exe时，程序仅在任务管理器中显示运行，无窗口弹出。此外，在WinMain入口后的第一行设置断点，该断点从未触发。应用中依赖的若干库是使用相同版本的SDK和构建工具编译的。

疑问与需求 #

1. 我假设若库与构建工具不匹配，VS会抛出错误，是否正确？
2. 如何调试这类无法完全启动的应用？第一步应该怎么做？

应用入口代码 #

int WINAPI wWinMain(_In_ HINSTANCE h_instance, _In_opt_ HINSTANCE h_prev_instance, _In_ LPWSTR lp_cmd_line, _In_ int n_cmd_show) 
{
    AllocConsole();
    freopen("conin$", "r", stdin);
    freopen("conout$", "w", stdout);
    freopen("conout$", "w", stderr);
    printf("Debugging Window:\n");

    std::shared_ptr<WindowsContainer> os_container = std::make_shared<WindowsContainer>();
    os_container->hInstance = h_instance;
    os_container->hPrevInstance = h_prev_instance;
    os_container->clientWidth = 3000;
    os_container->clientHeight = 1200;
    ProgramBuilder program_builder(os_container);
    
    if (!program_builder.Init()) return 0;
    
    return 1;
}

解答 #

关于库与构建工具匹配的疑问 #

这个假设不完全正确。VS仅会在链接阶段检查部分不兼容情况（比如32/64位架构不匹配、符号缺失），但像运行时库版本不一致（比如多线程DLL版MD与多线程静态版MT混用）、SDK细微版本差异导致的隐式行为变化这类问题，不会在编译链接阶段抛出错误，只会在运行时引发异常或启动阻塞。

调试步骤：第一步操作 #

优先检查系统应用程序日志：
打开「事件查看器」，依次定位到「Windows日志 -> 应用程序」，找到对应进程ID的错误记录（程序启动失败时通常会在这里留下崩溃信息、模块加载失败提示或初始化错误日志）。这些日志能直接指出启动失败的核心原因，比如某个依赖DLL缺失、系统权限不足、初始化阶段触发的未捕获异常等。

后续辅助排查操作 #

• 使用dumpbin /dependents [你的exe文件路径]命令，检查exe的所有依赖DLL，对比两台机器上这些DLL的存在性和版本号，重点关注VC运行时库（如msvcp140.dll、vcruntime140.dll）和自定义依赖库。
• 临时注释代码中自定义依赖库的初始化逻辑（比如ProgramBuilder::Init()调用），尝试启动程序，看是否能进入WinMain断点，逐步缩小问题范围。
• 直接双击运行生成的exe，观察是否能弹出控制台窗口并输出Debugging Window:，以此判断程序是否执行到了WinMain入口。

内容的提问来源于stack exchange，提问作者Mich