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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

asp.net mvc отладчик, бросающий SEHException

то решение:

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

http://forums.asp.net/t/1704958.aspx/8/10?Re+SEHException+ thrown+when+I+run + приложение +

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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

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