.NET Windows服务单台运行时读取文件抛线程中止异常的原因排查

所有原因均贴合“多台机器运行正常、仅单台机器触发、异常栈落在System.IO.File.InternalReadAllBytes位置”的实际场景：

• 服务控制管理器（SCM）的强制停止触发：该机器上的Windows服务如果被配置了过短的停止响应超时阈值（默认SCM对服务停止的响应窗口为30秒），当服务收到停止、暂停指令时，若正卡在文件读取的磁盘IO等待阶段，ServiceBase内置的停止逻辑会对阻塞的工作线程强制注入中止异常；因为单台机器磁盘响应速度比其他机器慢，IO操作还未完成就达到超时阈值，就会在当前文件读取栈帧位置抛出该异常。
• 应用域卸载的连带影响：如果这台机器上的服务宿主集成了定期应用域回收逻辑（比如自定义的应用域生命周期管理、带回收机制的第三方宿主），回收过程中CLR会对域内所有运行线程注入ThreadAbortException，正在执行文件读取操作的线程就会在刚从native IO调用返回到托管边界的位置，捕获到该异常。
• 自定义超时取消逻辑的机制问题：如果服务封装了带超时限制的任务执行框架，且框架采用老式Thread.Abort()而非协作式CancellationToken实现超时强制终止；当这台机器上的文件路径响应延迟超过预设超时阈值时，就会被强制中止线程，异常直接落在当前执行栈上——其他机器磁盘读速快、IO未超时，自然不会触发该逻辑。
• 目标存储介质的IO阻塞问题：这台机器上被读取的文件如果存在网络映射盘掉线、磁盘坏道、存储连接中断的情况，本来就会长时间阻塞native文件读取调用；叠加服务进程自带的看门狗超时机制触发线程中止，就会把异常抛在该IO调用栈上，其他机器因为文件存储在正常本地磁盘上，不会出现这类长阻塞场景。
• 终端安全软件的拦截影响：这台机器安装的杀毒软件、透明加密终端软件如果对目标图片文件触发实时扫描拦截，导致File.ReadAllBytes的系统调用长时间等待文件锁释放；当达到服务配置的操作超时阈值被强制中止线程时，就会抛出该异常，其他机器没有安装对应的拦截组件，文件读取可快速完成。
• 框架版本的已知栈错位问题：该机器上安装的旧版本.NET Framework存在已知问题——在线程被中止时，异常栈不会跳转到线程取消的实际触发点，而是直接落在当前刚返回托管边界的native IO调用栈帧上；其他机器安装的是修复了该问题的框架版本，异常栈位置表现正常。
• 运行账号的权限管控阻塞：这台机器上给Windows服务配置的运行账号，如果在企业终端权限管控系统中被设置了“敏感文件读取需临时审批”的规则，会导致文件读取调用长时间挂起；直到审批超时被系统强制关闭IO句柄、关联触发线程中止，就会把异常抛在当前栈位置。

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