如何确保服务进程完全停止且其关联程序集已被释放？

问题核心根因 #

你遇到的偶发文件占用问题本质是对ServiceController.WaitForStatus()的行为误解：
该方法返回ServiceControllerStatus.Stopped仅代表服务控制管理器（SCM）已收到服务上报的停止完成状态，不代表服务宿主进程已经完全退出、释放了所有程序集文件的句柄。服务上报停止状态后，可能仍需要数毫秒到数秒不等的时间完成资源清理、进程退出流程，这就是固定1秒延迟仍偶发失败的原因。

可落地的最佳实践方案 #

1. 替换固定延迟为主动进程退出校验 #

停止服务后不要用固定时长等待，直接校验对应服务进程是否完全退出，步骤如下：

• 调用ServiceController.Stop()后先调用WaitForStatus(ServiceControllerStatus.Stopped)，确保服务本身的停止逻辑已经执行完成
• 通过WMI查询Win32_Service类，根据服务名获取对应进程的PID：SELECT ProcessId FROM Win32_Service WHERE Name='你的服务名'
• 用Process.GetProcessById(pid)拿到进程对象，调用Process.WaitForExit(30000)等待进程退出，最长等待30秒足够覆盖所有正常场景
• 如果等待超时进程仍未退出，直接调用Process.Kill()强制终止，确保没有残留进程占用文件

2. 修正服务端OnStop实现，移除Environment.Exit() #

Environment.Exit()属于进程暴力退出，会绕过SCM的正常通知流程，导致SCM判定服务异常崩溃，记录错误日志。正确的实现逻辑：

• OnStop方法内仅处理业务层的资源释放：停止所有后台线程、关闭IO连接、取消异步任务即可
• 所有长期运行的后台线程要设置IsBackground = true，进程退出时会自动终止这类线程，不会卡进程退出流程
• 不要在OnStop内添加任何强制进程退出的逻辑，SCM会在服务上报停止状态后处理进程的正常退出

3. 可选：复制文件前添加独占打开校验 #

如果需要极端场景下的稳定性，复制每个文件前先尝试以独占写模式打开文件，验证没有被占用后再执行复制，示例代码如下：

private bool CheckFileCanWrite(string filePath)
{
    if (!File.Exists(filePath)) return true;
    try
    {
        using (var fs = File.Open(filePath, FileMode.Open, FileAccess.ReadWrite, FileShare.None))
        {
            return true;
        }
    }
    catch (IOException)
    {
        return false;
    }
}

如果校验不通过，可以间隔100ms重试，最多重试10次仍失败再抛出错误。

内容的提问来源于stack exchange，提问作者nc404