我正在尝试调试一些处理大文件的工作.代码本身有效,但.NET Runtime本身报告了偶发错误.对于上下文,这里的处理是1.5GB文件(仅加载到内存中一次)被处理并在循环中释放,故意试图重现这个不可预测的错误.
我的测试片段基本上是:
try {
byte[] data =File.ReadAllBytes(path);
for(int i = 0 ; i < 500 ; i++)
{
ProcessTheData(data); // deserialize and validate
// force collection, for tidiness
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
GC.WaitForPendingFinalizers();
}
} catch(Exception ex) {
Console.WriteLine(ex.Message);
// some more logging; StackTrace, recursive InnerException, etc
}
(带有一些时间和其他东西)
循环将完全成功地处理非确定性迭代次数- 没有任何问题; 那么这个过程会突然终止.异常处理程序未被命中.测试确实涉及大量的内存使用,但它在每次迭代过程中锯齿非常好(没有明显的内存泄漏,并且我有足够的空间 - 在锯齿的最差点处有14GB未使用的主存储器) .该过程是64位.
Windows错误日志包含3个新条目,(通过退出代码80131506)建议执行引擎错误 - 一个讨厌的小动物.一个相关的答案,建议GC错误,用"修复"来禁用并发GC; 但是这个"修复"并不能解决这个问题.
澄清:这个低级错误没有触及CurrentDomain.UnhandledException事件.
澄清:GC.Collect只有监控锯齿状记忆,检查内存泄漏并保持可预测性; 删除它不会使问题消失:它只是使它在迭代之间保持更多内存,并使dmp文件更大; p
通过添加更多的控制台跟踪,我发现它在以下每个过程中出现故障:
foreach一些数据) …我有一个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个小时.
我有一个计算成本高昂的多线程C#应用程序,在运行30-90分钟后似乎一直崩溃.它给出的错误是
运行时遇到了致命错误.错误的地址是0xec37ebae,在线程0xbcc上.错误代码是0xc0000005.此错误可能是CLR中的错误,也可能是用户代码的不安全或不可验证部分中的错误.此错误的常见来源包括COM-interop或PInvoke的用户编组错误,这可能会破坏堆栈.
(0xc0000005是访问冲突的错误代码)
我的应用程序不会调用任何本机代码,或使用任何不安全的块,甚至任何非CLS兼容的类型,如uint.实际上,调试器所说的导致崩溃的代码行是
overallLength += distanceTravelled;
两个值都是类型的 double
考虑到这一切,我认为崩溃必定是由于编译器或CLR或JIT中的错误造成的.我想找出导致它的原因,或者至少写一个较小的复制品发送到微软,但我不知道从哪里开始.我从来没有必要查看CIL二进制文件,或编译的JIT输出,或本机堆栈跟踪(崩溃时没有托管堆栈跟踪),所以我不确定如何.我甚至无法弄清楚如何在崩溃时查看所有变量的状态(很遗憾,VS不会告诉我像在托管异常之后那样,并将它们输出到控制台/文件会减慢应用程序1000倍,这显然不是一个选项).
那么,我该如何调试呢？
[编辑]在VS 2010 SP1下编译,运行最新版本的.Net 4.0 Client Profile.显然它是".Net 4.0C/.Net 4.0E,.Net CLR 1.1.4322"
我有一个长期运行的.NET 4.5应用程序随机崩溃,留下我在事件日志中的问题标题中提到的消息.该问题在3种不同的机器和2种不同的系统上重现(2008 R2和2012).应用程序不使用任何不安全/非托管组件,它是纯托管.NET,唯一不受管理的东西是CLR本身.
这是我从转储中提取的崩溃站点的堆栈跟踪:
clr.dll!MethodTable::GetCanonicalMethodTable()
clr.dll!SVR::CFinalize::ScanForFinalization() - 0x1a31b bytes
clr.dll!SVR::gc_heap::mark_phase() + 0x328 bytes
clr.dll!SVR::gc_heap::gc1() + 0x95 bytes
clr.dll!SVR::gc_heap::garbage_collect() + 0x16e bytes
clr.dll!SVR::gc_heap::gc_thread_function() + 0x3e bytes
clr.dll!SVR::gc_heap::gc_thread_stub() + 0x77 bytes
kernel32.dll!BaseThreadInitThunk() + 0x1a bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes
这个问题与这里讨论的问题非常相似,所以我尝试了该主题中提出的解决方案,但没有一个帮助:
我已经尝试安装此修补程序,但它不会安装在我的任何机器上(KB2640103不适用,或被计算机上的其他条件阻止),这实际上是有道理的,因为我使用的是4.5,而不是4.0 .
我已经尝试禁用并发GC和/或启用服务器GC.现在我的app.config的相关部分如下所示:
<?xml version="1.0"?>
<configuration>
<runtime>
<gcConcurrent enabled="false"/>
<gcServer enabled="true" />
</runtime>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/> </startup></configuration>
虽然奇怪的是我仍然在进程转储中找到多个与GC相关的线程.除了发生崩溃之外,还有7个线程具有以下堆栈跟踪:
ntdll.dll!NtWaitForSingleObject() + 0xa bytes
KERNELBASE.dll!WaitForSingleObjectEx() + 0x9a bytes
clr.dll!CLREventBase::WaitEx() + 0x13f bytes
clr.dll!CLREventBase::WaitEx() + 0xf7 bytes
clr.dll!CLREventBase::WaitEx() + 0x78 bytes …根据MSDN的说法,有一个"提示"指出,在重负载下运行的.NET应用程序具有并发垃圾收集(无论是<gcConcurrent enabled="true"/>指定的还是未指定的,因为它是默认行为)可能会抛出ExecutionEngineException.是否有人知道Microsoft知识库文章或其他来源提供了额外的背景知识？
我们直接使用基于NHibernate 3.2的Windows服务应用程序,经过最多几个小时的运行后,它总是会崩溃.我们能够跟踪ISession.Flush()调用的异常.
nhusers上有一个线程报告似乎是同一个问题.他建议的解决方法,即禁用并发GC,到目前为止对我们有用,虽然切换到服务器模式GC(<gcServer enable="true"/>),隐式禁用并发GC,也做了伎俩.
在将此作为错误提交给MS之前,我想知道是否有人提供有关并发GC不稳定性的其他信息.
我的MyApp Form程序有一个问题,它包含一个带WebBrowser控件DLL(GeckoFX)的选项卡Control.
我的应用程序在关闭时没有任何异常或任何东西.它可能在几分钟后或10分钟后最大值发生.在visual studio中,我看到应用程序以代码0终止.任何事情.
在program.cs中,我抓住了所有这些未处理的重复
` // Add the event handler for handling UI thread exceptions to the event.
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(UIThreadException);
// Set the unhandled exception mode to force all Windows Forms errors to go through
// our handler.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
// Add the event handler for handling non-UI thread exceptions to the event.
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);`
我已经在Windows事件记录器中检查是否有任何错误,但它很干净.就像程序终止得好.我不知道它是否是Gecko DLL故障,但我不这么认为.
我使用httpWebRequest下载包含一些URL的列表.
然后我使用a Backgroundworker读取URL列表,并调用addTab Delegate Method Sleep,直到加载页面并继续其他AddTab Invoke.
当列表为空时,我检查在DOM页面中是否有某个字符串然后在Backgroundworker完成我关闭所有选项卡并处理它们然后我点击button1启动Backgroundworker1.asyncall();
我的逻辑有什么问题吗？我也会发布代码,我需要它太长但我真的需要了解哪里可能是终止我的应用程序的错误.如果有人可以帮我看看为什么它崩溃没有任何错误或任何我会欣赏的.
private void Start_Back_Click(object sender, EventArgs e) …完全随机,突然我们的应用程序在其生产环境中崩溃.该应用程序在Windows XP和.net framework 3.5 sp1上运行.在应用程序中,我们提供WCF服务,我们使用串行端口.
当应用程序崩溃时,它会在应用程序日志中留下消息:
.NET Runtime version 2.0.50727.3625 - Fatal Execution Engine Error (7A0BC59E) (80131506)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
和
Faulting application ***.exe, version 1.0.0.0, stamp 4f48b8fc, faulting module mscorwks.dll, version 2.0.50727.3625, stamp 4e154c98, debug? 0, fault address 0x000a03ea.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
在我们的测试环境中,我们遇到了类似的问题
在互联网上,我发现了几个相同的问题,都提到了热修复或重新安装.但我想知道发生了什么,不想发生什么.有谁知道会发生什么以及我们如何解决它？
[编辑]除了应用程序还安装了Sophos antivirus和MySql.
[编辑2]在我们的应用程序中,我们使用包装在.net包中的C库.我们在更多的应用程序中使用该库,并且它不提供例外.
[编辑3]无法回答我自己的问题嗯,我找到了一些东西:
http://support.microsoft.com/kb/959209/en-us 958481 .NET Framework 2.0 Service Pack 2的应用程序兼容性更新解决的问题列表
在.NET Framework 3.5 SP1中,由于在检查NULL值以支持地址空间布局随机化(ASLR)时所做的更改,故障情况会导致运行时中的访问冲突.此访问冲突表现为ExecutionEngineException异常.此外,该过程终止.
http://www.microsoft.com/download/en/details.aspx?amp;displaylang=en&id=10006
在应用程序服务器上间歇性地崩溃x64 dotnet服务时遇到了问题.该服务可以运行数小时,数天或数周,没有任何问题,但随后没有太多信息.
该服务在两个服务器上的集群(每个服务器3个服务)中运行 - 并且已经看到两个服务器上的任何服务都发生了崩溃.复制环境显示相同的行为,因此我"已经筋疲力尽"的配置问题.
最初从应用程序服务器的事件日志中提取的错误是:
Error message from event log on server XXXX
Application: MySvc.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime
at IP 000007FEEFD8CD4C (000007FEEFC70000) with exit code 80131506
这并没有显示太多细节,我在网上找到的最好的指针就是"交叉手指"......
http://www.jamesewelch.com/2010/09/30/troubleshooting-internal-error-in-the-net-runtime/
最后,在运行了一个月的AdPlus调试器后,我们遇到了一系列故障和一些故障转储.现在我有转储,我很难从中获得任何使用.
我之前已经调查了几个"悬挂"转储并取得了很大的成功,并阅读了很多Tess Ferrandez的博客等等,但我发现的'崩溃'转储被证明是最糟糕的.大多数对象,异常等都标记为垃圾收集,只剩下主线程 - 我可能会遗漏一些东西.
我将添加来自!analyze -v以及转储日志的详细信息 - 它们显示异常.
所以 - 关于这一点的真正问题是:有人可以给我一些关于从哪里开始的指示.转储日志中的异常与我在实际转储中看到的异常不匹配.
DUMP 1日志在这里:http: //pastebin.com/Eg5YCqww
DUMP 1分析:(我有一个符号问题我无法解决..)
0:000> !analyze -v
***
FAULTING_IP:
+112c9440
00000000`00000000 ?? ???
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: …所以我收到这个错误，看起来好像是一个损坏的垃圾回收：
完整的错误是：
由于.NET运行时在IP 71C571C8（71B20000）上出现内部错误，退出代码为80131506，该过程已终止。
它正在运行：
框架版本：v4.0.30319
当重复运行此功能时，会不一致地发生：
public static int GetMdiTitledChildWindows(IntPtr parentWindow)
{
IntPtr mdiClient = FindWindowEx(parentWindow, IntPtr.Zero, MdiClient, "");
List<IntPtr> handles = new List<IntPtr>();
EnumChildWindows(mdiClient, (hwnd, param) =>
{
handles.Add(hwnd);
return true;
}, IntPtr.Zero);
int counter = 0;
foreach (IntPtr handle in handles)
{
StringBuilder builder = new StringBuilder();
GetWindowText(handle, builder, GetWindowTextLength(handle)+1);
if (builder.Length > 0)
{
counter++;
}
}
return counter;
}
其中FindWindowEx()，EnumChildWindows()并且GetWindowText()都的P / Invoke签名定义类似于此：
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
private static …