没有迹象的应用程序崩溃时致命异常| NLog版本2 |紧凑框架3.5 [英] No Signs of Fatal Exception when application crashes | NLog version 2 | Compact Framework 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的关键配置参数是：

a。 FileTarget.AutoFlush = true

b。 FileTarget.KeepFileOpen = false

c。 FileTarget不包装在任何异步包装器或任何缓冲的
包装器中。

请让我知道如果我缺少任何。

解决方案

崩溃的可能原因包括OutOfMemory异常或StackOverflowException。从后者的文档：

例如，从无界递归恢复）。但是，目前不鼓励这种做法，因为需要大量额外的代码来可靠地捕获堆栈溢出异常并继续程序执行。

从.NET Framework 2.0开始，try-catch块不能捕获StackOverflowException对象，并且相应的进程在默认情况下终止。因此，建议用户编写他们的代码来检测和防止堆栈溢出。例如，如果您的应用程序依赖于递归，请使用计数器或状态条件来终止递归循环。请注意，托管公共语言运行时（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屋！