ASP.NET Core/Angular站点在IIS中偶尔停止，如何排查原因？

一、强化应用日志捕获 #

后端（ASP.NET Core） #

• 在Program.cs中配置详细日志级别，将日志输出到本地文件：

  builder.Logging.AddFile("Logs/app-{Date}.txt", LogLevel.Trace);
  

  确保捕获Trace、Debug级别的日志，不要仅保留Error级别。
• 全局异常处理：添加UseExceptionHandler中间件，将未处理异常的完整堆栈信息写入日志：

  app.UseExceptionHandler(errorApp =>
  {
      errorApp.Run(async context =>
      {
          var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
          var exception = exceptionHandlerPathFeature?.Error;
          // 将exception的详细信息写入日志
          await context.Response.WriteAsync("An unexpected error occurred.");
      });
  });
  

前端（Angular） #

• 实现全局错误拦截器，捕获客户端脚本错误、HTTP请求错误，将日志存储到本地或上报至后端：

  @Injectable()
  export class GlobalErrorInterceptor implements HttpInterceptor {
    intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
      return next.handle(request).pipe(
        catchError((error: HttpErrorResponse) => {
          // 记录错误日志，比如写入localStorage或调用后端接口
          console.error('Frontend error:', error);
          return throwError(() => error);
        })
      );
    }
  }
  

• 若使用SSR（服务器端渲染），需在服务器端捕获Angular渲染时的异常，避免导致ASP.NET Core进程崩溃。

二、排查IIS配置与日志 #

查看IIS核心日志 #

• 站点日志默认路径：C:\inetpub\logs\LogFiles\W3SVC{站点ID}，重点关注sc-status为502/503的请求，这类状态码通常对应应用池崩溃或回收。
• 开启失败请求跟踪规则：在IIS站点的“失败请求跟踪”中，添加规则捕获5xx状态码的请求，生成的日志会包含请求处理的完整流程，定位具体出错模块。

检查应用池配置 #

• 回收设置：查看应用池的“回收”选项，确认是否开启了固定时间回收、内存/CPU阈值回收。若存在无规律回收，可临时关闭自动回收，观察问题是否复现。
• 闲置超时：默认20分钟无请求会回收进程，若应用访问量低，可将“闲置超时”改为0（禁用）或延长时间。
• 进程模型：检查“进程模型”中的“最大工作进程数”、“队列长度”，避免因请求堆积导致进程崩溃。

查看WAS服务日志 #

在事件查看器的「Windows日志→系统」中，筛选来源为WAS（Windows Process Activation Service）的事件，WAS会记录应用池启动、回收、崩溃的详细原因。

三、分析进程崩溃原因 #

• 监控资源占用：用任务管理器跟踪w3wp.exe（ASP.NET Core托管进程）或dotnet.exe（自托管进程）的内存、CPU变化，若内存持续上涨，大概率存在内存泄漏。
• 生成并分析Dump文件：使用DebugDiag工具为应用池进程创建崩溃规则，当进程崩溃时自动生成Dump文件，再用WinDbg或DebugDiag分析Dump，定位崩溃的调用栈和触发点。
• 检查.NET Runtime事件：在事件查看器的「Windows日志→应用程序」中，筛选来源为.NET Runtime或ASP.NET Core的事件，部分进程崩溃会在这里留下未被常规日志捕获的错误信息。

四、Angular部署专项排查 #

• 若Angular打包后部署在ASP.NET Core的wwwroot下，检查打包文件完整性，确保dist目录所有文件都已上传至服务器，避免因缺失文件导致前端请求异常。
• 前后端分离部署时，检查前端API请求的超时设置、错误重试逻辑，频繁的异常请求可能触发后端的未处理异常，进而导致进程崩溃。
• SSR模式下，重点排查服务器端渲染时的组件错误，未捕获的渲染异常会直接终止ASP.NET Core进程，需在SSR启动代码中添加异常捕获逻辑。

五、系统环境排查 #

• 检查服务器资源：确认磁盘空间充足（避免日志写入失败）、内存未耗尽（系统会强制终止高内存进程）。
• 杀毒软件/防火墙：排除杀毒软件误杀dotnet.exe或w3wp.exe进程的可能，可临时关闭杀毒软件测试。
• .NET Core运行时：确保服务器安装的.NET Core运行时版本与应用开发版本兼容，避免因版本不兼容导致进程启动失败或崩溃。

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