RemedyBG断点不命中主因是PDB缺失或编译未启调试信息：需确保MSVC用/Zi、Clang用-g，禁用/DEBUG:FASTLINK，PDB与二进制同目录或配置Symbol Paths；附加进程需管理员权限，启动游戏应通过Launch Process并设工作目录和环境变量。
RemedyBG 启动后不加载符号或断点不命中
根本原因是调试器没找到 PDB 文件，或者编译时没生成调试信息。Visual Studio 默认生成 .pdb，但若用 CMake + Ninja 或自定义构建流程，容易漏掉 /Zi（MSVC）或 -g（Clang/LLVM）编译选项。
- 确认编译命令含
/Zi（MSVC）或-g（Clang），且链接时未加/DEBUG:FASTLINK（它会禁用完整 PDB） -
PDB必须和.exe或.dll在同一目录，或 RemedyBG 中通过Settings → Symbol Paths手动添加路径 - 如果用 Unity 或 Unreal，确保构建为
Development或Debug Editor模式，而非Release—— 后者默认剥离符号 - RemedyBG 不支持增量 PDB（
/ZI），必须用/Zi；否则断点会显示为「pending」且永不触发
在 RemedyBG 里附加到正在运行的游戏进程（如 Steam 游戏、DX11/12 应用）
附加失败常见于权限不足或目标进程启用了调试保护。RemedyBG 本身不带管理员权限启动，而多数游戏（尤其全屏独占渲染的）会拒绝非特权调试器附加。
- 右键 RemedyBG 快捷方式 →「以管理员身份运行」，再点
File → Attach to Process - 若列表里看不到目标进程，检查是否勾选了
Show system processes（但通常游戏不在系统进程里）；更可能是进程开启了DisableThreadLibraryCalls或调用了IsDebuggerPresent反调试逻辑 - 对于 DX12/Vulkan 游戏，RemedyBG 能正常下断、查看寄存器和内存，但无法直接查看 GPU 状态（那是 RenderDoc / Nsight 的事）
- 附加后若立即崩溃，大概率是目标已启用
SetProcessMitigationPolicy中的ProcessDebugObjectHandleMitigation—— 此时只能改用源码启动模式（见下一条）
用 RemedyBG 启动游戏主程序并自动加载所有模块（DLL、插件、脚本运行时）
直接双击 exe 启动会导致 RemedyBG 无法捕获 DLL 加载事件，从而错过对插件或热更模块的调试入口。正确做法是让 RemedyBG 成为父进程，接管整个启动链。
- 在 RemedyBG 中点
File → Launch Process，填入完整路径（如C:\game\MyGame.exe），不要用相对路径 - 工作目录（
Working Directory）必须设为游戏根目录，否则LoadLibrary会找不到插件 DLL - 若游戏依赖环境变量（如
VULKAN_SDK、PATH），需在Environment栏手动补全，RemedyBG 不继承父 shell 的全部变量 - 勾选
Break on module load：这样每次LoadLibrary或dlopen都会中断，方便你在第三方 DLL 入口（如DllMain）下断点
RemedyBG 调试多线程桌面应用时，线程切换混乱、调用栈错乱
这不是 bug，而是 RemedyBG 的线程视图默认按 OS 线程 ID 排序，而 C++11 std::thread 或 Windows CreateThread 创建的线程 ID 和调试器看到的并不总对得上，尤其当线程快速创建/退出时。
立即学习“C++免费学习笔记（深入）”；
- 别依赖线程名（
SetThreadDescription）来识别——RemedyBG 目前不显示它；改用日志打点 +GetCurrentThreadId()输出 ID 对齐 - 在关键临界区前后手动插入
__debugbreak()，比依赖断点更可靠；RemedyBG 对__debugbreak响应极快，且不会被优化掉 - 若看到调用栈里出现
ntdll.dll!NtWaitForMultipleObjects卡住，大概率是线程在等锁或条件变量，此时切到Threads窗口右键对应线程 →Suspend，再看其他线程状态 - RemedyBG 不支持“冻结其他线程”调试（像 VS 的“Freeze All Except This”），所以调试竞态问题时，优先加
std::this_thread::sleep_for插桩，而非盲目单步
