简介一套用C实现的守护进程保护方案面向需要防止C#程序被意外终止或强制关闭的Windows开发者。核心思路是在C动态链接库中封装钩子与进程监控逻辑再注入到C#目标进程一旦检测到结束请求便及时拦截已在Win7系统实测有效。压缩包共173个文件约24.32MB既包含完整工程源码C钩子模块、DLL入口、C#调用端、项目与解决方案文件也保留大量编译中间产物与生成结果对象文件、预编译头、日志、依赖库、可执行文件、动态库等便于还原构建流程、分析各模块关系。核心钩子模块配合调试符号文件可深入跟踪。已有683人学习浏览主要适合研究中级Windows进程保护机制、需要参考跨语言调用与系统钩子用法的开发者可据此掌握相关API编排与工程组织方式。1. 守护进程不是“写个循环就完事”这份C守护与进程保护资源到底能解决什么问题写守护进程的程序第一反应就是写个while循环然后Sleep再按进程名判断目标是否存活。真正接手过要长期值班的生产环境后就会明白问题从来不只是“进程挂了没”而是挂了之后怎么拉起、拉起时会不会踩权限、连续崩溃是不是要先停下来。这份C守护进程程序包解决的就是Windows平台下关键进程的保活和保护问题它不是简单轮询工具而是把服务宿主、进程句柄管理、退出码白名单、自启动注册都收拢在一个工程里拿来改改就能变成自己的业务看门狗。适合两类人一是C/S架构里需要盯住后台服务不被误杀或僵死的开发者二是刚开始做Windows系统编程想完整看一遍进程管理链路的人。写进程保护这件事不少人会先想到C#或脚本但C能直接贴住进程API和服务API这套资源走的正是这一条路线。2. Windows进程生命周期管理Job Object、服务宿主与看门狗的三层结构2.1 先拆概念为什么单看“进程还活着”是不够的写进程保护第一件事是要承认一个事实Windows上的进程状态远比“活着/死了”要细腻。进程对象存在、主线程停止、事件循环无响应、句柄泄漏导致系统拒绝服务这些在不同维度上代表了不同的“生命状态”。业务开发常常只盯着任务管理器里那一条绿/红灯等真出问题才发现“任务管理器没红但已经卡死”。举一个实际现场某同学做过一个监控程序每5秒用CreateToolhelp32Snapshot枚举一次进程表发现目标不在了就CreateProcess拉起来。表面上看这套逻辑能覆盖崩溃退出。但它测不出假死某天目标进程的主线程死锁进程表里仍然有记录枚举逻辑认为“进程活着”于是不再干预直到用户反馈服务完全无响应最后人工重启。这就是第一个概念进程存在不等于进程可用。所以在这份C守护进程资源里看门狗不是简单按进程名查表而是同时走句柄等待和心跳检测两条路。句柄等待捕获真正的退出心跳检测捕获僵死。理解这一点之后后面看主循环代码时才不会被“这不是很简单嘛”的错觉带偏。2.2 绑Job Object把子进程绑进“一旦父死全家没”的保护圈Windows下父子进程关系比很多人想的要弱。父进程退出子进程并不会自动结束而是被系统重新挂接变成没有监督者的孤儿进程。对于一个守护场景来说最怕的并不是子进程死掉而是守护进程自己先死掉、子进程脱离控制继续无人值守地跑着。把子进程放进一个Job Object是Windows上通用的解法。所谓Job Object可以理解成一个“进程监狱”内核能对里面所有进程做统一限制和管理。下面这段就是资源里初始化作业对象的写法// 创建并配置作业对象保证守护进程退出时子进程树一并终止 HANDLE hJob CreateJobObjectW(nullptr, LGuard_Job); if (!hJob) { LogError(LCreateJobObject failed, code%u, GetLastError()); return E_FAIL; } JOBOBJECT_EXTENDED_LIMIT_INFORMATION jobLimits {}; jobLimits.BasicLimitInformation.LimitFlags JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE | // 最后一个作业句柄关闭时杀掉全部关联进程 JOB_OBJECT_LIMIT_ACTIVE_PROCESS; // 限制活动进程数量防止无限裂变 if (!SetInformationJobObject(hJob, JobObjectExtendedLimitInformation, jobLimits, sizeof(jobLimits))) { LogError(LSetInformationJobObject failed, code%u, GetLastError()); CloseHandle(hJob); return E_FAIL; }逻辑说明CreateJobObjectW先创建一个命名的作业对象返回内核句柄随后在JOBOBJECT_EXTENDED_LIMIT_INFORMATION里填限位标志再用SetInformationJobObject把配置写回。这里最关键的是KILL_ON_JOB_CLOSE它的语义是“当作业对象的最后一个句柄被关闭时作业中所有进程被强制终止”而不是“父进程退出时子进程就结束”。如果代码里能保证守护进程是最后一个持有作业句柄的进程那么守护进程一退出作业对象引用计数归零内核自然清理所有关联子进程。参数说明LimitFlags里的JOB_OBJECT_LIMIT_ACTIVE_PROCESS用于限制作业里最多同时存在多少进程给未受控的业务加上这一条能防止目标进程因配置错误不断自复制时把系统拖垮若还需要限制内存可以另加JOB_OBJECT_LIMIT_JOB_MEMORY并在对应字段里设置上限。阅读这份资源时可以看到它在拉起子进程后没有只用一个普通的CreateProcess就完事而是立即执行AssignProcessToJobObject把子进程登记进作业这样在守护进程本身被强杀时也避免了“子进程变成黑匣子继续跑”的运维事故。2.3 服务宿主而不是普通控制台为什么守护进程自己要先“变身”再看守护进程存在于哪个运行环境。如果按最简单的路子把它做成一个带控制台窗口的exe双击运行后一直挂着会遇到的麻烦是用户注销后进程可能被系统终止开机自启很难做往启动项里放一个控制台程序会引来安全软件的注意系统关机时它会被直接结束没有机会进入优雅收尾流程任务管理器里它是普通应用身份没有服务恢复选项。这份C守护进程资源里的应对方式是把它改造成一个Windows服务。核心是ServiceMain入口回调里的事件循环在SERVICE_CONTROL_STOP和SERVICE_CONTROL_SHUTDOWN中设置g_bRunning标志让主循环及时退出并先清理子进程。写成代码大概是这样// 服务控制回调响应系统停止/关机请求 void WINAPI ServiceCtrlHandler(DWORD dwCtrl) { switch (dwCtrl) { case SERVICE_CONTROL_STOP: case SERVICE_CONTROL_SHUTDOWN: g_bRunning FALSE; // 通知主循环退出 break; default: break; } } void WINAPI ServiceMain(DWORD argc, wchar_t* argv[]) { g_bRunning TRUE; SERVICE_STATUS_HANDLE hStatus RegisterServiceCtrlHandlerW(LGuardSvc, ServiceCtrlHandler); // 把服务状态置为运行中然后进入主循环主循环见第3章 RunGuardLoop(); }逻辑说明服务控制回调只做标记不直接在回调里做耗时操作这是服务程序铁律。Windows服务控制管理器SCM会在回调执行期间等待响应如果回调里Sleep几秒做清理SCM会认为服务无响应进而触发系统恢复选项把守护进程按“无响应”处理就会出现杀错人的场面。参数说明RegisterServiceCtrlHandlerW里传的服务名要和安装服务时注册的ServiceName一致不一致会返回ERROR_SERVICE_DOES_NOT_EXIST服务根本起不来。安装时可用sc create GuardSvc binPath C:\Guard\guard.exe start auto。把守护进程变成服务宿主还有一个附带收益服务进程天生运行在Session 0与用户桌面隔离权限边界清晰。后续第5章会讲Session 0对UI进程的影响这里先记住“服务身份让守护进程活在系统侧而不是用户侧”。3. 核心实现拆解把守护循环、重启策略与退出码判断写在代码里3.1 主循环长什么样事件驱动的句柄等待而不是傻傻Sleep轮询新手版本大多长这样while (true) { if (!IsProcessAlive(pid)) { LaunchProcess(); } Sleep(5000); }这段代码有问题而且问题不小Sleep期间无法及时响应退出IsProcessAlive如果按进程名查快照进程列表多锁一段还区分不了假死与真死。资源里的主循环是用句柄等待写的// 守护主循环句柄等待 心跳超时 while (g_bRunning) { DWORD waitRet WaitForSingleObject(hTargetProcess, 5000); if (waitRet WAIT_OBJECT_0) { // 子进程句柄有信号代表已退出走退出码判定 DWORD dwExitCode 0; GetExitCodeProcess(hTargetProcess, dwExitCode); HandleChildExit(dwExitCode); // 重新拉起子进程 StartProtectedChild(); } else if (waitRet WAIT_TIMEOUT) { // 5秒内没有退出不代表健康检查心跳时间 if (GetTickCount() - lastHeartbeatTick kHeartbeatTimeoutMs) { LogWarning(Lheartbeat timeout, terminate stale child); TerminateProcess(hTargetProcess, 99); HandleChildExit(99); StartProtectedChild(); } } }逻辑说明hTargetProcess是CreateProcess成功后的进程主句柄WaitForSingleObject等5秒如果返回WAIT_OBJECT_0说明进程对象被系统置为有信号状态也就是进程退出了如果返回WAIT_TIMEOUT则说明5秒内进程还活着但“还活着”在这里不够再用lastHeartbeatTick计算距上次心跳的时间超过阈值就试作假死主动TerminateProcess并按异常退出处理。参数说明kHeartbeatTimeoutMs的取值建议为心跳上报间隔的4-6倍。资源里心跳是一个回调接口业务进程每2秒往共享内存写一个时间戳守护进程读取并比较。太短会拿网络抖动当死太长在假死场景下恢复时间会超过用户容忍度常见的默认值是10秒而心跳间隔2秒。3.2 带白名单的退出码不是所有退出都能触发重启直接把所有非零退出码视为“崩溃”是另一个大坑。业务里有很多良性退出码升级脚本要求重启、维护模式主动退出、命令行参数错误后告警退出后两者如果都重试会变成循环。资源里用了白名单方式// 退出码白名单命中则不做重启 bool ShouldRestart(DWORD dwExitCode) { static const DWORD kAllowedExitCodes[] { 0, // 正常退出 85, // 维护模式主动退出 130 // 收到SIGINT等价信号退出 }; for (auto code : kAllowedExitCodes) { if (dwExitCode code) { return false; // 白名单内的退出码表示有计划退出 } } return true; // 其他退出码视为异常 }逻辑说明函数返回true表示需要重启返回false表示有计划退出不需要做任何事。白名单放在数组里而不是散落在case语句中是为了后续维护时新增一个退出码不至于漏改。一个常见误写是把“退出码0不重启”当默认常识但崩溃现场往往返回的不是0而是业务自身的错误码或负数所以白名单必须按业务实际情况填写。参数说明示例中的85和130要结合业务代码调整。可靠做法是在业务main函数里统一约定主动退出返回固定值、异常被捕获返回另一个固定值把这两类写进白名单剩下的全算异常。资源里的注释也建议把这个列表放到配置文件中维护避免每改一次退出码都重新编译守护进程。3.3 重启延迟是刚需指数退避与启动风暴控制崩溃重启还有个必须处理的问题要不要马上拉如果子进程是启动即崩型的立刻拉就会进入“崩-起-崩-起”的节奏CPU和磁盘I/O会被连续启动风暴吃干。资源里实现了一个带指数退避的重启延迟// 指数退避连续失败时延迟翻倍成功后清零重来 static DWORD currentDelayMs kBaseDelayMs; void ApplyRestartDelay(bool bLastExitOk) { if (bLastExitOk) { currentDelayMs kBaseDelayMs; // 优雅退出后恢复基础延迟 } else { currentDelayMs std::min(currentDelayMs * 2, kMaxDelayMs); } LogInfo(Ldelay before restart: %u ms, currentDelayMs); Sleep(currentDelayMs); }逻辑说明bLastExitOk用来区分“上一次退出是白名单内的良性退出”还是“异常崩溃”。如果是良性延迟复位如果异常延迟翻倍直到封顶值kMaxDelayMs。这样一开始几秒内会快速重试一次给暂时性的瞬断留机会如果长时间失败后续尝试会拉长到几十秒甚至一分钟给系统时间恢复资源。参数说明kBaseDelayMs设为2000ms是相对健康的默认值适合子进程启动时间在几百毫秒到两秒之间的服务若启动需要加载大内存数据或依赖远程数据库基础延迟应更大。kMaxDelayMs设60000是因为一分钟后还没好多半是外部依赖或配置问题此时保持一分钟一次的节奏直到白名单退出或连续失败计数被人工重置。4. 常见问题排查守护进程本身先翻车的五种现场4.1 现象一子进程第一次能拉起挂掉之后守护进程再无反应现象目标进程正常启动手动杀掉之后守护进程日志里只有启动那一条记录之后没有任何新的CreateProcess调用。原因早期的守护代码里hTargetProcess是从第一次CreateProcess中拿到的句柄代表的是“首次那个进程”。等首次进程退出后这个句柄立刻变为有信号再次WaitForSingleObject时还会立即返回WAIT_OBJECT_0但HandleChildExit又拿着旧PID去查询一轮折腾下来非但没拉新进程连状态都乱了。解决每次拉起都重新走一遍完整流程CreateProcess拿到新的HANDLE和PID立刻替换旧句柄旧句柄先CloseHandle避免句柄泄漏。重点是句柄生命周期必须由启动流程统一维护不能只创建一次就永久复用。4.2 现象二开机自启不生效安全软件把守护进程当成可疑启动项现象在装有企业管理级杀软的机器上重启后目标进程没有启动事件日志里有“应用程序被阻止”之类的记录而本机测试一切正常。原因不少安全软件会对“开机即常驻且无发布者签名”的可执行文件做启动拦截尤其当它通过注册表Run键启动时会被当成典型的自启动样本另一个常见原因是普通用户账户下写Run键被UAC重定向到自己的虚拟注册表安装时写进去的值是写给影子路径的当前用户登录时根本读不到。解决优先用Windows服务安装而不是注册表Run键服务由SCM管理启动身份清晰若确实要走注册表自启需要给exe加有效签名并让安装流程在管理员会话中执行。装完服务后把服务恢复选项配上“失败后重启服务”这与守护子进程的逻辑是互补的。4.3 现象三连续崩溃时没有退避延迟CPU被打满现象某个凌晨目标进程配置出错启动即崩守护进程立刻拉起再崩再拉日志里几千行CreateProcessCPU 100%持续半小时。原因代码里没有连续失败计数也没有退避延迟。基础延迟只有2秒每次拉起本身要加载框架和建立连接被反复打断后造成连续启动风暴。启动即崩的瞬间系统还没完全清理新的进程又被丢进来抢占CPU。解决把第3章的指数退避接入异常退出路径统计连续失败次数连续失败达到5次后把延迟提升到30秒以上。另外在重启前检查最近一次崩溃转储文件的时间与大小若间隔过短且体积大先做一次清理再拉起避免磁盘被dmp填满。4.4 现象四子进程需要管理员权限守护进程以普通权限拉不起来现象业务已经设计了提权逻辑但CreateProcess返回ERROR_ELEVATION_REQUIRED或者弹出一个UAC确认框人不在屏幕前启动失败。原因Windows的UAC模型下高完整性级别的进程不能由未提权的父进程直接创建CreateProcess没有帮你提权的功能。守护进程若以普通权限运行想创建一个要求管理员权限的进程就无法绕过UAC弹窗。解决让守护进程以本地系统账户或管理员权限运行最标准的做法是把它做成Windows服务并在安装时指定账户被守护的目标进程若必须访问系统目录也应通过服务账户运行。如果业务上必须交互就需要结合第5章讲的会话机制做成服务端与用户态agent双进程结构。4.5 现象五守护进程退出后子进程成了孤儿还在继续工作现象运维主动kill掉守护进程或者守护进程异常崩溃后目标业务进程依然在跑没人监督也没人拉起。原因没有绑定Job Object或者绑了却没有设置KILL_ON_JOB_CLOSE。有的老代码会尝试用ExitEvent通知子进程退出但守护进程被强杀时事件根本来不及触发你只能在进程树里看到那个孤儿。解决绑定作业对象并设置JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE这是最不依赖“优雅退出”的兜底机制。注意关闭作业对象句柄与关闭普通进程句柄不同前者会一并结束作业里的所有进程。测试时如果发现作业对象句柄在自己进程里还有引用想验证KILL_ON_JOB_CLOSE就会失效必须先关掉所有副本再退出以确认实际效果。5. 进阶边界跨会话保护、心跳检测与守护进程自身防篡改5.1 服务宿主跨会话的细节Session 0隔离对UI进程意味着什么Windows服务默认跑在Session 0而普通用户桌面应用跑在Session 1或更高。这意味着守护进程可以拉起一个业务子进程但该子进程如果在Session 0里创建窗口用户桌面是看不到的。很多人第一次把服务版守护拉起来后发现“进程在跑但桌面上找不到界面”就是踩了这个坑。跨会话给用户界面提供服务时不能简单CreateProcess正确做法是服务端留一个用户态agent图形界面由agent在用户会话中启动服务端只通过IPC下发状态与重启指令。更简单的一种妥协方案不把业务进程做成UI进程而做成一个无窗后台服务界面另外用一套web管理端或桌面小程序。资源里对这一点有清晰划分哪个会话创建UI就由哪个进程接管UI的启动参数服务进程只负责状态与保活。混用会话会导致窗口“消失”、权限拉扯以及互发消息失败这些都是运行很久才会暴露的隐性故障。5.2 守护进程自身怎么防替换与防篡改要保护目标进程守护进程自身的安全也不能忽略。Windows上做不到“不能被卸载”但能做到“被替换时被发现”。简单做法是启动时做一次镜像哈希自校验// 守护进程自校验用配置文件里的基线哈希比较当前exe std::wstring selfPath GetModuleFilePath(); std::string currentHash ComputeSha256(selfPath); std::string baselineHash LoadConfigString(Lguard, Lself_hash); if (currentHash ! baselineHash) { Logger::WriteError(Lguard self-check failed, refuse to start); ExitProcess(100); }逻辑说明GetModuleFilePath拿到自身exe路径ComputeSha256计算整个文件哈希与配置文件里存的基线比较不一致则拒绝启动阻止“把守护进程替换成恶意同名牌”式的操作。参数说明这个自校验只能防外部文件替换防不了先拿基线跑一遍再写恶意代码的攻击但作为低成本基线足够。更严谨的方案是做数字签名校验不过会增加PE签名验证代码量不属于守护逻辑的核心资源里把它做成长度可控的独立模块。5.3 心跳检测的极简实现共享内存里的时间戳业务进程上报心跳最简单的做法是创建一块命名共享内存每2秒写一次时间戳守护进程读这块内存发现时间戳陈旧即视为僵死。命名共享内存比内核事件的优势在于读写成本低也不占用事件对象资源// 业务侧心跳上报伪代码 HANDLE hMapping CreateFileMappingW( INVALID_HANDLE_VALUE, nullptr, PAGE_READWRITE, 0, sizeof(DWORD), LGlobal\\Guard_Heartbeat_01); DWORD* pTimeStamp (DWORD*)MapViewOfFile(hMapping, FILE_MAP_WRITE, 0, 0, sizeof(DWORD)); while (g_running) { *pTimeStamp GetTickCount(); Sleep(2000); }逻辑说明CreateFileMappingW创建带名字的共享内存区域MapViewOfFile拿到可写指针业务进程每2秒覆盖时间戳。守护进程侧以只读方式打开同一块共享内存比较与GetTickCount()的差值是否超过阈值。参数说明共享内存只存一个DWORD时间戳所以区域大小只开4字节名字带Global前缀让跨会话可访问但前提是服务进程具备相应权限。资源里没有采用按进程创建时间推断活性的方案因为时间戳直接来自业务自身不受进程重建影响更准确。5.4 与Windows自带恢复功能共存而不是互斥Windows服务属性里自带“失败后重启”的恢复选项那还需要自定义守护进程吗需要。原因有两点Windows服务恢复只对服务本体负责如果业务子进程是由服务内部启动的派生进程它退出后SCM感知不到服务恢复也不能区分退出码它无法判断某次退出是计划内还是异常。两条线是互补的用服务恢复选项保护“守护进程本身”用这份守护逻辑保护“子进程生命周期、心跳与退出码”。生产环境里这两条缝都要堵上只依赖任何一边都会在特定场景下漏风比如子进程被误杀时服务本身依然健康SCM永远不会介入。6. 用故障注入验证守护是否可靠一个值得养成的测试习惯守护进程写完之后验证不能只看“能启动”要主动把进程搞死、搞僵、搞没。我把自己的测试流程整理成三步故障注入法每次改动守护逻辑后强制跑一遍。第一步杀掉子进程。用taskkill /PID 目标进程或者更接近真实场景一点给进程发送异常退出信号。观察点守护进程是否发现退出是否遵守退出码白名单做出重启决策重启延迟是否符合退避策略。第二步把子进程挂起。任务管理器里没有挂起按钮一般用调试工具直接把目标主线程挂起模拟“进程在但永远不干活”的假死态。观察点心跳超时能不能被守护进程识别为僵死TerminateProcess之后的重启链路是否正常。第三步杀掉守护进程本身。因为开了KILL_ON_JOB_CLOSE子进程应当随之结束不能残留如果发现子进程还在跑优先检查作业对象句柄是否还有副本没释放最典型的坑是CreateProcess返回的进程句柄在代码里一直开着没关等于自己多持有了一个引用计数。完成故障注入后还要看一遍资源消耗重启前后句柄数、CPU和内存曲线差异连续崩溃后系统是否平稳。曾经某次测试发现重启总是卡在“磁盘I/O等待”上查了两天才定位到子进程每次崩溃后都会产生一个巨大的转储文件重启时间被拉到比崩溃还长。从那以后我每次迭代守护逻辑都强制走一遍这三步测试把所有数据留存下来再改任何参数都有依据。希望帮到你。本文还有配套的精品资源点击获取