如何调试PerfMon.dll? / AssemblyBinding中的0xc0000409错误

Question

问题描述

我试图在客户的服务器(Win 2012R2)上调试一个问题，其中一个.NET应用程序托管在它们的IIS8.5.9600.16384中。最近，我们的一个技术支持更改了应用程序的Web.config文件中的一个小内部设置，并且根据它们，没有对系统进行任何其他更改或操作。应用程序也没有更新，以前一直在运行，没有任何问题。

由于该更改，不能再启动配置站点的AppPool。根据系统事件日志，有几次尝试启动，每次都会导致工作进程崩溃，直到池的快速失败保护完全停止启动进程为止。

而且，由于我是在客户的服务器上，所以我只有有限的调试选项。

调查结果

在系统事件日志中报告的是：

为应用程序池“我们的池”服务的进程与Windows进程激活服务(Windows process Activation )发生致命通信错误。进程id为'5664‘。数据字段包含错误号。 由于为应用程序池提供服务的进程(Es)发生了一系列故障，应用程序池“我们的池”被自动禁用。

查看相应的应用程序错误日志可以发现以下内容：

错误应用程序名称: w3wp.exe，版本: 8.5.9600.16384，时间戳: 0x52157ba0故障模块名称: PerfMon.dll，版本: 8.0.10977.0，时间戳: 0x59cfb424异常代码: 0xc0000409故障偏移量: 0x000f8c7b故障进程Id: 0x1620故障应用程序启动时间: 0x01d423ff75bef49f故障应用程序路径: C:\Windows\SysWOW64\inetsrv\w3wp.exe故障模块路径: C:\Program \Microsoft监控C：\Windows\SysWOW64\inetsrv\w3wp.exe报告id: b56327b3-8ff2-11e8-80d5-005056a52299故障包全名:故障包-相对应用程序ID：

在谷歌搜索此问题时，我主要关注的是PerfMon.dll问题和提供的错误代码0xc0000409，它显然要么与损坏的注册表项有关，要么与堆栈缓冲区溢出有关，但在这两种情况下，我都不知道原因是什么。

我还尝试了这里描述的崩溃转储分析( https://blogs.msdn.microsoft.com/parvez/2016/08/06/iis-application-pool-crash-and-debug-diag/ )

但最终看来，这只是一次返回到原来问题的往返旅行，因为这是在转储中发现的唯一错误：

来自微软公司的C:\Program \ Microsoft监控Agent\Agent\APMDOTNETAgent\V8.0.10918.0\PerfMon.dll中的PerfMon!DllGetClassObject+966fb的组装指令在线程2上造成了一个未知的异常(0xc0000409)。

这基本上就是我从事件日志中得到的。

我在这里的主要问题不仅是这个问题的原因和潜在的解决办法，还在于如何从一开始就正确地找到原因/解决方案。

更新

使用融合日志，我为System.Web.DynamicData，System.Web.Extensions和System.ServiceModel.web.找到了三个绑定错误

手术失败了。绑定结果: hr = 0x80004005。未指定错误 程序集管理器从:在可执行的>C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll下运行的C:\Windows\SysWOW64\inetsrv\w3wp.exe加载--详细的错误日志如下所示。 ===预绑定状态信息===日志: DisplayName = System.ServiceModel.Web，Version=4.0.0.0，Culture=neutral，C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary (完全指定)日志: Appbase = app根路径日志:初始PrivatePath = app根bin目录日志: Dynamic = PublicKeyToken=31bf3856ad364e35 ASP.NET Files\ root \bee9e73a日志: Cache Base = C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\ root \bee9e73a日志: AppName = b83a4ee调用程序集：(未知)。 拒绝代码共享，因为依赖程序集与条件APTCA共享模式不匹配

搜索有关这方面的任何信息时，我只能找到一个与MVC4 3/MVC4 4相关的旧错误，该错误需要进行配置更改。不过，这与这个问题无关。这也可能意味着原始错误与PerfMon完全无关，而原始错误只是一个奇怪的副作用。

Answer 1

我只想补充一下，我们现在在Windows 2012上遇到了这个(或类似的)问题，并通过删除服务来解决这个问题，就像这篇非常精彩的博客文章：http://kevingreeneitblog.blogspot.com/2017/03/scom-2016-agent-crashing-legacy-iis.html所描述的那样

(博客文章中描述的问题应该只影响运行在较早的.NET框架版本上的应用程序，但我们经历了一个仅运行版本4的应用程序池。)

在我们的事件日志中：

Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x52157ba0
Faulting module name: PerfMon.dll, version: 8.0.11072.0, time stamp: 0x59c01c4c
Exception code: 0xc0000409
Fault offset: 0x000f8c7b
Faulting process id: 0x1ae8
Faulting application start time: 0x01d4eac448929ba3
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Program Files\Microsoft Monitoring Agent\Agent\APMDOTNETAgent\V8.0.11072.0\PerfMon.dll
Report Id: 8a700b62-56b7-11e9-8124-001dd8b71cba
Faulting package full name: