很难追踪导致我的应用程序池崩溃的进程

Question

所以我有一个不断崩溃的应用程序，它没有留下任何应用程序日志。当我最终去查看该服务器的事件查看器（服务器 2003 框）时，我发现了此错误（偶数源是 ASP.NET 4.0.30319.0）

发生未处理的异常，进程已终止。

应用程序 ID：/LM/W3SVC/2053196604/根

进程 ID： 24428

异常：System.IO.FileLoadException

消息：无法加载文件或程序集 'Microsoft.Practices.EnterpriseLibrary.Validation， version=5.0.505.0， 区域性=中性，公钥令牌=31bf3856ad364e35'或其之一 依赖。找到的程序集的清单定义没有 匹配程序集引用。（HRESULT的例外：0x80131040）

堆栈跟踪：

服务器堆栈跟踪：在 System.RuntimeTypeHandle.GetTypeByName（String name， Boolean throwOnError， boolean ignoreCase， boolean reflectionOnly， StackCrawlMarkHandle stackMark， Boolean loadTypeFromPartialName， ObjectHandleOnStack type） at System.RuntimeTypeHandle.GetTypeByName（String name， Boolean throwOnError， boolean ignoreCase， boolean reflectionOnly， StackCrawlMark&stackMark， Boolean loadTypeFromPartialName） at System.RuntimeType.GetType（String typeName， Boolean throwOnError， Boolean ignoreCase， Boolean reflectionOnly， StackCrawlMark&stackMark） at System.Type.GetType（String typeName） at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ContainerModel.Unity.UnityContainerConfigurator.AddValidationExtension（） 在 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ContainerModel.Unity.UnityContainerConfigurator..ctor（IUnityContainer 容器） 在 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.CreateDefaultContainer（IConfigurationSource 配置源） 在 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.SetCurrentContainerIfNotSet（） at Microsoft.Practices.EnterpriseLibrary.Logging.Logger.get_Writer（）
at Apriva.WebApi.Shared.Logging.DefaultLogWriter.Log（Object message， TraceEventType sreality， LogEntry& entry， String category， HttpContext 上下文）在 Apriva.WebApi.Shared.Logging.DefaultLogWriter.Info（对象消息， 字符串类别，HttpContext context） at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage（IntPtr md， Object[] args， Object server， Int32 methodPtr， Boolean fExecuteInContext， Object[]& outArgs） at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage（IMessage msg， IMessageSink replySink）

在 [0] 处重新引发异常：在 System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper（Message reqMsg， Boolean bProxyCase） at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke（Object NotUsed， MessageData&msgData） at Apriva.WebApi.Shared.Logging.Logger.LogDelegate.EndInvoke（IAsyncResult 结果）在 Apriva.WebApi.Shared.Logging.Logger.LogAsyncComplete（IAsyncResult ar） 在 System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage（IMessage 味精）在 System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage（IMessage msg， IMessageSink replySink） at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.DoAsyncCall（）
在 System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack（Object o） 在 System.Threading.QueueUserWorkItemCallback.WaitCallback_Context（对象 state） at System.Threading.ExecutionContext.Run（ExecutionContext executionContext， ContextCallback callback， Object state， Boolean ignoreSyncCtx） at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem（） at System.Threading.ThreadPoolWorkQueue.Dispatch（） at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback（）

有关详细信息，请参阅帮助和支持中心，网址为

当我在任务管理器中检查进程时，此PID不存在。我想这是因为它是一个 w3wp 过程。所以我去命令提示符并运行iisapp.vbs，它返回一个具有不同PID的进程。

该错误似乎意味着当找到的版本是 v5.0.505.0 时，存在对不同版本的企业库的配置引用进行验证，虽然我的项目有大量对企业库的引用，但没有一个引用验证包。

所以我的问题是 - 有人知道我下一步应该看哪里吗？我试图使用 PID 至少查看哪个应用程序导致错误，但这似乎并没有让我得到任何地方。

Answer 1

分析：从堆栈跟踪中可以清楚地看出，引用链是：Apriva.WebApi.Shared.Logging.DefaultLogWriter => Microsoft.Practices.EnterpriseLibrary.Logging.Logger => Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer => Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ContainerModel.Unity.UnityContainerConfigurator.类型为 Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ContainerModel.Unity.UnityContainerConfigurator 的方法"AddValidationExtension"需要来自"Microsoft.Practices.EnterpriseLibrary.Validation assembly with signature"的类型

可能的步骤找出根本原因：

1. 在视觉工作室中打开解决方案。
2. 转到编辑菜单->在文件中查找和替换->查找
3. 使用查找选项搜索 Microsoft.Practices.EnterpriseLibrary.Validation ->查看这些文件类型 -> *.csproj 您将获得引用此程序集的项目列表。
4. 在记事本中打开所有这些项目文件，找出哪个文件具有与版本=5.0.505.0、区域性=中性、公钥令牌=31bf3856ad364e35'不同的程序集签名

很可能你应该通过上述步骤成为罪魁祸首。我还建议检查程序集缓存并检查Microsoft.Practices.EnterpriseLibrary.Validation 程序集的签名，如果它与版本=5.0.505.0，区域性=中性，公钥令牌=31bf3856ad364e35'