0xc000007b错误表示程序在main函数执行前因架构不匹配（如32/64位dll混用）或vc++/directx运行库缺失损坏而被系统拒绝加载，需优先安装v14.50.35719.0双架构运行库并重启。
编译通过但运行出错，大概率不是语法问题，而是运行时环境、资源状态或逻辑路径没兜住——这类错误不会在 g++ 或 cl.exe 阶段报错，但一跑就崩、卡死、结果错或弹窗提示 0xC0000005、0xc000007b、std::runtime_error 之类。
检查运行库版本和架构是否匹配
VC++ 程序在另一台机器上“编译过了，一运行就报找不到 vcruntime140.dll”或直接崩溃，90% 是运行库缺失或版本太旧。尤其用 VS 2022 17.10+ 编译的程序，依赖新版 msvcp140.dll 中的 std::mutex 实现，旧版运行库（如 14.32）不支持，就会访问冲突。
- 先看错误提示：如果明确说“找不到 XXX.dll”，去微软官网下最新
Microsoft Visual C++ 2015–2022 Redistributable，x86 和 x64 都装（64 位系统也要装 x86 版，因为很多老程序是 32 位） - 如果没报 DLL 缺失，但崩溃码是
0xc000007b，优先怀疑架构错配（比如 64 位程序加载了 32 位 DLL，或反之），用Dependency Walker或dumpbin /headers查目标 EXE 和所用 DLL 的机器类型 - 注意程序目录下的“私有 DLL”：有些软件自带旧版
msvcp140.dll，会优先加载它，覆盖系统新版——删掉或重命名试试
确认 OpenGL 扩展函数是否已初始化
像 glGenBuffers、glBindBuffer 这类 GL 1.5+ 函数，在 Windows 上不能直接调用，因为系统 opengl32.dll 只导出到 GL 1.1。必须靠 GLEW/GLAD 等扩展加载器初始化后才能用，否则指针是空的，一调就 0xC0000005（读取地址 0x00000000）。
-
glewInit()必须在创建并激活 OpenGL 上下文之后调用，即wglMakeCurrent(hDC, hRC)之后；MFC SDI 中常漏掉这步，导致glewInit()返回非零值（失败），但代码没检查就继续调用扩展函数 - 不要在
main()或全局作用域里提前调glewInit()，此时没有上下文，必然失败 - GLAD 用户同理：
gladLoadGLLoader((GLADloadproc)wglGetProcAddress)也必须在wglMakeCurrent后
排查未捕获异常和非法内存访问
崩溃前没弹具体错误，只看到进程退出或黑屏？很可能是 std::terminate() 被触发，根源通常是未捕获的异常，或者段错误（SIGSEGV）。
- 在
main()最外层加try { ... } catch (const std::exception& e) { std::cerr ，至少能捞出 <code>std::runtime_error类异常 - 解引用空指针、数组越界、
vector::at()越界、释放后使用（悬垂指针）、多线程竞态写同一变量——这些都可能当场段错误。用-fsanitize=address编译（Clang/GCC）或/RTC1（MSVC）能快速定位 - 别信“这段逻辑不可能走到那里”——加日志或断点，验证实际执行路径；
assert()在 Debug 下有用，但 Release 下默认不生效
留意预编译头和链接符号问题
某些“编译过、链接过、一运行就崩”的现象，其实发生在更底层：符号没正确定义，或预编译头顺序错乱，导致运行时调用到了野地址。
- MFC 工程中，
#include "stdafx.h"必须是每个.cpp文件的第一行，否则预编译机制失效，可能导致类定义不可见、虚函数表错乱，运行时跳转到随机地址 - LNK2001/2019 错误虽属链接阶段，但有时被忽略（比如只在输出窗口闪一下），结果生成的 EXE 调用未实现的函数，运行时直接崩。用
dumpbin /symbols查 OBJ 是否真导出了对应符号 - 全局对象构造顺序不确定：如果 A 的构造函数依赖 B，但 B 还没构造，就可能访问未初始化内存——避免跨编译单元的静态对象强依赖
真正难调试的，往往是多个条件叠加：比如运行库版本旧 + 程序自带旧 DLL + 某个扩展函数未初始化 + 异常又没捕获。这时候得一层层剥，先确保环境干净（全新系统/虚拟机复现），再逐项排除。别跳步。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
