简介一套用于演示C#程序防任务管理器结束的示例工程面向需要了解进程保护与抗结束机制的Windows开发者、WinForms程序员。资源围绕权限提升、系统钩子、守护线程、服务化及自保护等主流思路提供可编译的Visual Studio解决方案既适合入门理解进程模型也可作为二次开发的基础框架。压缩包共29个文件含6个C#源码、3个可直接运行的exe、3个config及dll/pdb等调试信息整体仅57KB结构简洁便于快速查看核心逻辑并运行测试。已有2268人学习下载是同类进程中保护主题下较受关注的示例。下载后可直接打开工程查看窗体实现与权限控制代码配合exe程序实测结束进程时的表现能直观对比不同防护策略的适用场景和局限性为真实项目中的防退出、看门狗或服务化设计提供参考。1. 任务管理器结束不了你的 C# 程序先立住一个底线认知先说结论任务管理器结束不了的进程在纯用户态层面是不存在的。管理员权限下的taskkill /f可以结束掉绝大多数普通程序这是 Windows 内核设计上给管理者的权力程序自己无法越权豁免。所以“防止被任务管理器结束”这件事真正能实现的目标是普通用户双击进程、点“结束任务”时发现杀不掉或者刚点完结束它又原地复活。这个诉求在考勤终端、信息发布屏、数据上报客户端、内部工具软件里很常见主程序一旦被员工随手结束现场就要出问题。本文给的方案核心是用三层手段叠出一个“看起来很难被结束”的 C# 程序服务托管让任务管理器按钮变灰双进程互拉让进程“死了又活”外加进程 DACL 收紧让TerminateProcess被拒绝适合想把进程保护做到用户态极限的桌面应用开发者。2. 技术选型服务托管、双进程互拉、内核回调三条路怎么权衡2.1 任务管理器结束进程的底层机制任务管理器点“结束任务”时最终调用的是TerminateProcess。这个 API 的执行条件有两个调用方拿到目标进程句柄并且该句柄具备PROCESS_TERMINATE权限。任务管理器以当前登录用户身份运行而进程默认安全描述符允许创建者完全控制所以绝大多数普通程序在任务管理器面前就是一扇没上锁的门。要阻止它思路就三条让目标进程的句柄拿不到、让句柄不具备结束权限、或者让进程结束后再拉起来。第一招做不到因为OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION)这类查询权限拿句柄拦不住第二招可以改进程对象安全描述符但有副作用第三招是双进程互拉最实用。把三招组合起来就是本文的核心方案。2.2 三条实现路径对比方案实现难度对普通用户效果对管理员效果杀软误报风险适用场景服务托管低结束按钮直接灰色服务可被停止低无界面后台程序双进程互拉中结束一个另一个拉回两个同时结束就破功中前台界面程序进程 DACL 限制中高TerminateProcess被拒管理员可还原描述符低配合以上方案内核回调拦截极高效果最强签名驱动才能用极高商业安全软件内核回调方案需要写驱动、做签名、过杀软审核普通业务应用不该碰。进程 DACL 单独用也不好使因为管理员随时能重置安全描述符而且自己程序要正常退出也可能受影响。所以我实际落地的组合是服务托管 双进程互拉 可选 DACL 收紧三层各自挡住一类操作。2.3 选型结论与目标定位这套方案能防住的是一种人懂一点 Windows、会打开任务管理器尝试结束进程的普通用户。防不住的是知道sc stop、能提权、会改注册表的人。所以给需求方沟通时我一般先把预期讲清楚这是增加结束成本不是绝对免疫。面向普通员工的终端类软件做到这个程度已经能解决 95% 的现场问题。3. 双进程互拉落地看门狗复活逻辑与关键参数3.1 互拉的进程模型设计双进程互拉的核心结构是主程序MainApp.exe和守护程序GuardianApp.exe。主程序负责实际业务守护程序纯粹做看门狗。两边各挂一个定时器每隔几秒用Process.GetProcessesByName检查对方进程是否还在不在了就Process.Start拉起来。需要注意两个进程不能互相用普通的方式启动完就结束否则会出现“我拉起了你但我随后退出”的死循环。常见做法是启动时附加命令行参数区分角色static void Main(string[] args) { bool isGuardian args.Contains(--guardian); if (isGuardian) { StartGuardianLoop(); // 守护主程序 } else { StartMainAppLoop(); // 主程序顺带守护守护进程 } }启动互相拉起时要带上对应参数例如主程序拉起守护进程用Process.Start(guardianPath, --guardian)守护进程拉起主程序用Process.Start(mainPath, )。参数不对会导致进程反复自我拉起这是最常见的第一坑。3.2 看门狗轮询代码实现下面是守护进程的看门狗逻辑也是这套方案的核心循环private static void StartGuardianLoop() { var timer new System.Timers.Timer(3000); // 3 秒检查一次 timer.Elapsed (s, e) { // 检查主程序是否存活 var procs Process.GetProcessesByName(MainApp); if (procs.Length 0) { Process.Start(C:\App\MainApp.exe); } }; timer.Start(); // 保持进程存活直到被系统终止 Thread.Sleep(Timeout.Infinite); }检查间隔设为 3000 毫秒是多次实践后的折中太快容易在系统忙碌时误判太慢则用户结束进程后要等半天才复活。主进程那边对守护进程也做同样的检查但复活时带--guardian参数private static void StartMainAppLoop() { var timer new System.Timers.Timer(3000); timer.Elapsed (s, e) { var procs Process.GetProcessesByName(GuardianApp); if (procs.Length 0) { Process.Start(C:\App\GuardianApp.exe, --guardian); } }; timer.Start(); // 主程序业务逻辑继续运行 Application.Run(new MainForm()); }这段逻辑的关键点在于守护进程和主程序都没有窗体响应卡死的判断只做“进程对象是否存在”的轮询。所以哪怕目标进程假死、无窗口响应守护进程也不会去重启它。是否需要处理无响应场景取决于业务性质后面避坑章节展开。3.3 进程存在但立刻退出的处理轮询逻辑还有一个细节GetProcessesByName返回结果时进程对象可能正处于退出阶段你刚Start起来它又因为自身启动参数异常退出。所以复活后建议加一个短暂的观察窗口确认进程稳定存活Process.Start(C:\App\MainApp.exe); Thread.Sleep(500); var afterStart Process.GetProcessesByName(MainApp).Length; if (afterStart 0) { Log(MainApp start failed, will retry in next cycle); }这个日志很重要。很多场景下主程序启动失败是因为依赖项没装、路径不对、环境变量缺失而不是被任务管理器结束。如果你不看日志会误以为是保护机制失效实际是程序本身起不来。4. 服务化与权限加固让“结束任务”按钮变灰的关键配置4.1 服务托管设计双进程互拉能防桌面进程的相互结束但治不了“两个进程同时被杀”的极端情况。要让保护层级更高就得把其中一端放到任务管理器够不着的地方——Windows 服务的进程由服务控制管理器管理普通用户在任务管理器的“详细信息”里对服务进程点“结束任务”按钮是灰色的。在“服务”页签里只有“停止服务”而停止服务通常需要管理员确认。服务端不适合直接承载界面程序因为 Vista 之后会话隔离服务跑在 Session 0主界面程序跑在用户会话里两者不能直接互相操作。所以常见做法是服务进程做纯看门狗主程序照常是桌面进程。服务负责重启主程序主程序负责确认服务没被停止。服务这部分我用ServiceBase写public partial class AppGuardService : ServiceBase { private System.Timers.Timer _timer; public AppGuardService() { InitializeComponent(); ServiceName AppGuardSvc; } protected override void OnStart(string[] args) { _timer new System.Timers.Timer(3000); _timer.Elapsed (s, e) { if (Process.GetProcessesByName(MainApp).Length 0) { Process.Start(C:\App\MainApp.exe); } }; _timer.Start(); } protected override void OnStop() { _timer?.Stop(); } }这里有个重要限制服务以LocalSystem或LocalService账号运行它启动的进程默认继承服务账号的会话窗口不会出现在用户桌面。很多开发者在这里翻车——服务确实把主程序拉起来了但桌面上看不见窗口任务栏也没有图标。一个绕开会话隔离的办法是改用任务计划程序来启动主程序而不是直接用Process.Start。任务计划程序可以指定进程在登录用户的会话中运行这在 C# 里可以用TaskService库来创建一次性任务但每次拉起都创建任务很重维护成本高。我通常的做法是服务只管“拉起后台工作的核心进程”核心进程长驻系统托盘并负责拉起界面进程形成一个级联恢复链条。4.2 进程 DACL 收紧让 TerminateProcess 被拒绝除了服务托管还有一招可以在用户态继续加固修改进程对象的安全描述符把当前登录用户的PROCESS_TERMINATE权限拒绝掉。这样即使用户拿到句柄TerminateProcess也会报“拒绝访问”。C# 调用SetKernelObjectSecurity比较绕用 SDDL 字符串方式最直接[DllImport(advapi32.dll, SetLastError true)] static extern bool ConvertStringSecurityDescriptorToSecurityDescriptor( string StringSecurityDescriptor, uint StringSDRevision, out IntPtr SecurityDescriptor, IntPtr SecurityDescriptorSize); [DllImport(kernel32.dll, SetLastError true)] static extern bool SetKernelObjectSecurity( IntPtr Handle, uint SecurityInformation, IntPtr SecurityDescriptor); const uint DACL_SECURITY_INFORMATION 0x00000004; public static void BlockTerminateForCurrentUser(IntPtr processHandle) { // SDDL: 拒绝 Everyone 组对进程的 TERMINATE 权限(0x1) string sddl D:(D;;0x1;;;WD); IntPtr pSecurityDescriptor IntPtr.Zero; ConvertStringSecurityDescriptorToSecurityDescriptor( sddl, 1, out pSecurityDescriptor, IntPtr.Zero); SetKernelObjectSecurity(processHandle, DACL_SECURITY_INFORMATION, pSecurityDescriptor); }SDDL 字符串D:(D;;0x1;;;WD)的含义是给 Everyone 组添加一个拒绝 Ace拒绝权限码0x1也就是PROCESS_TERMINATE。这样任务管理器调用TerminateProcess时会触发“拒绝访问”。为什么权限码是 0x1因为 Windows 进程权限中PROCESS_TERMINATE的值就是 1。这个方案有个副作用程序自身调用Environment.Exit或正常退出时如果内部有清理逻辑需要结束进程也会因为这个 Deny 而失败。我一般只在部署脚本里对指定进程应用不在业务代码里每次启动都执行。而且即使这样管理员依然可以先还原安全描述符再结束进程所以这层只能用来增加操作门槛。4.3 服务注册与部署顺序写好服务后部署时用管理员命令行执行注册服务注册这类操作我在交付脚本里固定这几行sc create AppGuardSvc binPath C:\App\AppGuardService.exe start auto sc description AppGuardSvc MainApp protection service sc failure AppGuardSvc reset 86400 actions restart/30000/restart/60000/restart/90000 sc start AppGuardSvcsc failure设置的是服务自身被异常终止后的自动恢复策略30 秒后重启再失败 60 秒后再重启第三次 90 秒后重启。这样即使管理员能停服务普通用户通过任务管理器也拿它没办法。部署顺序是先装服务再启动主程序最后施加 DACL 策略——因为 DACL 一旦生效你自己的监控脚本去结束进程也会失败。5. 避坑五个最容易翻车的部署场景5.1 守护进程先死主程序退出后没人拉现象主程序被结束守护进程也被结束两边都死了系统里只剩一个没任何反应的孤儿服务。原因互拉模型最大的死穴是“同时死亡”。解决不要只依赖双进程互拉把服务端作为第三层兜底。服务端的定时器即使在互拉崩溃后仍然存在服务进程本身由 SCM 守护普通用户无法一键结束。5.2 服务拉起的界面程序显示不出来现象服务确实把主程序进程拉起来了CPU 有占用但桌面上没有窗口。原因Vista 以后的会话隔离Session 0 的服务进程启动的子进程默认在 Session 0 里普通用户桌面的 Session 1 看不到。解决不要用服务直接拉界面程序。改成服务拉一个无界面的核心进程核心进程再通过进程间通信提醒主程序启动界面或者干脆让主程序作为常驻进程先启动服务只负责重启它。5.3 DACL 收紧后自己的卸载脚本失效现象执行卸载脚本时taskkill结束不了进程导致程序卸载到一半卡住。原因SDDL 里的 Deny Ace 对所有登录账号生效包括卸载脚本和服务管理账号。解决卸载前先重置安全描述符。我一般把卸载动作做成两步先恢复默认 DACL再结束进程。恢复动作可以用ConvertStringSecurityDescriptorToSecurityDescriptor(D:(A;;GA;;;WD))把完全控制重新授予 Everyone这样taskkill就能正常工作了。5.4 杀软把互拉行为当成木马特征现象部署后杀软弹窗提示“检测到可疑行为进程反复创建其他进程”。原因双进程互拉是病毒最常见的自保护手段之一杀软的主动防御会把这个模式归为风险行为。解决给两个程序集都做数字签名并提交杀软白名单。同时避免用“进程自杀式守护”这种异常模型改成单向保护服务守护主程序、主程序守护服务状态但不互拉特征就温和很多。5.5 测试时怎么结束都不生效最后发现是管理员权限现象用任务管理器能正常结束进程保护逻辑形同虚设。原因测试人员在管理员权限下操作管理员天然拥有SE_DEBUG_PRIVILEGE这个特权在OpenProcess时可以绕过大部分 DACL 限制。解决保护方案的设计目标就不是管理员测试时必须用普通用户会话验证。如果业务确实需要防管理员用户态已经到极限只能走驱动方案成本完全不一样。6. 验证与进阶用任务管理器反复结束来测保护强度我刚部署完一套互拉方案时总喜欢用一套固定流程自测以普通用户身份登录打开任务管理器在主程序和守护进程上轮流点“结束任务”观察复活时间再同时选中两个进程一起结束看服务端的兜底是否生效。验证时我会把检查间隔临时调到 1000 毫秒这样能看到 1 秒内的复活实际部署再调回 3000 毫秒避免轮询太频繁。另一个验证点是进程句柄隔离结束前先记录两个进程的 PID 和启动时间结束时看任务管理器是否报“拒绝访问”报了这个错说明 DACL 生效。同时我会在系统日志里加一条自定义事件源记录每次复活动作的时间和触发者方便回溯问题。进阶做法是给主程序加窗口心跳。很多场景下进程活着不代表业务正常看门狗可以额外检查主程序是否响应。我一般会在主程序里每 30 秒写一个心跳文件服务端检查心跳文件的修改时间超过 2 分钟未更新就重启主程序。这个比单纯检查进程存在更可靠缺点是增加了磁盘写入固态硬盘上影响不大。另外推荐把互拉逻辑收敛成一个独立类库主程序和守护进程共用这样两边的定时器间隔、启动路径、日志开关都在一个地方配置。从那以后我每次部署完都会强制走一遍“杀一次、等复活、看日志”的完整流程不是信任代码而是信任验证过的结果。希望帮到你。本文还有配套的精品资源点击获取