Blazor Server+EF数据库访问后应用池崩溃，如何获取调试信息？

问题背景 #

• 调试基于Entity Framework连接SQL Server的Blazor Server应用，已搭建最小复现项目：包含基础配置、单表DbContext、接收Account ID的控制器及查询数据库的服务。本地VS测试服务器可无限次访问，但部署到IIS后仅几次访问就触发“服务不可用”，提示应用池不健康，且无任何事件日志、IIS日志或异常信息；
• 已排查方向：使用DbContextFactory创建短生命周期DbContext、遵循Unit of Work原则、用using包裹DbContext实例、移除静态方法，问题仍存在。

调试信息获取方案 #

1. 启用应用级详细日志记录 #

在appsettings.json中配置更详细的日志级别，重点覆盖ASP.NET Core、EF Core相关类别：

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug",
      "Microsoft.AspNetCore": "Debug",
      "Microsoft.EntityFrameworkCore": "Debug",
      "Microsoft.EntityFrameworkCore.Database.Command": "Information"
    },
    "File": {
      "Path": "logs/app-{Date}.log",
      "Append": true,
      "LogLevel": {
        "Default": "Debug"
      }
    }
  }
}

同时在Program.cs中添加文件日志提供器（若未配置）：

builder.Logging.AddFile("logs/app-{Date}.log");

部署后定期检查日志文件，重点看崩溃前的最后操作记录。

2. 配置IIS进程崩溃转储 #

• 打开IIS管理器，找到目标应用池，右键选择高级设置；
• 在进程模型下，将生成崩溃转储设为On，指定转储文件路径（需确保应用池身份拥有该路径的写入权限）；
• 应用池崩溃时会生成.dmp文件，用Visual Studio或WinDbg打开转储文件，分析崩溃时的调用栈、内存占用情况，直接定位异常源头。

3. 添加全局异常捕获中间件 #

在Program.cs中添加全局异常捕获逻辑，确保所有未处理异常被记录：

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionFeature = context.Features.Get<IExceptionHandlerPathFeature>();
        if (exceptionFeature?.Error != null)
        {
            var logger = context.RequestServices.GetRequiredService<ILogger<Program>>();
            logger.LogCritical(exceptionFeature.Error, "未处理异常：{RequestPath}", exceptionFeature.Path);
        }

        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        await context.Response.WriteAsync("服务器内部错误");
    });
});

注意将此中间件放在app.UseRouting()之前，确保覆盖所有请求路径。

4. 检查SQL Server连接池状态 #

用SQL Server Management Studio执行以下查询，查看应用的数据库连接情况：

SELECT * FROM sys.dm_exec_connections WHERE program_name LIKE '%你的应用名称%'

• 检查连接数是否异常增长，若超过连接池最大限制（默认100），可临时调高连接字符串中的Max Pool Size值，观察是否缓解问题；
• 同时确认连接是否被正确释放，避免连接泄漏。

5. 启用Windows事件日志详细记录 #

• 打开事件查看器，导航到Windows日志 > 应用程序，右键选择属性；
• 勾选启用日志，设置较大的最大日志大小（如1GB），避免旧日志被自动覆盖；
• 同步检查系统日志，查看是否有IIS应用池回收、进程终止相关的错误或警告。

6. 本地模拟高并发测试 #

用Postman批量请求、Apache JMeter等工具在本地模拟高并发访问，尝试复现崩溃场景。此时本地VS可直接捕获异常，查看调用栈信息，对比IIS环境的差异，缩小问题范围。

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