Необработанное исключение в Finalizer не из нашего кода

Как мы можем решить необработанное исключение, созданное финализатором, которое явно происходит не из нашего кода?

По событию AppDomain.CurrentDomain.UnhandledException мы время от времени регистрируем исключение, которое не исходит из нашего кода и завершает работу программы. Трассировка стека начинается с метода Finalize() и вызывается в классе A, который мы нигде не используем.

Вопросы

  1. Можем ли мы каким-то образом обнаружить библиотеку/NuGet/проект, которые вызывают это?
  2. Can we maybe do some hard core hack like:
    • Changing GC behaviour (catching exceptions on finalizer, printing the faulted object ...)
    • Постоянно находить все экземпляры A в памяти и либо распознавать их происхождение (что их создало или имеет на них ссылку), либо самим вызывать их финализатор в нужный момент в try catch?
  3. Что-то другое?

КОНКРЕТНАЯ ИНФОРМАЦИЯ:

Полная трассировка стека начинается с кадров System.ComponentModel.Component.Finalize() и System.IO.FileSystemWatcher.Dispose(Boolean disposing). FileSystemWatcher является производным от класса Component, поэтому финализатор вызывается для класса FileSystemWatcher.

Мы нигде в нашем коде не используем класс FileSystemWatcher. Он может исходить от какого-то NuGet, но мы используем многие из них. Наше решение широкое, мы понятия не имеем, к чему это может привести. Мы используем .Net Core 2.2, работающий в докерах на Linux.

Зарегистрированная информация об исключении:

 AggregateException: One or more errors occurred. (Object reference not set to an instance of an object.); 
 InnerException: NullReferenceException: Object reference not set to an instance of an object. 

 Stacktrace: 
 at System.Threading.CancellationTokenSource.CallbackNode.<>c.<ExecuteCallback>b__10_0(Object s)
 at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
 --- End of stack trace from previous location where exception was thrown ---
 at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
 --- End of inner exception stack trace ---
 at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
 at System.IO.FileSystemWatcher.StopRaisingEvents()
 at System.IO.FileSystemWatcher.Dispose(Boolean disposing)
 at System.ComponentModel.Component.Finalize()

person frakon    schedule 18.10.2019    source источник
comment
Меня бы заинтересовала эта лямбда-функция.   -  person Taekahn    schedule 20.10.2019
comment
Ошибка - System.Threading.CancellationTokenSource.ExecuteCallbackHandlers, вызванная где-то Finalize. Ошибка также исходит из вашего приложения, иначе это будет исключение второго шанса. Хотя все это полезно знать, как это решит вашу проблему... а) улучшите ведение журнала, чтобы иметь возможность воспроизвести проблему, stackoverflow.com/questions/30326673/, b) откройте решение в ILSply и сохраните его как решение C#, найдите FileWatcher в пакете(ах) NuGet, вызывающем проблему.   -  person Jeremy Thompson    schedule 21.10.2019
comment
Является ли трассировка стека 1) исключением с корнем Finalize или 2) внутренним исключением? Если это из 1), можете ли вы сбросить трассировку стека из внутреннего исключения. Кроме того, как вы регистрируете ошибки? Может ли это повлиять на ваши выводы (например, nlog использует FileSystemWatcher)   -  person Simon Mourier    schedule 21.10.2019
comment
@SimonMourier, трассировка стека представляет собой комбинацию трассировки стека AggregateException и внутреннего исключения NullReferenceException, поэтому доступна полная трассировка стека. Логируем ошибки Serilog...   -  person frakon    schedule 21.10.2019
comment
@JeremyThompson Большое спасибо за ваши предложения, согласно им, мы попробуем эти две вещи: 1. б): использовать ILSpy для всего решения наиболее неисправный микросервис, затем подключитесь к нему с помощью удаленного отладчика VS и настройте его на прерывание только при NullReferenceExceptions. Когда он сломается, мы исследуем объект обратного вызова (лямбда-функция). Завтра у нас должны быть ответы.   -  person frakon    schedule 21.10.2019
comment
Может быть, вы можете попытаться сломать исключение при первом шансе, а затем посмотреть темы.   -  person Daniel W.    schedule 23.10.2019
comment
Это просто глупая ошибка, обновите до последней версии .netcore, чтобы исправить. Об этом можно было бы сказать много, но учтите, что Docker вам мало чем помог. Вероятно, заставил вас заблокировать глючную версию. В век agile важно постоянно обновляться. В целом, версия .NETCore major.x.y является рискованной для низких значений y, она еще не подвергалась достаточному практическому использованию.   -  person Hans Passant    schedule 24.10.2019
comment
ОБНОВЛЕНИЕ: Мы еще НЕ РЕШИЛИ. 1. Мы попробовали ILSpy, он нашел FileSystemWatcher только в AspNetCore, но не смог декомпилировать некоторые библиотеки, так что может быть и где-то еще. 2. Мы провели удаленную отладку, сломались при исключении, но оно показало окно, в котором код в данный момент не выполняется... и мы не смогли исследовать контекст исключения.   -  person frakon    schedule 25.10.2019
comment
НАШИ СЛЕДУЮЩИЕ ПОПЫТКИ: обновление до .Net Core 3, запуск в качестве консольного приложения без библиотек AspNetCore, проверка старых версий приложения, чтобы узнать, когда началось это исключение, запуск в Windows вместо Linux, ... Но мы сделаем эти шаги в месяц, так как сейчас мы должны разработать что-то еще. Если у вас есть какие-либо новые предложения, пожалуйста, оставьте их здесь.   -  person frakon    schedule 25.10.2019


Ответы (1)


На мой взгляд, здесь остается единственное решение — разделить вашу программу на несколько более мелких подпрограмм, если это возможно, и запустить каждую из них по отдельности, чтобы найти неисправный плагин. Подпрограммам не нужно выполнять значительную часть работы, которую выполняет вся программа. Это просто для теста.

person Farhad Rahmanifard    schedule 24.10.2019
comment
Финализатор обычно не вызывается в результате явного взаимодействия со сторонней библиотекой; он вызывается, когда сборщик мусора сканирует кучу объектов в поисках ссылок, которые можно освободить. Дополнительные сведения: docs.microsoft.com /en-us/dotnet/csharp/programming-guide/ - person Per Lundberg; 26.10.2019
comment
Я предлагаю другой способ (полностью изменил свой ответ)! - person Farhad Rahmanifard; 27.10.2019
comment
Лучше так, я удалил свой отрицательный голос. Тем не менее, мне интересно, не думает ли Ханс Пассант о чем-то здесь: 1#comment103406335_58444716" title="необработанное исключение в финализаторе не из нашего кода">stackoverflow.com/questions/58444716/ - person Per Lundberg; 29.10.2019