有时候，你可能会看到在Windows事件日志这个可怕的错误：

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

事件类型clr20r3，w3wp.exe的P1，P2 6.0.3790.3959，P3 45d6968e，P4 dp.ui，P5 3.9.7.55，P6 4b49a307，P7 62E，P8 0，P9 system.***exception，P10 NIL。

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.***exception, 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.***exception时引发无限循环或方法调用发生，所以你应该检查所有来源的任何递归方法调用，你可以火起来的Visual Studi住宅调试那。但是，这是不可能的，可行的所有的时间，即使你的应用程序是不是企业。所以，你必须谷歌的P1，...，P10。我做了你这不是，所以只是高枕无忧！

OK, besides of all jokes and wishes, the exception "system.***exception" 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 ：MethodDef
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)

这是pretty的明显，我们需要找到P7，P8。 IL反汇编，工具包含在Visual Studio，将帮助我们做到这一点。

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反汇编器，并打开您的库。
2. 菜单：视图 - >元信息 - >显示!,重视对菜单的检查表，特别是具有原始复选框
。
3. 将出现一个对话框，搜索组合 06000 与 62E ，你会看到这个类的方法名并通过查找，你会看到它声明类到达第一个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!

在窗口和服务应用此异常可能喜欢以下内容，你应该IL反汇编检查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":

事件类型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 zxkyzcs5wacordmkttdkr1xouosi00fr，P10 NIL。

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 zxkyzcs5wacordmkttdkr1xouosi00fr, P10 NIL.

如果您在网上冲浪，你可能会看到一个解决方案，像微软prepared：   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.

1. http://www.netframeworkdev.com/common-language-runtime/clr20r3-from-a-windows-service-calling-a-dot-net-dll-32830.shtml
   
2. http://social.msdn.microsoft.com/Forums/en-US/netfxtoolsdev/thread/ec36eff9-ac9f-46da-afa1-92be489d6a56