崩溃本质是DLL卸载后窗口过程被再次调用，属确定性use-after-unload；第二次加载时RegisterClass因类名重复返回0且未检查，导致CreateWindowEx传入非法类名而崩溃。
崩溃发生在 DLL 卸载后仍尝试访问其代码或数据（比如窗口过程、全局函数指针、静态对象析构器），本质是“use-after-unload”，不是随机 bug，而是确定性的生命周期错配。
崩溃堆栈里出现 user32.dll!__InternalCallWinProc 或 xxx.dll+0x1234 怎么定位
这类堆栈说明：系统仍在调度该 DLL 中注册的窗口过程（WndProc），但 DLL 已被卸载，内存页可能已被回收或重映射。关键不是看崩溃点，而是看谁还在调用它。
- 用
Process Explorer（Sysinternals）打开目标进程 → 右键 → Properties → Threads 标签，筛选线程调用栈含DispatchMessage/CallWindowProc的线程，确认是否指向已卸载的 DLL 地址段 - 在卸载前加日志：
OutputDebugString(L"[DLL] UnregisterClass(InjectDllWindow)");，再检查是否真执行了UnregisterClass—— 很多崩溃源于没注销类就直接FreeLibrary - 若堆栈中地址是类似
0x7ffef1234567这种高位值，且不在当前任何模块的modules列表里（用 WinDbg 的lm命令确认），基本坐实 DLL 已 unload 但消息循环还在投递
为什么第二次加载 DLL 创建窗口就崩，而第一次正常
因为第一次卸载时没清理干净：窗口未销毁、类未注销、线程未退出、或 FreeLibraryAndExitThread 在窗口消息处理中途强行退出，导致内核中仍保留对该类/窗口的引用。第二次加载时，RegisterClass 失败（返回 0），但代码没检查，后续 CreateWindowEx 传入非法类名，触发 user32 内部断言或静默失败后解引用空指针。
- 每次调用
RegisterClass前必须确保类名唯一；重复注册会失败，返回值为 0 —— 一定要检查：if (!RegisterClass(&wc)) { DWORD err = GetLastError(); } -
CreateWindowEx返回NULL时，GetLastError()通常是ERROR_CLASS_ALREADY_EXISTS或ERROR_INVALID_CLASS，不是“运气不好”，是状态残留 - 不要在
WndProc里直接调用FreeLibraryAndExitThread；应发WM_CLOSE→ 在WM_DESTROY中调用PostQuitMessage→ 等消息循环退出后再卸载
如何让卸载过程可调试、不静默崩溃
Windows 不会在 DLL 卸载时自动报错，必须主动拦截和观测。核心是把“卸载”变成“可观测事件”。
立即学习“C++免费学习笔记（深入）”；
- 在 DLL 入口函数
DllMain的DLL_PROCESS_DETACH分支里，加断点或日志：if (lpReserved == NULL) OutputDebugString(L"[DLL] Detaching – no thread detach");。注意：此时不能调用LoadLibrary、CreateThread等禁止 API - 用 WinDbg 设置条件断点：
bp yourdll!DllMain "j @rdx==3 'gc';'.'"（x64 下@rdx==3表示DLL_PROCESS_DETACH） - 启用 GFlags：运行
gflags /i yourapp.exe +sls，开启“严格 DLL 加载顺序检查”，它会让某些延迟崩溃提前暴露为STATUS_DLL_NOT_FOUND - 最关键的验证动作：卸载后立刻调用
GetModuleHandle(L"YourDll.dll")，如果返回非 NULL，说明没真正卸载——可能是有线程还在跑、有窗口没销毁、或存在隐式引用（如 COM 对象持有 DLL 实例）
真正麻烦的不是崩溃那一瞬间，而是卸载逻辑和 UI 生命周期耦合太紧：窗口销毁、类注销、线程退出、DLL 卸载，这四件事必须串行且有明确完成信号。少一个检查，就埋一个必现的崩溃点。
