.NET Framework Web Api自托管Windows服务修改监听地址后旧端口请求触发空引用异常崩溃

所有报错特征完全对应HttpSelfHostServer销毁流程的已知缺陷，结合代码实现可以定位到三个直接触发点：

• 旧服务实例的异步销毁流程没有被等待完成，就直接被赋值替换。HttpSelfHostServer底层基于WCF HTTP绑定和HTTP.SYS内核监听器实现，调用Dispose方法仅会触发异步停止流程，不会立即解绑内核层的端口监听、不会清空正在排队的请求上下文。此时旧端口的监听连接仍然由当前进程持有，一旦有请求打到这个未完全释放的旧端口，就会进入已经被置空内部依赖的旧server实例调度逻辑，直接触发空引用。
• Timer回调的无锁并发问题。System.Timers.Timer的Elapsed事件默认在线程池线程执行，没有做重入控制时，可能出现两个回调同时操作server/config字段的情况：比如一个线程正在执行旧server的销毁流程，另一个线程已经把字段指向了新server，导致旧server内部的异步回调拿到的字段引用已经被修改为null，触发系统库内部的空引用。
• URLACL配置逻辑完全写反。代码里先执行新地址的add urlacl，紧接着又执行同一个新地址的delete urlacl，既没有正确配置新端口的访问权限，也没有清理旧端口的保留URL，反而会让HTTP.SYS层的端口绑定残留更久，增加旧请求打到已销毁实例的概率。

• 为什么新端口请求正常？新创建的HttpSelfHostServer实例内部路由、配置对象都是完整初始化的，处理请求的链路没有缺损，自然可以正常响应。
• 为什么旧端口请求会直接导致进程崩溃？触发空引用的位置是系统库内部的异步状态机，不在业务代码的try-catch覆盖范围内：HttpSelfHostServer的d__34、d__35是OpenAsync/CloseAsync的编译生成状态机，这些状态机里的空引用属于未观察的任务异常，默认会被Windows进程的未处理异常捕获器直接终止进程，不会走业务代码的日志逻辑，所以本地日志完全没有记录。
• 为什么调试时拿不到完整异常栈？空引用发生在系统库的异步续延线程上，没有附加调试器时，这些异常的上下文信息不会传递到业务层的调用帧，所以只能在事件查看器里看到最顶层的异常位置。

1. 修正Server销毁的等待逻辑
   把之前的同步Dispose替换为显式等待异步关闭完成：将原有的server.Dispose()逻辑替换为server.CloseAsync().Wait(TimeSpan.FromSeconds(30))，确认旧server完全从HTTP.SYS解绑后，再创建新的server实例。销毁旧实例后，手动执行netsh http delete urlacl url=旧监听地址/清理残留的URL保留配置，确保旧端口不会被内核层继续绑定到当前进程。
2. 给Timer回调加重入锁
   用静态私有锁对象包裹整个配置检查、Server启停的逻辑块，避免多线程同时修改server/config字段。同时在每次Timer回调开始时，重置Timer的等待时间，避免上一次逻辑执行时间超过间隔时出现并发重入。
3. 补全全局异常兜底
   在程序入口的Main方法中注册AppDomain.CurrentDomain.UnhandledException和TaskScheduler.UnobservedTaskException事件，将捕获到的完整异常堆栈、当前配置值、server实例状态写入本地日志。后续再出现类似崩溃时，就能拿到完整的异常内部帧，不用只靠事件查看器的顶层堆栈定位问题。
4. 修正URLACL的命令逻辑
   调整netsh命令的执行顺序：启动新server前，先执行新地址的add urlacl命令；等旧server完全停止、解绑完成后，再执行旧地址的delete urlacl命令，补充完整命令参数（需指定授权操作的服务账号，不要空写参数）。
5. 验证步骤
   切换完监听端口后，执行netstat -ano | findstr :旧端口号检查端口占用情况，只要旧端口仍然被当前进程的PID占用，就说明销毁流程没有完成。此时等待监听完全释放后，再发请求到旧端口，系统会直接返回连接拒绝错误，不会进入进程内部触发空引用崩溃。

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