控制台程序关闭窗口后进程残留，是因未正确处理CTRL_CLOSE_EVENT信号；需用SetConsoleCtrlHandler注册处理器并主动清理资源，否则主线程阻塞或子线程未回收会导致假退出。
任务管理器里看不到进程，但 cmd 窗口关了程序还在跑？
这是 Windows 控制台程序（CONSOLE 类型）常见的“假退出”现象：用户点了关闭按钮（×），窗口消失，但主进程没真正终止。根本原因不是卡死，而是程序没响应 CTRL_CLOSE_EVENT 或没正确处理控制台关闭信号。
常见诱因包括：
- 主线程阻塞在
std::cin、getchar()、WaitForSingleObject()等同步等待上，且未设置控制台事件回调 - 用了
SetConsoleCtrlHandler(NULL, TRUE)屏蔽了所有控制台信号（包括关闭） - 子线程仍在运行，而主线程已退出但进程未被回收（如未调用
CloseHandle()或线程未join()）
怎么快速定位残留进程是不是你的程序？
别只盯任务管理器的“名称”，控制台程序默认显示为 conhost.exe 或 cmd.exe，真实进程名可能被掩盖。用命令行查更准：
tasklist /fi "imagename eq your_program.exe"
如果返回空，试试查父进程链：
立即学习“C++免费学习笔记（深入）”；
wmic process where "name='conhost.exe'" get name,processid,parentprocessid,commandline
重点看 commandline 字段——里面常含你程序的路径或参数。若看到类似 "C:\path\to\your_program.exe"，那就是它。
注意：conhost.exe 本身是 Windows 控制台宿主，不等于你的程序；但它的 parentprocessid 指向你的 exe 进程 ID，这才是真身。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
程序里怎么正确响应控制台关闭？
必须显式注册控制台事件处理器，不能依赖默认行为。关键点：
- 用
SetConsoleCtrlHandler()注册回调函数，且返回值为TRUE（表示已处理，系统不再强制终止） - 回调函数里做清理（如设退出标志、唤醒阻塞线程、关闭句柄），然后主动调用
ExitProcess()或让主线程自然退出 - 避免在回调中调用
printf、std::cout等可能引发死锁的 CRT 函数（Windows 控制台 I/O 在信号上下文中不安全）
最小可行示例：
BOOL CtrlHandler(DWORD fdwCtrlType) {
if (fdwCtrlType == CTRL_CLOSE_EVENT) {
// 设置全局退出标志，通知工作线程停止
g_exit_requested = true;
// 唤醒可能阻塞的线程（如 WaitForSingleObject）
SetEvent(g_shutdown_event);
return TRUE; // 表示已处理
}
return FALSE;
}
// 主函数开头注册
SetConsoleCtrlHandler(CtrlHandler, TRUE);调试时怎么确认是卡在哪儿？
别靠猜。直接用 procdump 或 WinDbg 抓进程快照：
procdump -ma your_program.exe dump.dmp
然后用 WinDbg 打开 dump.dmp，执行：
~* kb
看所有线程的调用栈。重点关注：
- 主线程是否停在
ReadConsoleInputA、WaitForMultipleObjects、sleep等等待函数 - 是否有线程卡在临界区（如
EnterCriticalSection后没出来） - 是否在调用
free()或delete时卡住（可能堆损坏或锁竞争）
如果 dump 显示所有线程都在 sleep 或 wait，但没响应关闭——基本就是没装控制台处理器，或者处理器里没做有效唤醒。
真正的难点不在发现残留，而在确认那个“看似退出”的瞬间，你的代码有没有把所有资源归还、所有线程收拢、所有句柄关闭。漏掉一个 CreateThread() 没 WaitForSingleObject()，就足以让进程悬在后台不动声色。
