visual-studio-2008 - configuracion - excepciones visual studio 2015
El depurador VS2008 no se rompe en excepción no controlada (6)
Ctl-D, E abre la ventana de Excepciones. Puede configurar las excepciones que desea y no quiere interrumpir.
Estoy teniendo un problema extraño con mi depurador vs. Al ejecutar mi programa en el depurador vs, el depurador no se rompe en una excepción no controlada. En cambio, el control se devuelve a VS como si el programa saliera normalmente. Si miro en la pestaña de salida, hay una excepción de primera oportunidad enumerada justo antes de la terminación del hilo.
Entiendo cómo usar el cuadro "Excepciones" del menú Depurar. Tengo un descanso en las excepciones no controladas marcadas. Si verifico excepciones de primera oportunidad para la excepción específica que está ocurriendo, el depurador se detendrá.
Sin embargo, tengo entendido que el depurador también debe detenerse en cualquier ''Excepciones no controladas''. No está haciendo esto por mí.
Aquí están las últimas líneas de mi pestaña de Salida:
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).
No entiendo por qué la excepción se marca como una excepción de "primera oportunidad" cuando no se maneja.
Creo que el código de salida 0xe0434f4d es un error COM genérico.
¿Algunas ideas?
Metro.
Hay dos casillas de verificación en el cuadro "Excepciones ...". Por lo general, tengo que hacer que se comprueben ambas para que se rompa con las excepciones no controladas. Independientemente de que solo se lea como si necesitaras tener una marcada.
Una vez cada vez esto me pasa a mí también. Parece un error o algo así, ya que cuando reproduzco el escenario, la excepción se detecta y se muestra como de costumbre.
Cuando leí la respuesta sobre tener dos casillas de verificación en el cuadro de diálogo "Excepción ...", volví y abrí el cuadro de diálogo otra vez. Solo tenía una columna de casillas de verificación para interrumpir "Lanzado".
Como resultado, si no tiene activado "Activar solo mi código (solo administrado)" en las opciones de depuración, la columna "Usuario no gestionado" no aparece en el cuadro de diálogo "Excepciones".
Seleccioné la opción "Habilitar solo mi código" y verifiqué que la casilla de verificación "No utilizado por el usuario" en el cuadro de diálogo "Excepciones" se seleccionó para todas las categorías de excepción.
Pude obtener excepciones no controladas para entrar en el depurador durante una sesión. Pero cuando volví al día siguiente, el comportamiento fue como antes.
Metro.
Si tiene un sistema operativo de 64 bits, es muy probable que lo muerda un comportamiento de nivel de sistema operativo que hace que las excepciones desaparezcan. La forma más confiable de reproducirlo es crear una nueva aplicación WinForm que simplemente arroje una excepción en OnLoad; parecerá que no es arrojado. Eche un vistazo a estos:
- Visual Studio no se rompe en la excepción no controlada con Windows de 64 bits
- http: // social.msdn.microsoft.com/Forums/en/vsdebug/thread/69a0b831-7782-4bd9-b910-25c85f18bceb
- El caso de la desaparición de la excepción OnLoad
- Excepciones silenciosas en máquinas de desarrollo x64 (Microsoft Connect)
- https: // connect.microsoft.com/VisualStudio/feedback/details/357311/silent-exceptions-on-x64-development-machines
El primero es lo que encontré de Google (después de que este hilo no ayudó), y ese hilo me llevó a los siguientes dos. El segundo tiene la mejor explicación, y el tercero es el bug / ticket de Microsoft (que reafirma que esto es un comportamiento "por diseño").
Entonces, básicamente, si su aplicación arroja una excepción que golpea un límite de modo kernel en su camino hacia atrás en la pila, se bloquea en ese límite. Y el equipo de Windows decidió que la mejor manera de lidiar con eso era pretender que se manejó la excepción; la ejecución continúa como si todo se completara normalmente.
Ah, y esto sucede en todas partes . Debug versus Release es irrelevante. .Net vs C ++ es irrelevante. Este es el comportamiento a nivel de sistema operativo.
Imagine que tiene que escribir algunos datos críticos en el disco, pero falla en el lado equivocado de un límite de modo kernal. Otro código intenta usarlo más tarde y, si tiene suerte, detecta que algo anda mal con los datos ... ¿pero por qué? Apuesto a que nunca consideras que tu aplicación no pudo escribir los datos, porque esperabas que se emitiera una excepción.
Jerks.
Tuve un problema similar, y al marcar "Habilitar solo mi código (solo administrado)" se solucionó el problema, mientras que si lo apagaba, el problema volvía, no se sabía por qué (pero es posible que aparezcan algunos DLL que aparezcan cargado cuando está desmarcado causa el comportamiento).