应用程序崩溃时没有致命异常的迹象 |NLog 版本 2 |紧凑型框架 3.5 [英] No Signs of Fatal Exception when application crashes | NLog version 2 | Compact Framework 3.5

查看:17
本文介绍了应用程序崩溃时没有致命异常的迹象 |NLog 版本 2 |紧凑型框架 3.5的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 .Net Compact Framework 3.5 应用程序,它使用 Nlog 2.0 版来记录信息、错误和致命异常.大多数情况下,日志记录按预期工作,并在崩溃之前记录致命异常.但有时会观察到应用程序崩溃而没有留下任何错误/异常迹象.

让我详细说明一下场景:

<块引用>

  1. 应用程序创建的线程很少,所有线程都在其调用堆栈的开头添加了 try-catch 块.因此记录胎儿崩溃前的异常.
  2. 主线程有 'AppDomain.CurrentDomain.UnhandledException' 在其调用堆栈上记录任何胎儿异常.
  3. 该应用确实会加载一些第三方托管的 dll 并在 Wnce dll 上执行一些 PInvoke.

但我相信,即使某些第三方 DLL 崩溃(或者假设它创建了一个崩溃的新线程),我至少应该在日志中看到一些 ThreadAbortExceptions,之前由我的应用程序线程记录退出.

Nlog的关键配置参数有:

<块引用>

一个.FileTarget.AutoFlush = true

b.FileTarget.KeepFileOpen=false

c.FileTarget 未包装在任何异步包装器或任何缓冲中包装.

如果我遗漏了什么,请告诉我.

解决方案

崩溃的可能原因包括 OutOfMemory 异常或 StackOverflowException.来自后者的文档:

<块引用>

版本注意事项

在 .NET Framework 的早期版本中,您的应用程序可能会捕获 StackOverflowException 对象(例如,从无限递归中恢复).但是,目前不鼓励这种做法,因为需要大量额外的代码才能可靠地捕获堆栈溢出异常并继续执行程序.

从 .NET Framework 2.0 版开始,StackOverflowException 对象无法被 try-catch 块捕获,相应的进程默认终止.因此,建议用户编写代码来检测和防止堆栈溢出.例如,如果您的应用程序依赖于递归,请使用计数器或状态条件来终止递归循环.请注意,承载公共语言运行时(CLR)的应用程序可以指定CLR卸载发生堆栈溢出异常的应用程序域,并让相应的进程继续进行.有关详细信息,请参阅 ICLRPolicyManager 接口和托管概述.

I have a .Net Compact Framework 3.5 application that uses Nlog version 2.0 to log Info, Error and Fatal Exceptions. Most of the time the logging works as expected and logs fatal exceptions before crashing. But at times it is observed that application crashes without leaving any signs of an error/exception.

Let me elaborate the scenario:

  1. The Application creates few threads, all the threads have try-catch block added at the beginning of their call stacks. And hence log fetal exceptions before crashing.
  2. The main thread have 'AppDomain.CurrentDomain.UnhandledException' to log any fetal exceptions on its call stack.
  3. The application does load some third party managed dlls and performs some PInvokes on Wnce dlls.

But I believe even if some third party DLL crashes (or let’s say it creates a new thread which crashes), I should at least see some ThreadAbortExceptions in the log, logged by my application's thread before exiting.

The key configuration parameters of Nlog are:

a. FileTarget.AutoFlush = true

b. FileTarget.KeepFileOpen= false

c. FileTarget is not wrapped in any async wrapper or in any buffered wrapper.

Please let me know if I'm missing anything.

解决方案

Possible reasons for the crash include OutOfMemory exception or StackOverflowException. From the documentation for the latter:

Version Considerations

In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue. For more information, see ICLRPolicyManager Interface and Hosting Overview.

这篇关于应用程序崩溃时没有致命异常的迹象 |NLog 版本 2 |紧凑型框架 3.5的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