.Net 4.0 Windows 应用程序在 Windows Server 2008 下的 clr.dll 中崩溃
我有一个计划每天运行的 Windows 应用程序，但根据 EventViewer 中的以下日志，间歇性失败。
Faulting application name: MyApplication.exe, version: 1.0.0.0, time stamp: 0x4d54829a
Faulting module name: clr.dll, version: 4.0.30319.1, time stamp: 0x4ba21eeb
Exception code: 0xc0000005
Fault offset: 0x00000000000029e1
Faulting process id: 0xbb1c
Faulting application start time: 0x01cbd99223d8b4eb
Faulting application path: E:\MyApplication\MyApplication.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 7e74ec7e-45a5-11e0-a95d-003048de380d
在第二个 EventViewer 日志中，它显示：
The process was terminated due to an internal error in the .NET Runtime at IP 000007FEF97329E1 (000007FEF9730000) with exit code 80131506.
服务器是 Win Server 2008 R2，应用程序使用 .Net 4.0（您也可以在错误日志中看到）。
该应用程序集中使用多线程，从远程数据库读取数据并写入本地硬盘。
对导致此问题的原因有何猜测以及如何调查的建议？我不知道应用程序的生命周期（大约 5-10 小时）中哪里失败了。
I have a Windows application scheduled to run on a daily basis and fails intermittently as per the following log in EventViewer.
Faulting application name: MyApplication.exe, version: 1.0.0.0, time stamp: 0x4d54829a
Faulting module name: clr.dll, version: 4.0.30319.1, time stamp: 0x4ba21eeb
Exception code: 0xc0000005
Fault offset: 0x00000000000029e1
Faulting process id: 0xbb1c
Faulting application start time: 0x01cbd99223d8b4eb
Faulting application path: E:\MyApplication\MyApplication.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Report Id: 7e74ec7e-45a5-11e0-a95d-003048de380d
And in the second EventViewer log it says:
The process was terminated due to an internal error in the .NET Runtime at IP 000007FEF97329E1 (000007FEF9730000) with exit code 80131506.
The server is Win Server 2008 R2 and the application uses .Net 4.0 (as you can see in the error log too).
The application uses multi-threading intensively and reads from a remote database and writes to local hard disk.
Any guesses on what causes this issue and any suggestions on how to investigate? I have no idea where it fails in the life of the application which is about 5-10 hours.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我有同样的问题。在应用寿命大约 8-10 小时时，CLR 错误会上升。我怀疑我的非托管代码在后台线程中生成异常。但我无法真正找出原因。但是，您可以尝试以下操作：
在执行它时。
(https://connect.microsoft.com/VisualStudio/Downloads)
如果您已经找到解决办法了。
I'm having the same issue. At approximately 8-10 hours of application life CLR error rises. I suspected my unmanaged code generating exception in the background thread. However I could not really find out why. You can give the following a try however:
while executig it.
(https://connect.microsoft.com/VisualStudio/Downloads)
Please let me know if you have already found a solution.
我有一个类似的问题，所以这可以帮助未来的用户找到解决方案：
我们使用 Apache log4net 作为应用程序日志。
更新到 DLL 版本 1.2.15 后，对于 dotnet Framwork 4.5，一旦日志文件达到最大大小 (10MB)，它就会开始触发此异常
I had a similar problem, so this can help future user to find a solution :
We use Apache log4net for application log.
After an update to DLL version 1.2.15, for dotnet Framwork 4.5 it starts to fire this exact exception once the log file reach the maximal size (10MB)
修补程序大部分已经消失，我也遇到了类似的问题，所以我将在这里分享我的答案。
我的解决方案围绕着我将 Lamda 传递给 P/Invoke 的事实：
https://stackoverflow.com/a/52360307/ 4700841
The hot-fix has mostly vanished and I faced a similar issue, so I'll share my answer here.
My solution revolved around the fact that I was passing a Lamda to a P/Invoke:
https://stackoverflow.com/a/52360307/4700841