IIS多ASP.NET应用间歇性InvalidOperationException路径映射失败求助

问题背景 #

托管在同一IIS站点下的多个ASP.NET Web应用间歇性出现服务器错误，前端可见，事件查看器记录警告：

InvalidOperationException: Failed to map the path '/MyWebApp1/Scripts/App/Controllers/'

堆栈跟踪指向JS打包压缩过程中，从包提取文件时虚拟路径到物理路径的映射失败。问题仅在2个应用上出现，回收应用池+刷新缓存可临时解决；已排除权限差异、路径修改、可复现性等常规问题，怀疑与webengine4.dll的MgdMapPathDirect逻辑有关。

排查思路 #

1. 捕获异常发生时的上下文细节 #

在异常发生时记录更丰富的现场信息，而非仅依赖事件查看器：

• 在Global.asax中添加全局异常捕获逻辑，写入自定义日志：

  protected void Application_Error(object sender, EventArgs e)
  {
      var ex = Server.GetLastError();
      if (ex is InvalidOperationException invalidOpEx && invalidOpEx.Message.Contains("Failed to map the path"))
      {
          var logEntry = $"[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] 异常触发:\n" +
                        $"请求路径: {Request?.Path ?? "N/A"}\n" +
                        $"应用域ID: {AppDomain.CurrentDomain.Id}\n" +
                        $"当前进程ID: {System.Diagnostics.Process.GetCurrentProcess().Id}\n" +
                        $"应用池标识: {System.Security.Principal.WindowsIdentity.GetCurrent().Name}\n" +
                        $"完整堆栈: {ex.StackTrace}\n\n";
          System.IO.File.AppendAllText(@"D:\IISLogs\PathMappingErrors.log", logEntry);
      }
  }
  

• 日志可帮助定位异常是否和特定应用域、进程或用户标识相关。

2. 排查应用域回收与缓存冲突 #

问题仅在回收应用池后缓解，需验证缓存与应用域生命周期的兼容性：

• 检查应用池回收规则（IIS管理器→应用池→高级设置），对比异常发生时间与Event ID 5074（应用池回收）的时间点，看是否存在关联。
• 检查JS打包压缩的缓存逻辑：是否将资源路径缓存到了应用域级别的静态变量中？若缓存未处理AppDomain.DomainUnload事件，可能导致旧路径引用残留，引发间歇性映射失败。

3. 用ETW跟踪路径映射底层逻辑 #

针对webengine4.dll的MgdMapPathDirect，通过Windows事件跟踪（ETW）捕获底层操作：

• 创建跟踪会话：

  logman create trace AspNetPathTrace -ow -o C:\Traces\PathMap.etl -p "Microsoft-Windows-IIS-WebServer" 0xFFFF -p "Microsoft-Windows-ASP.NET" 0xFFFF -ets
  

• 异常发生后停止跟踪：

  logman stop AspNetPathTrace -ets
  

• 解析生成的ETL日志：

  tracerpt C:\Traces\PathMap.etl -o C:\Traces\PathMapReport.xml -of XML
  

• 在报告中搜索MgdMapPathDirect相关事件，查看路径解析失败的具体触发条件（如虚拟路径对应的应用是否在当时处于异常状态）。

4. 验证站点虚拟路径配置冲突 #

检查同一站点下的应用是否存在路径解析冲突：

• 确认所有应用的虚拟路径、虚拟目录无重叠，避免IIS在高并发下出现路径解析混淆。
• 排查是否有部署脚本、第三方工具动态修改过站点/应用的路径配置（即使你未手动修改）。

5. 监控应用池进程的文件系统操作 #

用Procmon捕获临时权限或路径不存在的场景：

• 打开Process Monitor，过滤目标应用池的w3wp.exe进程，设置过滤条件：
  • 操作类别：File System
  • 路径包含：/MyWebApp1/Scripts/App/Controllers/（转换为物理路径前缀）
• 异常发生时查看是否有PATH NOT FOUND或ACCESS DENIED事件，验证是否存在临时文件系统访问问题。

6. 检查打包工具的路径处理逻辑 #

针对JS打包压缩环节，验证路径配置的正确性：

• 检查BundleConfig（或对应打包工具配置）中的路径是否统一使用虚拟路径格式，避免相对路径与绝对路径混用。
• 手动触发应用域回收（修改web.config），验证打包资源是否能重新正确映射路径，模拟异常恢复场景的逻辑是否正常。

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