SignalR WebSocket崩溃引发ASP.NET MVC应用重启问题求助

一、WebSocket崩溃为何导致服务器应用重启 #

在.NET Framework 4.8 + SignalR 2.4.3的环境下，WebSocket崩溃引发整个服务器应用重启的核心逻辑集中在未捕获致命异常触发应用域/进程崩溃：

• SignalR在.NET Framework中采用进程内状态管理，若WebSocket连接处理阶段（比如OnDisconnect、LeaveGroup执行时）出现未捕获的CLR级异常，会直接导致整个应用域崩溃，触发IIS应用池自动重启。
• IIS应用池的快速失败保护机制：生产环境高负载场景下，短时间内多次异常会触发应用池强制重启，这是IIS默认的故障恢复策略。
• Session与SignalR的状态交互冲突：结合场景2中崩溃延迟与sessionstate timeout的关联，Session过期释放时，若与SignalR的群组清理操作存在资源竞争或未处理异常，会引发进程级崩溃。

二、SignalR WebSocket崩溃的可能根源 #

结合生产环境的两种场景及Session超时关联的更新信息，崩溃原因可从以下方向排查：

1. Session生命周期与SignalR群组操作冲突 #

场景2中崩溃延迟随sessionstate timeout延长而增加，说明Session过期释放流程与SignalR的LeaveGroup/OnDisconnect逻辑存在交互异常：

• 若Session中存储了SignalR群组关联的状态（比如用户-群组映射），Session过期销毁时，触发的清理操作可能访问已被SignalR释放的资源，引发空引用或内存访问错误。
• InProc模式下的Session与SignalR共享应用域内存，Session回收时的资源释放操作可能干扰SignalR的连接管理线程，导致未处理异常。

2. 闲置连接的资源泄漏与清理异常 #

场景1中闲置30-60分钟后关闭连接触发崩溃，大概率是长时间闲置导致的资源泄漏：

• 连接闲置期间，未正确释放Socket句柄、内存缓冲区等资源，关闭连接时触发的清理操作引发内存溢出或句柄耗尽，进而导致WebSocket处理线程崩溃。
• 生产环境的网络代理/负载均衡可能主动断开闲置连接，但SignalR未正确处理这类异常断开场景，引发未捕获错误。

3. 频繁交互下的并发线程安全问题 #

场景2中频繁操作引发无规律快速崩溃，核心是SignalR群组或消息分发的并发冲突：

• 频繁的JoinGroup/LeaveGroup及消息推送操作，若未对共享资源（比如群组用户集合）做线程同步处理，会引发多线程竞争条件，触发NullReferenceException或InvalidOperationException等未捕获异常。
• 高频率消息交互导致SignalR的后台线程池资源耗尽，引发线程调度异常，进而导致WebSocket连接处理失败。

4. 环境配置与版本兼容性问题 #

• 开发环境与生产环境的IIS配置差异：生产环境应用池的回收规则、内存限制、快速失败保护阈值更严格，小异常就会触发重启；开发环境通常配置宽松，不易复现。
• .NET Framework 4.8或SignalR 2.4.3的已知问题：部分版本存在WebSocket处理中的内存泄漏、未处理异常bug，仅在生产环境高负载或特定Session配置下触发。

排查建议 #

• 启用应用程序异常日志和CLR崩溃日志，捕获崩溃时的完整堆栈信息，定位具体异常代码。
• 检查IIS应用池的快速失败保护配置，临时调高异常阈值或关闭该功能，验证是否为该机制导致的重启。
• 测试调整Session状态模式（比如从InProc改为StateServer），或临时禁用Session，验证是否与Session生命周期相关。
• 检查OnDisconnect和LeaveGroup方法中的业务代码，确保所有异常都被捕获处理，避免未捕获异常扩散。

内容的提问来源于stack exchange，提问作者Kristóf Horváth