Как следует диагностировать ошибку SEHException - Внешний компонент вызвал исключение

86

Каждый раз, когда пользователь сообщает об ошибке, например

System.Runtime.InteropServices.SEHException - Внешний компонент вызвал исключение?

Могу ли я, как программист, что-нибудь сделать, чтобы определить причину?

Сценарий: об этой ошибке сообщил один пользователь (использующий программу, написанную моей компанией). Это могло быть или не быть разовой ошибкой. Они упомянули, что за последний месяц компьютер дважды «переставал работать». На собственном опыте я научился не понимать это описание слишком буквально, поскольку обычно это означает, что кто-то, имеющий отношение к компьютеру, работает не так, как ожидалось. Они не смогли предоставить мне более подробную информацию, и я не смог найти никаких зарегистрированных ошибок. Следовательно, это могла быть или не быть эта ошибка.

Из трассировки стека фактическая ошибка возникла при создании класса, который напрямую не вызывает какой-либо код взаимодействия, но, возможно, осложнен тем, что объект может быть частью списка, привязанного к DevExpress Grid.

Ошибка была «поймана» подпрограммой необработанного исключения, которая обычно закрывает программу, но имеет возможность игнорировать и продолжить. Если они решили проигнорировать ошибку, программа продолжала работать, но ошибка возникла снова при следующем запуске этой процедуры. Однако после закрытия и перезапуска нашего приложения этого не произошло.

Рассматриваемый компьютер, похоже, не был перегружен. Он работает под управлением Vista Business, имеет 2 ГБ памяти и, согласно диспетчеру задач, он использовал только около половины этой памяти с нашим приложением, всего около 200 МБ.

Есть еще одна информация, которая может иметь или не иметь отношения к делу. В другом разделе той же программы используется сторонний компонент, который по сути представляет собой оболочку dotnet вокруг собственной библиотеки DLL, и у этого компонента есть известная проблема, при которой очень иногда вы получаете

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

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

Учитывая, что последствия ошибки незначительны (работа не теряется, перезапуск программы и возвращение туда, где они были, занимает не более минуты) и учитывая, что заказчик вскоре получит новую версию (с обновленной третьей- party), я, очевидно, могу скрестить пальцы и надеяться, что ошибка больше не повторится.

Но могу ли я еще что-нибудь сделать?

sgmoore
источник

Ответы:

28

Да. Эта ошибка представляет собой структурированное исключение, которое не было сопоставлено с ошибкой .NET. Вероятно, ваше сопоставление DataGrid выбрасывает собственное исключение, которое не было перехвачено.

Вы можете узнать, какое исключение происходит, посмотрев на свойство ExternalException.ErrorCode . Я бы проверил вашу трассировку стека и, если он привязан к сетке DevExpress, сообщил бы им о проблеме.

Рид Копси
источник
1
StackTrace нигде не упоминал DevExpress, а только мой класс. Придется проверить, какой был ErrorCode.
sgmoore
В таком случае попробуйте выяснить, что именно вызвало сообщение об ошибке.
Рид Копси
4
«посмотрев на свойство ExternalException.ErrorCode» - есть ли у вас какие-нибудь подсказки, как именно это сделать? VS показывает мне "Необработанное исключение типа 'System.Runtime.InteropServices.SEHException' произошло в .... dll Дополнительная информация: Eine externe Komponente hat eine Ausnahme ausgelöst.", Но кроме, например, приложений C #, ссылки нет посмотреть "Детали" объекта исключения где угодно.
OR Mapper
Отладчик VSCode показывает экземпляр $ exception в разделе Locals - это включает поле сообщения, которое включает код и удобочитаемое сообщение об ошибке.
nightblade9
8

У меня была аналогичная проблема с исключением SEHException, которое было вызвано, когда моя программа впервые использовала собственную оболочку dll. Оказалось, что нативная DLL для этой оболочки отсутствует. Исключение никоим образом не помогло решить эту проблему. Что помогло в конечном итоге, так это запуск procmon в фоновом режиме и проверка наличия ошибок при загрузке всех необходимых DLL.

Морис Гилден
источник
5

