本文介绍了导致应用程序因“EventType clr20r3, P1 w3wp.exe"而崩溃的未处理异常在日志中,但没有详细信息的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在生产服务器上,当 ASP .NET 应用程序崩溃时,我可以从系统事件查看器中看到此事件:

On the production server, I can see this event from system Event Viewer when an ASP .NET app crashes:

EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d691cc,
P4 app_web_default.aspx.cdcab7d2, P5 0.0.0.0, P6 4b2e4bf0, P7 4, P8 4, P9
system.dividebyzeroexception, P10 NIL.*

它属于.NET Runtime 2.0 错误报告"类别.

It belongs to ".NET Runtime 2.0 Error Reporting" category.

但我找不到属于ASP.NET 2.0.50727.0"类别的事件,它可以为我提供这样的详细视图:

But I can't find an event which belongs to "ASP.NET 2.0.50727.0" category which can give me this exception a detailed view like this:

An unhandled exception occurred and the process was terminated.
Application ID: /LM/W3SVC/505951206/Root
Process ID: 1112
Exception: System.DivideByZeroException
Message: Attempted to divide by zero.
StackTrace:
   at _Default.Foo(Object state)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp

我的开发机器上有第二个事件,是因为那里安装了 Visual Studio 吗?如果是这样,我该如何禁用它以便模拟生产环境?

I have the second event on my dev machine, is it because Visual Studio is installed there? If so, how can I disable this so I can emulate the production environment?

推荐答案

有时您可能会在 Windows 事件日志中看到这个可怕的错误:

Sometimes you may see this scary error in the Windows Event Log:

EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d6968e, P4 dp.ui, P5 3.9.7.55, P6 4b49a307, P7 62e, P8 0, P9 system.stackoverflowexception, P10 NIL.

如您所见,它不清楚并且没有堆栈跟踪,并且您对 P1、...、P10 和任何数字一无所知.您知道其中最糟糕的部分是什么;如果它不在日志中,唯一让你不睡觉并让你许愿的东西,是的!dp.ui"消息.

As you can see it is unclear and has no stack trace, and you don’t have any idea about P1, …, P10 and any numbers. You know which the worst part of that is; the only thing that make you not to sleep and make you wish if it wasn’t in the log, yes! The "dp.ui" message.

好的,除了所有的笑话和愿望之外,当发生无限循环或方法调用时,会引发异常system.stackoverflowexception",因此您应该检查所有源中是否存在任何递归方法调用,您可以启动 Visual Studi 进行调试那.但是,即使您的应用程序不是企业级的,也并非始终可行.所以你必须用谷歌搜索 P1,...,P10.是我代替你做的,所以请高枕无忧!

OK, besides of all jokes and wishes, the exception "system.stackoverflowexception" is raised when an infinite loop or method calling happen, so you should check all sources for any recursive method calling and you could fire up Visual Studi to debug that. But it is not possible and feasible all the time even if your application is not enterprise. So you have to google for P1, ..., P10. I did it instead of you, so just sit back and relax!

P1:出现此错误的应用程序名称
P2:应用程序版本
P3:应用时间戳
P4:组件/模块名称
P5:装配/模块版本
P6:组装/模块时间戳
P7:方法定义
P8:IL 偏移量
P9:异常名称(因为名称太长而散列)

P1: application name that has occurred this error
P2: application version
P3: application time stamp
P4: Assembly/Module name
P5: Assembly/Module version
P6: Assembly/Module timestamp
P7: MethodDef
P8: IL offset
P9: exception name (hashed because the name is too long)

很明显,我们需要找到 P7、P8.Visual Studio 中包含的工具 IL Disassembler 将帮助我们做到这一点.

It’s pretty obvious that we need to find P7, P8. IL Disassembler, a tool included in Visual Studio, will help us to do that.

  1. 执行 IL Disassembler,然后打开您的库.
  2. 菜单:view -> MetaInfo -> Show!,注意菜单的检查列表,尤其是 Raw 复选框.
  3. 将出现一个对话框,搜索 0600062e 的组合,您将看到该类的 MethodName,通过查找您将看到第一个 TypeDef 声明班上.仅此而已!
  1. Execute IL Disassembler, and open your library.
  2. Menu: view -> MetaInfo -> Show!, pay much attention to the check list of the menu, especialy Raw check boxes.
  3. A dialogue box will appear, search for combination 06000 with 62e and you will see the MethodName of the class and by looking up you will see the first TypeDef which declare the class. And that's all!

当您转到您的应用程序时,您可能会看到一个递归调用,您应该检查使该循环退出的条件!

As you go to your application you may see a recursive calling and you should check the condition that makes this loop exit!

在 Windows 和服务应用程序中,此异常可能如下所示,您应该通过IL Disassembler"检查sib.infobase.workflow.services.exe":

In windows and service application this exception maybe likes the following and you should check "sib.infobase.workflow.services.exe" by "IL Disassembler":

EventType clr20r3, P1 sib.infobase.workflow.services, P2 1.0.2740.20114, P3 468a74f5, P4 sbpscs, P5 1.0.2740.20087, P6 468a74be, P7 1c, P8 120, P9 zxkyzcs5wacordmkttdkr1

如果您在网上冲浪,您可能会看到 Microsoft 准备的解决方案:http://support.microsoft.com/kb/911816 ,但它可能不此异常无法正常工作.

If you surf in the net you may see a solution like Microsoft has prepared: http://support.microsoft.com/kb/911816 , but it may be don’t work properly for this exception.

查找方法报错桶参数

这篇关于导致应用程序因“EventType clr20r3, P1 w3wp.exe"而崩溃的未处理异常在日志中,但没有详细信息的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-15 02:01