Никаких признаков фатального исключения при сбое приложения | NLog версии 2 | Компактный фреймворк 3.5

У меня есть приложение .Net Compact Framework 3.5, которое использует Nlog версии 2.0 для регистрации информации, ошибок и фатальных исключений. В большинстве случаев ведение журнала работает должным образом и регистрирует фатальные исключения до сбоя. Но иногда наблюдается сбой приложения без каких-либо признаков ошибки / исключения.

Позвольте мне развить сценарий:

  1. Приложение создает несколько потоков, все потоки имеют блок try-catch, добавленный в начало их стеков вызовов. И, следовательно, регистрировать исключения плода перед сбоем.
  2. У основного потока есть «AppDomain.CurrentDomain.UnhandledException» для регистрации любых фетальных исключений в своем стеке вызовов.
  3. Приложение загружает некоторые сторонние управляемые библиотеки DLL и выполняет некоторые PInvokes для библиотек Wnce.

Но я считаю, что даже если какая-то сторонняя DLL выйдет из строя (или, скажем, она создаст новый поток, который выйдет из строя), я должен, по крайней мере, увидеть несколько ThreadAbortExceptions в журнале, зарегистрированном потоком моего приложения перед выходом.

Ключевые параметры конфигурации Nlog:

а. FileTarget.AutoFlush = true

б. FileTarget.KeepFileOpen = false

c. FileTarget не заключен в какую-либо асинхронную оболочку или в какую-либо буферизованную оболочку.

Пожалуйста, дайте мне знать, если я что-нибудь упустил.


crash nlog compact-framework windows-ce
person Abhinav Kapoor    schedule 04.01.2012    source источник
comment
Пожалуйста, не публикуйте тот же вопрос повторно. Если у вас есть дополнительная информация или вы хотите внести изменения, используйте ссылку «Изменить». Спасибо.   -  person Adam Lear    schedule 06.01.2012

Ответы (1)


arrow_upward
0
arrow_downward

Возможные причины сбоя включают исключение OutOfMemory или StackOverflowException. Из документации для последнего:

Рекомендации по версии

В предыдущих версиях .NET Framework ваше приложение могло перехватить объект StackOverflowException (например, для восстановления после неограниченной рекурсии). Однако такая практика в настоящее время не приветствуется, поскольку требуется значительный дополнительный код для надежного перехвата исключения переполнения стека и продолжения выполнения программы.

Начиная с .NET Framework версии 2.0, объект StackOverflowException не может быть перехвачен блоком try-catch, и соответствующий процесс завершается по умолчанию. Следовательно, пользователям рекомендуется писать свой код для обнаружения и предотвращения переполнения стека. Например, если ваше приложение зависит от рекурсии, используйте счетчик или условие состояния для завершения рекурсивного цикла. Обратите внимание, что приложение, в котором размещается среда CLR, может указать, что CLR выгружает домен приложения, в котором возникает исключение переполнения стека, и позволяет соответствующему процессу продолжаться. Дополнительные сведения см. В разделе Обзор интерфейса и хостинга ICLRPolicyManager.

person phoog    schedule 04.01.2012
comment
Спасибо за предложения. Мое приложение работает на Compact Framework 3.5. Я пробовал эмулировать оба условия в отдельном потоке. Для исключения Out of memory я получил System.OutOfMemoryException в потоке, в котором я написал код, а в других потоках я получил System.Threading.ThreadAbortException. Это было зарегистрировано в журналах приложений. И да, для исключения StackOverFlow нет логов. - person Abhinav Kapoor; 10.01.2012