Отладчик VS2008 не прерывается при необработанном исключении

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

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

Однако, насколько я понимаю, отладчик также должен останавливаться на любых «необработанных исключениях». Это не для меня.

Вот несколько последних строк моей вкладки «Вывод»:

A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll
The thread 0x60c has exited with code 0 (0x0).
The program '[3588] ALMSSecurityManager.vshost.exe: Managed' has exited with code -532459699 (0xe0434f4d).

Я не понимаю, почему исключение помечается как исключение «первого шанса», когда оно не обрабатывается.

Я считаю, что код выхода 0xe0434f4d является общей ошибкой COM.

Любые идеи?

Метро.


debugging unhandled visual-studio-2008
person Metro    schedule 19.09.2008    source источник

Ответы (6)


arrow_upward
5
arrow_downward

Если вы работаете в 64-битной ОС, вполне вероятно, что вас укусит поведение на уровне ОС, которое приводит к исчезновению исключений. Самый надежный способ воспроизвести это - создать новое приложение WinForm, которое просто генерирует исключение в OnLoad; будет казаться, что его не бросят. Взгляните на это:

  1. Visual Studio doesn't break on unhandled exception with windows 64-bit
    • http: // social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb
  2. Случай исчезновения исключения OnLoad
  3. Silent exceptions on x64 development machines (Microsoft Connect)
    • https: // connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines

Первое - это то, что я нашел в Google (после того, как эта ветка не помогла), и эта ветка привела меня к следующим двум. У второго есть лучшее объяснение, а третье - ошибка / тикет Microsoft (который еще раз подтверждает, что это поведение «по замыслу»).

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

Да, и это происходит везде. Сравнение отладки и выпуска не имеет значения. .Net против C ++ не имеет значения. Это поведение на уровне ОС.

Представьте, что вам нужно записать некоторые важные данные на диск, но это не удается на неправильной стороне границы режима ядра. Другой код пытается использовать его позже, и, если вам повезет, вы обнаружите, что с данными что-то не так ... но почему? Бьюсь об заклад, вы никогда не задумывались о том, что ваше приложение не смогло записать данные - потому что вы ожидали, что будет сгенерировано исключение.

Рывки.

person Granger    schedule 04.12.2010
comment
Обещаю, это было не из злого умысла! Альтернативы заключались в том, чтобы заставить вашу машину работать дополнительно, сверхмедленно (постоянно сохранять полный контекст регистра) или мгновенно сбрасывать ваше приложение после того, как исключение SEH возникает в обратном вызове пользовательского режима. Хорошая новость заключается в том, что обратные вызовы пользовательского режима выполняются исключительно (*) в оконных процедурах, поэтому это не влияет на сервисные приложения и не влияет на рабочие потоки (то есть на любой не оконный поток). - person Ana Betts; 14.01.2011
comment
@Paul - я действительно предпочел бы инстакрэш. По крайней мере, теперь я знаю, что я параноик. - person Granger; 27.01.2011
comment
@PaulBetts В вашем сообщении в блоге по этой проблеме утверждается, что Windows 7 решает эту проблему, потому что вы получаете одноразовое всплывающее окно от Ассистента совместимости программ. Это странное решение. Больше похоже на небольшой лейкопластырь. Конечно, настоящее исправление позволит вам снова начать отладку этих исключений, как обычно. - person Jez; 06.12.2014
comment
@Jez Одноразовое всплывающее окно применяется только к приложениям, у которых нет манифеста Win7. Новая разработка всегда должна иметь манифест Win7, что означает, что вы сможете отлаживать эти исключения, потому что вы получите (желаемое) поведение при сбое. - person Ana Betts; 07.12.2014
comment
@PaulBetts Интересно. За исключением того, что я все еще не могу заставить его работать. При использовании VS2013 с включенным манифестом с настройками по умолчанию, выбранными в свойствах нового приложения Windows Forms, исключения по-прежнему игнорируются в Form1_Load. Добавление app.manifest, раскомментирование совместимости с Win7 и выбор этого манифеста в свойствах по-прежнему игнорируют исключения, созданные в Form1_Load. - person Jez; 07.12.2014

arrow_upward
6
arrow_downward

Когда я прочитал ответ о наличии двух флажков в диалоговом окне «Исключение ...», я вернулся и снова открыл диалоговое окно. У меня была всего одна колонка флажков - для перерыва на «Заброшено».

Как оказалось, если в параметрах отладки не установлен флажок «Включить только мой код (только управляемый)», столбец «Необработанные пользователем» не отображается в диалоговом окне «Исключения».

Я выбрал параметр «Включить только мой код» и убедился, что флажок «Необработанные пользователем» в диалоговом окне «Исключения» был выбран для всех категорий исключений.

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

Метро.

person Metro    schedule 19.09.2008
comment
См. Мое сообщение, согласно которому возможно, что это связано с самой настройкой Enable Just My Code, и поэтому возможно, что в последнем сеансе этот параметр был каким-то образом отменен - person yoel halb; 25.07.2012

arrow_upward
2
arrow_downward

Ctrl-D, E вызывает окно Исключений. Вы можете установить, какие исключения вы хотите и не хотите прерывать.

person Community    schedule 19.09.2008

arrow_upward
0
arrow_downward

В поле «Исключения ...» есть два флажка, мне обычно приходится ставить оба флажка, чтобы отключить его при необработанных исключениях. Несмотря на то, что он читается только так, как будто вам нужно проверить один.

person hova    schedule 19.09.2008

arrow_upward
0
arrow_downward

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

person Morten Christiansen    schedule 19.09.2008

arrow_upward
0
arrow_downward

У меня была аналогичная проблема, и проверка «Включить только мой код (только управляемый)» устранила проблему, в то время как, если я выключил ее обратно, проблема вернулась, не знаю почему (но возможно, что некоторые библиотеки DLL, которые, похоже, получают загружается, когда он не отмечен, вызывает поведение).

person yoel halb    schedule 24.07.2012