Поиск причины System.AccessViolationException

Наше приложение испытывает нечетное фатальное исключение System.AccessViolationException. Мы видим это, поскольку мы создали событие AppDomain.CurrentDomain.UnhandledException для регистрации исключения.

Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
   at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
   at System.Windows.Forms.Application.Run(Form mainForm)
   at Bootstrap.Run() in e:\build-dir\src\Bootstrap.cs:line 25

Само исключение, похоже, не содержит больше информации, чем сообщение "Попытка читать или записывать защищенную память. Это часто свидетельствует о том, что другая память повреждена".

Какие шаги мы можем предпринять, чтобы понять причину проблемы?
Есть ли способ определить незаконный адрес или значение указателя, вызвавшее сбой?
Можем ли мы выяснить, какой код библиотеки был причиной проблемы?
Можно ли включить дополнительную отладку/трассировку?

UPDATE

Может ли это быть вызвано более ранним нетепловым использованием WinForms API?

Ответ 1

То, что вы испытываете, - это точный эквивалент "У программы возникла проблема и она будет закрыта", за исключением того, что она попадает в среду выполнения .NET, а не в ОС.

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

Единственный способ отслеживать что-то вроде этого - это запустить собственные библиотеки под отладчиком, что должно уловить нарушение прав доступа до того, как оно пузырится до уровня CLR. Это может быть легко или сложно.

Если собственный код - ваш собственный проект, то самый простой способ установить это - это как проект .NET, так и проект С++ в том же решении, и убедитесь, что проект .NET ссылается на проект С++. Если вы разместите более подробную информацию о своей среде, я могу дать более конкретные советы.

Ответ 2

Трассировка стека указывает на плохие данные в параметре MSG встроенного мессенджера отправки. Вы пробовали загружать символы из Microsoft и проверять параметры этой трассировки стека.

Без знания элементов управления на вашем ui и любых событиях, с которыми вы подключились, будет сложно определить, в чем именно проблема.

Ответ 3

У меня была аналогичная проблема, в отличие от @BartRead, последовательно. Для меня некоторый код CLI работал нормально в простом приложении форм Windows, но когда я поместил его в экосистему плагинов larager (многопоточность), сообщения нуждались в перекачке с Application.Run или Application.DoEvents. Если у вас есть доступ к закачиваемому коду, лучшим вариантом (что сработало для меня) было комментировать все больше фрагментов кода, сохраняя при этом функциональность. Оказалось, что у меня не было GC:: Alloc'd callback/delegate, и в то время как он был закреплен и все еще упоминался, был перемещен в памяти или сразу же помечен для сбора.

если вы используете GC Alloc, обязательно очиститесь после себя!

Ответ 4

У меня возникла эта проблема при выполнении хранимой процедуры с использованием ADO. эта ошибка имела две причины:

строка плохой связи.
параметр-нечет-совпадение (переход в long для db-int32 или long в nvarchar (10), который короче)