ASP.NET Core 3.1应用IIS启动时w3wp工作进程崩溃排查

问题背景 #

某ASP.NET Core 3.1 Web API应用在IIS中启动时直接崩溃，系统事件日志记录错误信息：

Faulting application name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899135
Faulting module name: ucrtbase.dll, version: 10.0.14393.3659, time stamp: 0x5e914092

故障现象为w3wp工作进程完全无法启动。该应用通过安装包自动完成所有配置发布，此前在20余台Windows Server 2012/2016/2019服务器上均验证可正常运行，本次故障出现在已安装全部最新系统更新、最新版.NET Core运行时的Windows Server 2016环境中。

通过Debug Diagnostic Tool抓取应用程序池崩溃转储后，分析堆栈定位到崩溃发生在ASP.NET Core Module（ANCM）启动标准流重定向阶段，完整堆栈如下：

[0x0]   ucrtbase!_invoke_watson + 0x12   
[0x1]   ucrtbase!_invalid_parameter + 0x75   
[0x2]   ucrtbase!_invalid_parameter_noinfo + 0xb   
[0x3]   ucrtbase!_fileno + 0x308a1   
[0x4]   aspnetcorev2!StdWrapper::StartRedirection + 0x39   
[0x5]   aspnetcorev2!StandardStreamRedirection::Start + 0x13e   
[0x6]   aspnetcorev2!StandardStreamRedirection::TryStartRedirection + 0x35   
[0x7]   aspnetcorev2!StandardStreamRedirection::{ctor} + 0x46   
[0x8]   aspnetcorev2!HandlerResolver::FindNativeAssemblyFromHostfxr + 0x233   
[0x9]   aspnetcorev2!HandlerResolver::LoadRequestHandlerAssembly + 0x369   
[0xa]   aspnetcorev2!HandlerResolver::GetApplicationFactory + 0x3d6   
[0xb]   aspnetcorev2!APPLICATION_INFO::TryCreateApplication + 0x2e8   
[0xc]   aspnetcorev2!APPLICATION_INFO::CreateApplication + 0x25a   
[0xd]   aspnetcorev2!APPLICATION_INFO::CreateHandler + 0x1b3   
[0xe]   aspnetcorev2!ASPNET_CORE_PROXY_MODULE::OnExecuteRequestHandler + 0x108   
[0xf]   iiscore!NOTIFICATION_CONTEXT::RequestDoWork + 0x2e3   
[0x10]  iiscore!NOTIFICATION_CONTEXT::CallModulesInternal + 0x4af   
[0x11]  iiscore!NOTIFICATION_CONTEXT::CallModules + 0x2b   
[0x12]  iiscore!NOTIFICATION_MAIN::DoStateRequestExecuteHandler + 0x40   
[0x13]  iiscore!NOTIFICATION_MAIN::DoWork + 0x116   
[0x14]  iiscore!W3_CONTEXT_BASE::StartNotificationLoop + 0x93   
[0x15]  iiscore!W3_MAIN_CONTEXT::OnNewRequest + 0xbf   
[0x16]  w3dt!UL_NATIVE_REQUEST::DoWork + 0xb0   
[0x17]  w3dt!UL_RECEIVE_CONTEXT::DoWork + 0x1b   
[0x18]  w3dt!WP_CONTEXT::OnCompletion + 0x3a   
[0x19]  w3tp!THREAD_POOL_DATA::ThreadPoolThread + 0xb0   
[0x1a]  w3tp!THREAD_POOL_DATA::ThreadPoolThread + 0x2b   
[0x1b]  w3tp!THREAD_MANAGER::ThreadManagerThread + 0x67   
[0x1c]  kernel32!BaseThreadInitThunk + 0x24   
[0x1d]  ntdll!__RtlUserThreadStart + 0x2f   
[0x1e]  ntdll!_RtlUserThreadStart + 0x1b  

排查步骤与转储重点检查项 #

堆栈明确指向崩溃发生在ANCM标准输出流重定向启动阶段，ucrtbase!_invalid_parameter报错代表传入CRT函数的参数非法，90%以上同类故障为配置问题，按以下优先级排查：

一、优先验证配置类问题 #

• 检查站点根目录下web.config内stdoutLogEnabled配置项，如果值为true，逐一核对stdoutLogFile配置的路径：
  • 路径不能包含特殊字符、中文、不存在的嵌套目录层级
  • 配置的日志存储目录必须提前手动创建，ANCM不会自动生成目录
  • 给应用程序池对应的运行身份授予该日志目录的写入、修改权限
• 直接给IIS AppPool\对应应用池名的系统账号授予站点根目录、.NET Core运行时目录的读取+执行权限，不要依赖默认权限继承逻辑
• 核对web.config内processPath配置的dotnet执行路径是否正确，确认IIS模块列表中存在正常安装的AspNetCoreModuleV2条目，版本与其他正常运行的同系统服务器一致

二、转储文件重点排查信息 #

如果配置核对后仍崩溃，在已抓取的dump中重点核查以下内容：

• 切换到堆栈对应的崩溃线程，查看aspnetcorev2!StdWrapper::StartRedirection方法的入参，重点确认传入的日志文件路径字符串是否为空、包含非法字符、长度异常
• 检查转储中加载的aspnetcorev2.dll、ucrtbase.dll版本号，确认和其他正常运行的Windows Server 2016服务器上的版本完全一致，排除系统补丁导致的版本不兼容问题
• 查看转储中的进程环境变量块，确认ASPNETCORE_ENVIRONMENT、DOTNET_ROOT等核心环境变量是否被服务器全局配置、IIS站点级环境变量配置篡改，指向了不存在的路径
• 检查ucrtbase.dll、kernel32.dll的加载地址是否存在异常Hook，部分EDR、杀毒软件会拦截系统文件操作函数，导致流初始化时传入无效句柄触发参数非法错误

三、快速复现定位方法 #

无需反复抓取转储，直接做独立启动测试即可快速定位根因：

• 打开命令提示符，切换到站点根目录，以应用池对应身份执行dotnet 应用入口程序集.dll，查看控制台是否直接抛出配置类错误
• 如果独立运行正常，临时将web.config里的stdoutLogEnabled设为false，重启站点后如果能正常启动，可100%确定为stdout日志路径或权限问题
• 临时关闭服务器上的杀毒软件、EDR类安全软件后测试，排除安全软件拦截导致的句柄无效问题

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