包装代码以检测应用程序池崩溃的任何方法都将导致IIS 7 MVC 3.0崩溃 [英] Any way to wrap code to detect App pool crashs IIS 7 MVC 3.0

问题描述

我有一个MVC 3.0应用程序，当部署该应用程序时，每次运行某个页面时，该应用程序池都会崩溃.

I have an MVC 3.0 application that when deployed crashs the app pool every time a certain page is run.

基本上，此页面与其他页面没有任何不同 获取数据库记录并使用视图显示信息.

This page is not doing anything different to any of the other pages, basically Grabs a database record and presents the information using a view.

我无法弄清楚为什么崩溃会导致应用程序池关闭并关闭整个站点. 我已经安装了ELMAH日志跟踪并包装了基本控制器，但是由于应用程序池崩溃，因此没有日志写入ELMAH

I have not been able to figure out why it crashes causing the app pool to shut down and shutting down the entire site. I have install ELMAH log tracking and have wrapped a base controller but as the app pool crashes no logs get written to ELMAH

我尝试使用此方法捕获所有非托管异常
http://support.microsoft.com/kb/911816 但是应用程序池仍然崩溃，我离解决方案还很近.

I have tried to catch all unmanaged exceptions using this method
http://support.microsoft.com/kb/911816 however the app pool still crashs and I am no closer to finding a solution.

没有代码是非托管的，所以我不确定为什么会发生这种情况，只是对数据库的调用可能会失败，但是在数据库日志中看不到任何错误. 我正在使用DynamicMethod生成IL代码以映射到我的模型的数据库结构，但是相同的实现适用于其他模型，并且断开的调用在我的开发机上也可以.

None of the code is unmanaged so I am not sure why this is happening except for calls to the database that could be failing but see no errors in the database logs. I am using DynamicMethod to generate IL code to map to the database structure to my models but the same implementation works for every other model and the broken call works ok on my dev machine.

问题1 如果此IL生成的代码失败，那么是否仍应在标准请求错误处理中捕获该异常?

Question 1 If this IL generated code fails should the exception still be caught in the standard request error handling?

事件日志是隐秘的，几乎没有用.

Event logs are cryptic and next to useless.

Application: w3wp.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP      000007FEFA352648 (000007FEFA350000) with exit code 80131506.

用于64位窗口的DebugDiag仅允许我分析转储文件，而无法将其附加到应用程序池或IIS进程.

DebugDiag for 64 bit windows only allows me to analyze dump files and I am unable to attach it to app pool or IIS process.

在VS2010中，应用程序可以在调试和发布模式下完美运行.

Application runs perfectly in Debug and release mode in VS2010.

问题2 我正在32位上进行开发，但要部署到64位上.在某些情况下，某些情况在32位环境下可以正常工作，但在64位环境下会失败吗?

Question 2 I am developing on 32 bit but deploying to 64 bit. Is there any scenario where something works fine in 32 bit but fails in a 64 bit environment?

问题3 我不确定我可以通过其他日志记录或方法来找到此问题. 还有其他可用来包装我的请求的日志记录或代码，以尝试跟踪问题.

Question 3 I am not sure what other logging or approach I can do to find this problem. Is there any other logging or code I can wrap my request with to try and track the issue.

我敢肯定，Dynamic方法代码一定会崩溃，因此，如果任何人都可以回答Question1，那将真的有帮助

I am pretty sure it must be a crash in the Dynamic method code, so if anyone can answer Question1 then that will really help

推荐答案

好.问题出在DynamicMethod生成IL代码失败.

Ok The problem was with the DynamicMethod generate IL code was failing.

如果字段类型和数据库类型不匹配，则会使整个应用程序池崩溃

If the field type and database type did not match up it crashed the entire app-pool

应该在开发服务器上找到任何类型的不匹配项，但是 问题是int的数据库类型和Decimal的字段类型 并没有在32位开发计算机上中断，但在64位部署服务器上中断了.

Any type mismatches should of been found on the development server however the The issue was a database type of int and field type of Decimal did not break on the 32 bit dev machines but broke on the 64 bit deploy server.

将IL代码生成到dll并运行PEVerify时出现了问题.

Generating IL Code to a dll and running PEVerify showed the problem.

问题1.不，
问题2.在这种情况下，是
问题3. PEVerify，如果要生成IL代码，请始终通过PEVerify运行它.

Question 1. No,
Question 2. In this situation yes
Question 3. PEVerify, if you are generating IL code always run it through PEVerify.

这篇关于包装代码以检测应用程序池崩溃的任何方法都将导致IIS 7 MVC 3.0崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！