если у вас возникла проблема, описанная в этом посте:

Отладчик asp.net mvc генерирует исключение SEHException

тогда решение:

если у вас есть какое-либо приложение от Trusteer (например, rapport или что-то еще), просто удалите и перезагрузите свою систему, оно будет работать нормально ... нашел это решение здесь:

http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+thrown+when+I+run+the+application

Сафран Али
источник
3

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

Спросите у производителя компонентов, как проверить, является ли проблема, с которой сталкивается клиент, проблемой, которую, по их словам, они исправили в своей последней версии, без / до развертывания последней версии для клиента.

ChrisW
источник
1

Я столкнулся с этой ошибкой, когда приложение находится в общем сетевом ресурсе, и устройство (ноутбук, планшет, ...) отключается от сети во время использования приложения. В моем случае это произошло из-за того, что планшет Surface вышел за пределы диапазона беспроводной связи. Никаких проблем после установки лучшего WAP.

Конрад
источник
1
Я получал его случайным образом при доступе к различным видам отражения (GetAssemblyName, GetProperty, Activator и т. Д.) Как в моем коде, так и в сторонних библиотеках, и только в одной клиентской среде, аналогично с библиотеками в удаленном месте. Множество доказательств того, что это ошибка .net framework.
Андрей К.
Andriy K: Я не думаю, что это проблема .NET, я думаю, что дескрипторы открытых файлов в сетевом ресурсе как-то потеряны \ сброшены, возможно, ошибка в Windows или проблема с сетью. Сборки отображены в память и будут выгружаться с диска по запросу (бомба замедленного действия), возможно, память также может быть отброшена в ситуациях с нехваткой памяти. Если открытые ручки файлов нестабильны, это, вероятно, взорвется дымом. .NET мог бы обработать это и повторно открыть файл (сгладить проблему), но это может быть сложно.
osexpert 06
У меня такая же проблема. Я получаю System.Runtime.InteropServices.SEHException (0x80004005) без трассировки стека. Это InnerException исключения TargetInvocationException. TargetInvocationException действительно имеет трассировку стека, но для меня это не имело смысла, поскольку казалось, что оно исходит из main или Application.Run. Бывает очень случайно, в основном вечером \ ночью. Думаю, единственное «решение» - не запускать с сетевого диска: - | Возможно, я добавлю проверку, которая может заблокировать этот сценарий: stackoverflow.com/questions/8633680/…
osexpert
0

Еще одна информация ... Была эта проблема сегодня в системе Windows 2012 R2 x64 TS, где приложение было запущено из unc / сетевого пути. Проблема возникла для одного приложения для всех пользователей терминального сервера. Запуск приложения локально прошел без проблем. После перезагрузки он снова начал работать - выброшенное SEHException было Constructor init и TargetInvocationException


источник
0

Мои конфигурации машины:

Операционная система: Windows 10 версии 1703 (x64)

Я столкнулся с этой ошибкой при отладке моего проекта C # .Net в Visual Studio 2017 Community edition. Я вызывал собственный метод, выполняя p / invoke в сборке C ++, загруженной во время выполнения. Я столкнулся с той же ошибкой, о которой сообщил OP.

Я понял, что Visual Studio была запущена с учетной записью пользователя, которая не была администратором на машине. Затем я перезапустил Visual Studio под другой учетной записью пользователя, которая была администратором на машине. Вот и все. Моя проблема была решена, и я больше с ней не сталкивался.

Следует отметить, что метод, который был вызван на сборке C ++, должен был записывать несколько вещей в реестр. Я не отлаживал код C ++, чтобы выполнить некоторую RCA, но я вижу вероятность того, что все это не удалось, поскольку для записи реестра в операционной системе Windows 10 требуются права администратора. Итак, раньше, когда Visual Studio работала под учетной записью пользователя, у которой не было административных прав на машине, собственные вызовы не выполнялись.

RBT
источник
0

Я получил эту ошибку при выполнении модульных тестов на настроенное мной кеширование памяти. Залил кеш. После аннулирования кеша и перезапуска виртуальной машины все заработало.

AtreyHazelИспанский
источник