尧图网站建设 
简介这是一份基于.NET 4.0的Winform服务检测工具面向需要保障Windows服务持续运行的运维或开发人员。程序按照设定周期默认3秒监控指定服务状态一旦发现停止便自动重启直至恢复为“运行中”全程采用异步等待不阻塞界面有效减少业务中断风险。压缩包共5个文件含exe主程序、config运行配置、xml服务列表配置、pdb调试符号以及txt日志示例整体仅35KB轻量易部署。工具支持添加多个服务同时检测可自定义提示信息显示行数、手动停止检测并支持导出提示信息每天自动生成以日期命名的日志文件记录服务重启情况关闭按钮仅最小化至托盘防止误关。已有452人学习下载资源解压即可运行配置好服务名即可使用适合需要快速实现服务自愈或参考Winform定时任务与系统服务交互的开发者直接使用或二次开发也可作为轻量级服务监控方案的模板。1. 服务检测工具让Windows服务挂了之后自己爬起来做运维或者维护过业务系统的人基本都经历过这种场景周末凌晨某个Windows服务悄无声息地停了客户周一上班发现系统不正常一查日志服务已经躺了两天。人工盯服务状态这件事盯一天两天还行长期盯根本不现实。这个服务检测工具就是一个专门干这事的Winform程序——它负责定时盯着你指定的Windows服务一旦发现服务状态不是“运行中”就自动执行重启直到服务恢复正常为止。程序的思路很直接不用改服务本身的代码也不用装额外组件就在一台Windows机器上跑一个常驻进程轮询你配置的服务列表发现异常就动手拉起来。适合的场景包括自研的业务服务、第三方中间件、偶尔抽风的数据库代理进程以及一切你不想半夜爬起来手动重启的服务。项目本身是.NET 4.0架构的Winform程序体积小部署简单复制到一台Windows服务器上就能跑。2. 程序的运作原理轮询、服务状态判断与自动拉起2.1 核心机制定时轮询而不是事件驱动要理解这个工具先要知道它为什么选择“轮询”而不是“事件驱动”。Windows服务本身没有对外提供“我挂了请通知我”的事件回调机制Srvc.exe 这类系统组件并不会主动告诉你某个服务状态变了。最务实的做法就是定时去查——用ServiceController去查目标服务的当前状态这就是轮询。程序里有一个监测周期参数默认是3秒。我的理解是每3秒遍历一次ServiceNameList.xml里配置的服务名逐个用ServiceController查询状态如果Status不等于Running就触发重启逻辑。用框架自带的System.ServiceProcess.ServiceController类代码层面大概长这样using System.ServiceProcess; // 遍历服务列表逐个检查状态 foreach (string serviceName in serviceNameList) { using (ServiceController sc new ServiceController(serviceName)) { // 刷新当前状态确保拿到的是最新值 sc.Refresh(); if (sc.Status ! ServiceControllerStatus.Running) { // 服务不在运行状态执行重启 RestartService(serviceName); } } }逻辑说明ServiceController是.NET Framework自带的类通过传入服务名就能拿到对应Windows服务的控制句柄。Refresh()方法是关键——ServiceController的状态有缓存不刷新的话拿到的可能是一分钟前的旧状态会误判。参数说明serviceName是Windows服务注册表中的服务名称不是显示名称。比如“World Wide Web Publishing Service”的显示名是这个但服务名是W3SVC。写错的话会抛异常“无法打开服务”这个坑后面会细说。检测周期默认3秒对绝大多数场景都够用太短反而增加无谓的系统开销。2.2 非阻塞等待为什么重启服务时界面不会卡死很多初级的服务管理工具在启动服务时会用同步调用即ServiceController.Start()之后程序就卡在原地直到服务状态变为Running才继续执行。问题是Windows服务从Start()到Running通常要几秒甚至十几秒期间Winform界面会变成“白屏无响应”状态鼠标点哪里都没反应看起来就像程序死了。这个工具的处理方式应该是把重启逻辑放到了后台线程或异步Task里界面线程只负责发起重启操作不等待结果返回。我当时拆这个项目的时候看到它在等待服务转为Running的过程中界面依然能操作这点做得很聪明——用的是轮询异步回调的思路// 异步重启不阻塞UI线程 private async Task RestartServiceAsync(string serviceName) { using (ServiceController sc new ServiceController(serviceName)) { // 先尝试启动服务 sc.Start(); // 等待状态变为Running最多等30秒 for (int i 0; i 10; i) { await Task.Delay(3000); sc.Refresh(); if (sc.Status ServiceControllerStatus.Running) { LogMessage($[{DateTime.Now}] 服务 {serviceName} 已成功重启); break; } } } }逻辑说明启动服务后不立刻检测结果而是每隔3秒查一次状态最多查10次也就是最多等30秒。等待期间用await把控制权交还给UI线程界面就不会卡死。如果服务在30秒内没起来就会记录一条失败日志等下一个检测周期再试。参数说明Task.Delay(3000)中的3000是毫秒数表示每次查询间隔3秒。循环次数10对应最大等待时间。对于启动慢的服务比如数据库类服务可能启动要1分钟以上这两个参数可以按需调整常见做法是把循环次数改成20或者把间隔缩短到2秒。3. 配置文件拆解SystemConfig与ServiceNameList.xml怎么用3.1 ServiceNameList.xml管理检测目标这是整个工具最核心的配置文件程序要盯哪些服务全看这个文件。格式是XML结构很清晰?xml version1.0 encodingutf-8? Services ServiceNameW3SVC/ServiceName ServiceNameMSSQLSERVER/ServiceName ServiceNameTomcat8/ServiceName /Services逻辑说明每个 节点就是一个要监控的Windows服务名程序启动时读取这个文件把服务名加载到内存列表里之后每个检测周期都遍历这个列表。新增服务只需要在这个文件里加一行不用重新编译程序。参数说明serviceName必须和Windows服务管理器里显示的服务名称完全一致注意是“服务名称”不是“显示名称”。怎么区分打开服务管理器双击某个服务看“常规”选项卡——“服务名称”字段是唯一的标识符“显示名称”只是给人看的友好名称。写错了程序会报错而且报错信息是“无法打开计算机上的服务”排查起来容易懵。我一般建议在配置前先在命令行里确认一下sc query W3SVC输出里有“SERVICE_NAME: W3SVC”这样的字段就说明服务名正确。如果提示“指定的服务未安装”那就是服务名写错了。用sc query确认之后再把名字填进XML文件里能省很多事。3.2 SystemConfig周期、行数与程序行为控制SystemConfig从名字看是程序的全局配置控制检测周期、提示信息显示行数等参数。虽然具体实现可能是硬编码默认值默认周期3秒、默认行数100行但这类配置一般会放在exe同目录下的.config文件里。我拆到的包里有一个ServiceCheck.exe.config文件配置内容可能长得像这样?xml version1.0 encodingutf-8? configuration appSettings !-- 检测周期单位秒默认3秒 -- add keyCheckInterval value3 / !-- 提示信息最大显示行数默认100行 -- add keyMaxLogLines value100 / !-- 日志文件保留天数默认7天 -- add keyLogRetentionDays value7 / /appSettings /configuration逻辑说明appSettings是.NET Framework约定俗成的配置节程序启动时通过ConfigurationManager.AppSettings[CheckInterval]读取。检测周期决定轮询频率行数控制窗口里提示信息的上限超过就自动清空避免内存占用越来越大。参数说明CheckInterval的单位是秒设置时要权衡——太短比如1秒会导致CPU占用偏高太长比如30秒则服务挂了之后要30秒才能被发现。对于绝大多数业务系统3到10秒是比较合理的区间。MaxLogLines这个参数容易被忽略但如果服务日志输出频繁100行会很快刷屏可以调到500行甚至1000行。3.3 同目录配套文件pdb、日志与配置的关系包里除了ServiceCheck.exe之外还有几个文件拆包的时候我逐个确认了一下文件作用是否需要手动改动ServiceCheck.exe主程序不需要ServiceCheck.pdb调试符号文件记录程序变量和行号映射不需要出问题时给开发者排错用ServiceCheck.exe.config程序配置文件按需调整参数SystemConfig系统级配置可能是备份或供程序调用的配置一般不需要动ServiceNameList.xml服务列表配置核心配置文件必须按实际服务名修改EverydayLog日志输出目录按日期生成txt文件不需要手动创建程序自动生成ServiceCheck.exe.config配置文件按需调整参数注意pdb文件很多人会删掉以减小体积但如果你在服务器上跑出了问题、需要给开发者反馈崩溃原因没有pdb文件的话日志里只有内存地址没有函数名排查难度会上升。我个人的习惯是保留pdb不差这几十KB的磁盘空间。4. 部署实操从解压到跑起来每一步都别跳4.1 部署环境要求先把部署环境说清楚。这个程序是.NET 4.0框架的Winform程序运行机器上必须有.NET Framework 4.0及以上版本。Windows Server 2008 R2和Windows 7自带.NET 3.5Windows Server 2012及之后自带.NET 4.5所以现代Windows服务器基本都能直接跑。还有一个重要前提程序要能控制Windows服务必须用管理员权限运行。如果不用管理员身份启动访问ServiceController时大概率会报“拒绝访问”的异常。Winform程序默认不请求管理员权限所以正确的做法是右键exe→“以管理员身份运行”。不想每次手动右键的话可以改exe的清单文件嵌入requireAdministrator配置不过这是进阶操作第6章会讲。4.2 完整部署步骤部署流程其实很简单按下面几步走五分钟内能完成# 1. 确认.NET框架版本 reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full /v Release # 2. 确认目标服务名以IIS的W3SVC为例 sc query W3SVC | findstr SERVICE_NAME # 3. 复制工具到服务器例如D:\ServiceCheck\ # 将ServiceCheck.exe、dll、config、xml文件全部复制过去第一步验证.NET框架如果命令返回的Release值大于0说明已安装Release值378389对应.NET 4.5461808对应.NET 4.7.2都高于4.0可以直接用。第二步确认服务名输出中SERVICE_NAME后面的字符串就是要在ServiceNameList.xml中填的内容。第三步是文件复制用共享文件夹拷过去或者用远程桌面直接粘贴都行。接着修改配置文件打开ServiceNameList.xml把要监控的服务名填入?xml version1.0 encodingutf-8? Services ServiceNameW3SVC/ServiceName ServiceNameMSSQLSERVER/ServiceName /Services确认配置无误后右键ServiceCheck.exe选择“以管理员身份运行”。程序启动后主窗口会显示检测状态和日志信息默认开始检测。为了确认整个检测链路是通的可以手工停掉一个服务来验证# 手工停止W3SVC服务验证工具能否自动拉起 sc stop W3SVC等待3秒左右观察程序窗口是否出现服务停止的提示再过几秒看服务状态是否回到Running。如果服务被自动拉起来了说明整套机制工作正常。4.3 窗口界面的操作习惯别被“关闭”按钮骗了有一个操作习惯要提前提醒这个程序右上角的关闭按钮点击后并不会真正退出程序而是把窗口收进系统托盘——这是刻意设计成这样的防止误关闭导致检测中断。托盘图标是程序底部的小图标真正退出要做的是右键托盘图标弹出菜单中选择【退出】。刚开始用的人最容易困惑的点就在这里点了关闭任务栏没了任务管理器里看进程还在。这不是Bug是防误关机制。如果通过任务管理器强制结束进程那么程序是没了服务也失去了自动恢复的保障。我的习惯是部署完后把程序的exe路径加到服务器开机启动项里启动文件夹或计划任务这样服务器重启后程序会自己起来检测逻辑自动恢复。4.4 验证工具是否真正在检测判断程序到底有没有在干活最直接的指标是看EverydayLog目录下的日志文件。程序每天会在程序目录下生成一个对应日期的日志文件比如EverydayLog/2023-03-13.txt里面记录了每次服务停止、重启、启动成功的完整时间线。日志文件长这样2023-03-13 14:23:01 检测到服务 W3SVC 状态为Stopped 2023-03-13 14:23:01 正在尝试启动服务 W3SVC ... 2023-03-13 14:23:06 服务 W3SVC 已成功启动当前状态Running如果日志里只有检测记录但没有启动记录说明程序启动了但服务自身有问题如果连日志都没有就要检查程序是否以管理员权限运行。日志文件按日期命名不会无限制堆积——你可以配合计划任务定期清理超过N天的日志文件或者用程序自带的“提示信息导出”功能手动导出存档。5. 避坑指南服务重启工具最常见的5个翻车现场5.1 症状服务名写错检测不到任何服务现象程序启动了窗口一直在滚动提示但日志里没有任何服务检测记录或者弹出“无法打开服务”的错误对话框。原因ServiceNameList.xml里填的是显示名称而不是服务名。比如“SQL Server (MSSQLSERVER)”是显示名服务名是MSSQLSERVER。另外服务名区分大小写不敏感但空格、括号等字符必须完全匹配。解决用sc query命令查服务名把SERVICE_NAME字段对应的值填进XML中。对于SQL Server这种服务要特别注意服务列表里可能有多个实例MSSQLSERVER和MSSQL$SQLEXPRESS是不同的服务。填错一个字符整个检测链路就断了。5.2 症状出现“拒绝访问”或“无法打开服务”异常现象程序能启动但日志中出现“拒绝访问”或“无法打开服务”错误服务一直没有被自动拉起。原因ServiceController类需要一定的系统权限才能读写服务状态。如果程序是以普通用户身份运行的即使该用户是管理员组成员UAC也会拦截服务控制请求。解决确认当前登录用户在“管理员”组中并且右键exe选择“以管理员身份运行”。特别注意用计划任务启动时要在任务属性中勾选“使用最高权限运行”否则即使是管理员身份也会被UAC拦截。5.3 症状服务重启失败程序反复尝试现象日志显示服务状态为Stopped程序尝试启动但服务始终无法转为Running循环了几分钟甚至几小时。原因服务本身启动失败可能是需要依赖其它服务先启动或者服务账号密码过期或者服务对应程序的配置文件损坏。工具只能起到“拉起”作用解决不了服务自身的启动问题。解决看Windows事件查看器——应用程序日志和服务日志中有系统记录的启动报错这是最直接的排查入口。我遇到过一个MySQL服务反复重启失败的情况最后发现是磁盘满了。把磁盘空间清理掉之后服务一次启动就成功了。5.4 症状多服务同时重启导致连锁问题现象两个数据库相关的服务同时停止程序同时尝试重启它们结果启动失败或启动顺序混乱。原因服务之间有依赖关系。比如应用A依赖数据库B的某个服务先起来但程序是并行重启多个服务的没有先后顺序。解决把有依赖关系的服务拆分成两个配置文件或者调整程序的一次性处理逻辑让依赖服务先启动等待服务状态Running后再处理被依赖的服务。从实际经验看我一般把强依赖的服务拆到不同的检测周期错开处理通过在不同时间启动工具实例的方式实现。5.5 症状程序莫名其妙消失了现象运行了一段时间后程序不见了服务又停了而且这次没有自动拉起。原因有人手动在任务管理器里结束了进程或者程序崩溃后退出了。任务管理器里结束进程不会有任何确认提示程序没有守护自身的能力。解决这个工具本身没有自我保护机制所以我的习惯是配合计划任务部署一条守护命令每分钟检查一次ServiceCheck.exe进程是否存在不存在就重新启动# 在任务计划程序中配置每分钟执行一次 tasklist /FI IMAGENAME eq ServiceCheck.exe | findstr /I ServiceCheck.exe nul || start D:\ServiceCheck\ServiceCheck.exe这行命令的作用是如果检测不到ServiceCheck.exe进程就重新启动它。加到Windows计划任务里每分钟跑一次能弥补程序自身缺乏守护的短板。6. 进阶技巧日志复核与批量部署的实战经验6.1 用日志反推服务的稳定性日志不只是看“服务有没有被拉起”的它还是服务稳定性的晴雨表。我每次部署完这个工具都会隔一周去翻一次EverydayLog目录下的日志文件统计每个服务的重启次数。如果一个服务一周内被自动重启了5次以上说明这个服务本身有隐性问题靠重启工具治标不治本。正确的做法是把日志中的时间点和服务端应用日志做交叉比对——比如MSSQLSERVER在凌晨2点被重启对应的SQL Server错误日志里一定有相关报错。定位到根因后彻底修复再让工具回归到“兜底”的岗位。我习惯用PowerShell写一个简单的统计脚本把日志里的重启次数按服务名汇总$logPath D:\ServiceCheck\EverydayLog $files Get-ChildItem $logPath -Filter *.txt foreach ($file in $files) { $content Get-Content $file.FullName $restartCount ($content | Select-String 已成功启动).Count Write-Host $($file.Name) 重启次数: $restartCount }这个脚本会把每一天的日志文件扫描一遍统计“已成功启动”出现的次数。我一般把它设置成每周日自动运行一次输出结果邮件发出来。知道哪些服务在频繁重启比等客户报障再排查要主动得多。6.2 多服务器批量部署时的一个习惯如果你管着多台服务器每台机器都要部署这个工具有一个细节值得注意ServiceNameList.xml的配置因机器而异但日志文件默认生成在exe所在目录。我一般会把日志目录重定向到独立盘符防止系统盘被日志刷满。具体做法是在exe.config里加一个日志路径配置项或者直接把整个程序目录放到D盘。复制完文件后先确认D:\ServiceCheck\EverydayLog能正常写文件权限不对的话日志会静默失败排查起来很被动。还有一个多服务器场景的注意点如果有多台机器监控同一个共享服务比如监控共享数据库要避免每台机器同时重启同一个服务这会造成服务实例互相冲突。加一个简单的“只有一个实例处理重启”逻辑或者按机器拆分监控的服务列表能省去很多莫名其妙的问题。6.3 管理员权限的彻底解决方案之前提到右键“以管理员身份运行”是手动方式。对于需要开机自启或计划任务运行的程序改成显式请求管理员权限更稳妥。打开Visual Studio或任意文本编辑器在exe同目录加一个app.manifest文件编译时引入即可。核心配置如下requestedExecutionLevel levelrequireAdministrator uiAccessfalse /加上这个配置后双击exe会直接弹出UAC提权确认框不再需要手动右键。这样配合计划任务或启动文件夹程序每次开机都能以管理员权限自动运行检测逻辑不会因为权限问题静默失效。部署完之后我一般会走一遍完整的验证功能上手工停服务看能否自动拉起权限上重启一次服务器看程序是否能自启配置上改一次ServiceNameList.xml确认热加载是否生效。这套流程走完之后基本可以放心让工具自己在后台守着。服务检测工具的价值不在于功能多复杂而在于它把最基础的“服务死了要拉起来”这件事做扎实了——能用最简单的方式解决运维里最烦人的问题就是好工具。希望这个拆解能帮到你。本文还有配套的精品资源点击获取 Windows服务自动重启监控工具：设计与部署实战解析
简介这是一份基于.NET 4.0的Winform服务检测工具面向需要保障Windows服务持续运行的运维或开发人员。程序按照设定周期默认3秒监控指定服务状态一旦发现停止便自动重启直至恢复为“运行中”全程采用异步等待不阻塞界面有效减少业务中断风险。压缩包共5个文件含exe主程序、config运行配置、xml服务列表配置、pdb调试符号以及txt日志示例整体仅35KB轻量易部署。工具支持添加多个服务同时检测可自定义提示信息显示行数、手动停止检测并支持导出提示信息每天自动生成以日期命名的日志文件记录服务重启情况关闭按钮仅最小化至托盘防止误关。已有452人学习下载资源解压即可运行配置好服务名即可使用适合需要快速实现服务自愈或参考Winform定时任务与系统服务交互的开发者直接使用或二次开发也可作为轻量级服务监控方案的模板。1. 服务检测工具让Windows服务挂了之后自己爬起来做运维或者维护过业务系统的人基本都经历过这种场景周末凌晨某个Windows服务悄无声息地停了客户周一上班发现系统不正常一查日志服务已经躺了两天。人工盯服务状态这件事盯一天两天还行长期盯根本不现实。这个服务检测工具就是一个专门干这事的Winform程序——它负责定时盯着你指定的Windows服务一旦发现服务状态不是“运行中”就自动执行重启直到服务恢复正常为止。程序的思路很直接不用改服务本身的代码也不用装额外组件就在一台Windows机器上跑一个常驻进程轮询你配置的服务列表发现异常就动手拉起来。适合的场景包括自研的业务服务、第三方中间件、偶尔抽风的数据库代理进程以及一切你不想半夜爬起来手动重启的服务。项目本身是.NET 4.0架构的Winform程序体积小部署简单复制到一台Windows服务器上就能跑。2. 程序的运作原理轮询、服务状态判断与自动拉起2.1 核心机制定时轮询而不是事件驱动要理解这个工具先要知道它为什么选择“轮询”而不是“事件驱动”。Windows服务本身没有对外提供“我挂了请通知我”的事件回调机制Srvc.exe 这类系统组件并不会主动告诉你某个服务状态变了。最务实的做法就是定时去查——用ServiceController去查目标服务的当前状态这就是轮询。程序里有一个监测周期参数默认是3秒。我的理解是每3秒遍历一次ServiceNameList.xml里配置的服务名逐个用ServiceController查询状态如果Status不等于Running就触发重启逻辑。用框架自带的System.ServiceProcess.ServiceController类代码层面大概长这样using System.ServiceProcess; // 遍历服务列表逐个检查状态 foreach (string serviceName in serviceNameList) { using (ServiceController sc new ServiceController(serviceName)) { // 刷新当前状态确保拿到的是最新值 sc.Refresh(); if (sc.Status ! ServiceControllerStatus.Running) { // 服务不在运行状态执行重启 RestartService(serviceName); } } }逻辑说明ServiceController是.NET Framework自带的类通过传入服务名就能拿到对应Windows服务的控制句柄。Refresh()方法是关键——ServiceController的状态有缓存不刷新的话拿到的可能是一分钟前的旧状态会误判。参数说明serviceName是Windows服务注册表中的服务名称不是显示名称。比如“World Wide Web Publishing Service”的显示名是这个但服务名是W3SVC。写错的话会抛异常“无法打开服务”这个坑后面会细说。检测周期默认3秒对绝大多数场景都够用太短反而增加无谓的系统开销。2.2 非阻塞等待为什么重启服务时界面不会卡死很多初级的服务管理工具在启动服务时会用同步调用即ServiceController.Start()之后程序就卡在原地直到服务状态变为Running才继续执行。问题是Windows服务从Start()到Running通常要几秒甚至十几秒期间Winform界面会变成“白屏无响应”状态鼠标点哪里都没反应看起来就像程序死了。这个工具的处理方式应该是把重启逻辑放到了后台线程或异步Task里界面线程只负责发起重启操作不等待结果返回。我当时拆这个项目的时候看到它在等待服务转为Running的过程中界面依然能操作这点做得很聪明——用的是轮询异步回调的思路// 异步重启不阻塞UI线程 private async Task RestartServiceAsync(string serviceName) { using (ServiceController sc new ServiceController(serviceName)) { // 先尝试启动服务 sc.Start(); // 等待状态变为Running最多等30秒 for (int i 0; i 10; i) { await Task.Delay(3000); sc.Refresh(); if (sc.Status ServiceControllerStatus.Running) { LogMessage($[{DateTime.Now}] 服务 {serviceName} 已成功重启); break; } } } }逻辑说明启动服务后不立刻检测结果而是每隔3秒查一次状态最多查10次也就是最多等30秒。等待期间用await把控制权交还给UI线程界面就不会卡死。如果服务在30秒内没起来就会记录一条失败日志等下一个检测周期再试。参数说明Task.Delay(3000)中的3000是毫秒数表示每次查询间隔3秒。循环次数10对应最大等待时间。对于启动慢的服务比如数据库类服务可能启动要1分钟以上这两个参数可以按需调整常见做法是把循环次数改成20或者把间隔缩短到2秒。3. 配置文件拆解SystemConfig与ServiceNameList.xml怎么用3.1 ServiceNameList.xml管理检测目标这是整个工具最核心的配置文件程序要盯哪些服务全看这个文件。格式是XML结构很清晰?xml version1.0 encodingutf-8? Services ServiceNameW3SVC/ServiceName ServiceNameMSSQLSERVER/ServiceName ServiceNameTomcat8/ServiceName /Services逻辑说明每个 节点就是一个要监控的Windows服务名程序启动时读取这个文件把服务名加载到内存列表里之后每个检测周期都遍历这个列表。新增服务只需要在这个文件里加一行不用重新编译程序。参数说明serviceName必须和Windows服务管理器里显示的服务名称完全一致注意是“服务名称”不是“显示名称”。怎么区分打开服务管理器双击某个服务看“常规”选项卡——“服务名称”字段是唯一的标识符“显示名称”只是给人看的友好名称。写错了程序会报错而且报错信息是“无法打开计算机上的服务”排查起来容易懵。我一般建议在配置前先在命令行里确认一下sc query W3SVC输出里有“SERVICE_NAME: W3SVC”这样的字段就说明服务名正确。如果提示“指定的服务未安装”那就是服务名写错了。用sc query确认之后再把名字填进XML文件里能省很多事。3.2 SystemConfig周期、行数与程序行为控制SystemConfig从名字看是程序的全局配置控制检测周期、提示信息显示行数等参数。虽然具体实现可能是硬编码默认值默认周期3秒、默认行数100行但这类配置一般会放在exe同目录下的.config文件里。我拆到的包里有一个ServiceCheck.exe.config文件配置内容可能长得像这样?xml version1.0 encodingutf-8? configuration appSettings !-- 检测周期单位秒默认3秒 -- add keyCheckInterval value3 / !-- 提示信息最大显示行数默认100行 -- add keyMaxLogLines value100 / !-- 日志文件保留天数默认7天 -- add keyLogRetentionDays value7 / /appSettings /configuration逻辑说明appSettings是.NET Framework约定俗成的配置节程序启动时通过ConfigurationManager.AppSettings[CheckInterval]读取。检测周期决定轮询频率行数控制窗口里提示信息的上限超过就自动清空避免内存占用越来越大。参数说明CheckInterval的单位是秒设置时要权衡——太短比如1秒会导致CPU占用偏高太长比如30秒则服务挂了之后要30秒才能被发现。对于绝大多数业务系统3到10秒是比较合理的区间。MaxLogLines这个参数容易被忽略但如果服务日志输出频繁100行会很快刷屏可以调到500行甚至1000行。3.3 同目录配套文件pdb、日志与配置的关系包里除了ServiceCheck.exe之外还有几个文件拆包的时候我逐个确认了一下文件作用是否需要手动改动ServiceCheck.exe主程序不需要ServiceCheck.pdb调试符号文件记录程序变量和行号映射不需要出问题时给开发者排错用ServiceCheck.exe.config程序配置文件按需调整参数SystemConfig系统级配置可能是备份或供程序调用的配置一般不需要动ServiceNameList.xml服务列表配置核心配置文件必须按实际服务名修改EverydayLog日志输出目录按日期生成txt文件不需要手动创建程序自动生成ServiceCheck.exe.config配置文件按需调整参数注意pdb文件很多人会删掉以减小体积但如果你在服务器上跑出了问题、需要给开发者反馈崩溃原因没有pdb文件的话日志里只有内存地址没有函数名排查难度会上升。我个人的习惯是保留pdb不差这几十KB的磁盘空间。4. 部署实操从解压到跑起来每一步都别跳4.1 部署环境要求先把部署环境说清楚。这个程序是.NET 4.0框架的Winform程序运行机器上必须有.NET Framework 4.0及以上版本。Windows Server 2008 R2和Windows 7自带.NET 3.5Windows Server 2012及之后自带.NET 4.5所以现代Windows服务器基本都能直接跑。还有一个重要前提程序要能控制Windows服务必须用管理员权限运行。如果不用管理员身份启动访问ServiceController时大概率会报“拒绝访问”的异常。Winform程序默认不请求管理员权限所以正确的做法是右键exe→“以管理员身份运行”。不想每次手动右键的话可以改exe的清单文件嵌入requireAdministrator配置不过这是进阶操作第6章会讲。4.2 完整部署步骤部署流程其实很简单按下面几步走五分钟内能完成# 1. 确认.NET框架版本 reg query HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full /v Release # 2. 确认目标服务名以IIS的W3SVC为例 sc query W3SVC | findstr SERVICE_NAME # 3. 复制工具到服务器例如D:\ServiceCheck\ # 将ServiceCheck.exe、dll、config、xml文件全部复制过去第一步验证.NET框架如果命令返回的Release值大于0说明已安装Release值378389对应.NET 4.5461808对应.NET 4.7.2都高于4.0可以直接用。第二步确认服务名输出中SERVICE_NAME后面的字符串就是要在ServiceNameList.xml中填的内容。第三步是文件复制用共享文件夹拷过去或者用远程桌面直接粘贴都行。接着修改配置文件打开ServiceNameList.xml把要监控的服务名填入?xml version1.0 encodingutf-8? Services ServiceNameW3SVC/ServiceName ServiceNameMSSQLSERVER/ServiceName /Services确认配置无误后右键ServiceCheck.exe选择“以管理员身份运行”。程序启动后主窗口会显示检测状态和日志信息默认开始检测。为了确认整个检测链路是通的可以手工停掉一个服务来验证# 手工停止W3SVC服务验证工具能否自动拉起 sc stop W3SVC等待3秒左右观察程序窗口是否出现服务停止的提示再过几秒看服务状态是否回到Running。如果服务被自动拉起来了说明整套机制工作正常。4.3 窗口界面的操作习惯别被“关闭”按钮骗了有一个操作习惯要提前提醒这个程序右上角的关闭按钮点击后并不会真正退出程序而是把窗口收进系统托盘——这是刻意设计成这样的防止误关闭导致检测中断。托盘图标是程序底部的小图标真正退出要做的是右键托盘图标弹出菜单中选择【退出】。刚开始用的人最容易困惑的点就在这里点了关闭任务栏没了任务管理器里看进程还在。这不是Bug是防误关机制。如果通过任务管理器强制结束进程那么程序是没了服务也失去了自动恢复的保障。我的习惯是部署完后把程序的exe路径加到服务器开机启动项里启动文件夹或计划任务这样服务器重启后程序会自己起来检测逻辑自动恢复。4.4 验证工具是否真正在检测判断程序到底有没有在干活最直接的指标是看EverydayLog目录下的日志文件。程序每天会在程序目录下生成一个对应日期的日志文件比如EverydayLog/2023-03-13.txt里面记录了每次服务停止、重启、启动成功的完整时间线。日志文件长这样2023-03-13 14:23:01 检测到服务 W3SVC 状态为Stopped 2023-03-13 14:23:01 正在尝试启动服务 W3SVC ... 2023-03-13 14:23:06 服务 W3SVC 已成功启动当前状态Running如果日志里只有检测记录但没有启动记录说明程序启动了但服务自身有问题如果连日志都没有就要检查程序是否以管理员权限运行。日志文件按日期命名不会无限制堆积——你可以配合计划任务定期清理超过N天的日志文件或者用程序自带的“提示信息导出”功能手动导出存档。5. 避坑指南服务重启工具最常见的5个翻车现场5.1 症状服务名写错检测不到任何服务现象程序启动了窗口一直在滚动提示但日志里没有任何服务检测记录或者弹出“无法打开服务”的错误对话框。原因ServiceNameList.xml里填的是显示名称而不是服务名。比如“SQL Server (MSSQLSERVER)”是显示名服务名是MSSQLSERVER。另外服务名区分大小写不敏感但空格、括号等字符必须完全匹配。解决用sc query命令查服务名把SERVICE_NAME字段对应的值填进XML中。对于SQL Server这种服务要特别注意服务列表里可能有多个实例MSSQLSERVER和MSSQL$SQLEXPRESS是不同的服务。填错一个字符整个检测链路就断了。5.2 症状出现“拒绝访问”或“无法打开服务”异常现象程序能启动但日志中出现“拒绝访问”或“无法打开服务”错误服务一直没有被自动拉起。原因ServiceController类需要一定的系统权限才能读写服务状态。如果程序是以普通用户身份运行的即使该用户是管理员组成员UAC也会拦截服务控制请求。解决确认当前登录用户在“管理员”组中并且右键exe选择“以管理员身份运行”。特别注意用计划任务启动时要在任务属性中勾选“使用最高权限运行”否则即使是管理员身份也会被UAC拦截。5.3 症状服务重启失败程序反复尝试现象日志显示服务状态为Stopped程序尝试启动但服务始终无法转为Running循环了几分钟甚至几小时。原因服务本身启动失败可能是需要依赖其它服务先启动或者服务账号密码过期或者服务对应程序的配置文件损坏。工具只能起到“拉起”作用解决不了服务自身的启动问题。解决看Windows事件查看器——应用程序日志和服务日志中有系统记录的启动报错这是最直接的排查入口。我遇到过一个MySQL服务反复重启失败的情况最后发现是磁盘满了。把磁盘空间清理掉之后服务一次启动就成功了。5.4 症状多服务同时重启导致连锁问题现象两个数据库相关的服务同时停止程序同时尝试重启它们结果启动失败或启动顺序混乱。原因服务之间有依赖关系。比如应用A依赖数据库B的某个服务先起来但程序是并行重启多个服务的没有先后顺序。解决把有依赖关系的服务拆分成两个配置文件或者调整程序的一次性处理逻辑让依赖服务先启动等待服务状态Running后再处理被依赖的服务。从实际经验看我一般把强依赖的服务拆到不同的检测周期错开处理通过在不同时间启动工具实例的方式实现。5.5 症状程序莫名其妙消失了现象运行了一段时间后程序不见了服务又停了而且这次没有自动拉起。原因有人手动在任务管理器里结束了进程或者程序崩溃后退出了。任务管理器里结束进程不会有任何确认提示程序没有守护自身的能力。解决这个工具本身没有自我保护机制所以我的习惯是配合计划任务部署一条守护命令每分钟检查一次ServiceCheck.exe进程是否存在不存在就重新启动# 在任务计划程序中配置每分钟执行一次 tasklist /FI IMAGENAME eq ServiceCheck.exe | findstr /I ServiceCheck.exe nul || start D:\ServiceCheck\ServiceCheck.exe这行命令的作用是如果检测不到ServiceCheck.exe进程就重新启动它。加到Windows计划任务里每分钟跑一次能弥补程序自身缺乏守护的短板。6. 进阶技巧日志复核与批量部署的实战经验6.1 用日志反推服务的稳定性日志不只是看“服务有没有被拉起”的它还是服务稳定性的晴雨表。我每次部署完这个工具都会隔一周去翻一次EverydayLog目录下的日志文件统计每个服务的重启次数。如果一个服务一周内被自动重启了5次以上说明这个服务本身有隐性问题靠重启工具治标不治本。正确的做法是把日志中的时间点和服务端应用日志做交叉比对——比如MSSQLSERVER在凌晨2点被重启对应的SQL Server错误日志里一定有相关报错。定位到根因后彻底修复再让工具回归到“兜底”的岗位。我习惯用PowerShell写一个简单的统计脚本把日志里的重启次数按服务名汇总$logPath D:\ServiceCheck\EverydayLog $files Get-ChildItem $logPath -Filter *.txt foreach ($file in $files) { $content Get-Content $file.FullName $restartCount ($content | Select-String 已成功启动).Count Write-Host $($file.Name) 重启次数: $restartCount }这个脚本会把每一天的日志文件扫描一遍统计“已成功启动”出现的次数。我一般把它设置成每周日自动运行一次输出结果邮件发出来。知道哪些服务在频繁重启比等客户报障再排查要主动得多。6.2 多服务器批量部署时的一个习惯如果你管着多台服务器每台机器都要部署这个工具有一个细节值得注意ServiceNameList.xml的配置因机器而异但日志文件默认生成在exe所在目录。我一般会把日志目录重定向到独立盘符防止系统盘被日志刷满。具体做法是在exe.config里加一个日志路径配置项或者直接把整个程序目录放到D盘。复制完文件后先确认D:\ServiceCheck\EverydayLog能正常写文件权限不对的话日志会静默失败排查起来很被动。还有一个多服务器场景的注意点如果有多台机器监控同一个共享服务比如监控共享数据库要避免每台机器同时重启同一个服务这会造成服务实例互相冲突。加一个简单的“只有一个实例处理重启”逻辑或者按机器拆分监控的服务列表能省去很多莫名其妙的问题。6.3 管理员权限的彻底解决方案之前提到右键“以管理员身份运行”是手动方式。对于需要开机自启或计划任务运行的程序改成显式请求管理员权限更稳妥。打开Visual Studio或任意文本编辑器在exe同目录加一个app.manifest文件编译时引入即可。核心配置如下requestedExecutionLevel levelrequireAdministrator uiAccessfalse /加上这个配置后双击exe会直接弹出UAC提权确认框不再需要手动右键。这样配合计划任务或启动文件夹程序每次开机都能以管理员权限自动运行检测逻辑不会因为权限问题静默失效。部署完之后我一般会走一遍完整的验证功能上手工停服务看能否自动拉起权限上重启一次服务器看程序是否能自启配置上改一次ServiceNameList.xml确认热加载是否生效。这套流程走完之后基本可以放心让工具自己在后台守着。服务检测工具的价值不在于功能多复杂而在于它把最基础的“服务死了要拉起来”这件事做扎实了——能用最简单的方式解决运维里最烦人的问题就是好工具。希望这个拆解能帮到你。本文还有配套的精品资源点击获取