c# - studio - kmsauto net 2016 excepcion no controlada en la aplicacion

VS2010 no muestra mensaje de excepción no controlada en una aplicación WinForms en una versión de Windows de 64 bits

Question

Cuando creo un nuevo proyecto, obtengo un comportamiento extraño para las excepciones no controladas. Así es como puedo reproducir el problema:

1) crear una nueva aplicación Windows Forms (C #, .NET Framework 4, VS2010)

2) agregue el siguiente código al controlador Form1_Load :

int vara = 5, varb = 0;
int varc = vara / varb;
int vard = 7;

Esperaría que VS se rompa y muestre un mensaje de excepción no controlada en la segunda línea. Sin embargo, lo que sucede es que la tercera línea simplemente se salta sin ningún mensaje y la aplicación sigue ejecutándose.

No tengo este problema con mis proyectos existentes de C #. Así que supongo que mis nuevos proyectos se crean con algunas configuraciones predeterminadas extrañas.

¿Alguien tiene una idea de lo que está mal con mi proyecto?

Intenté marcar las casillas en Depurar-> Excepciones. Pero luego las ejecuciones se rompen incluso si manejo la excepción en un bloque try-catch ; que tampoco es lo que quiero Si mal no recuerdo, había una columna llamada "excepciones no controladas" o algo así en este cuadro de diálogo, que haría exactamente lo que quisiera. Pero en mis proyectos solo hay una columna ("Lanzada").

Answer 1

Como Hans menciona, compila la aplicación y ejecuta el exe sin un depurador adjunto.

Para mí, el problema era cambiar un nombre de propiedad de Clase al que estaba vinculado un control BindingSource. Funcionando sin el IDE, pude ver el error:

No se puede enlazar a la propiedad o columna SendWithoutProofReading en el DataSource. Nombre del parámetro: dataMember

La reparación del control BindingSource para enlazar con el nombre de propiedad actualizado resolvió el problema:

Answer 2

En mi experiencia, solo veo este problema cuando estoy ejecutando un depurador adjunto. La aplicación se comporta igual cuando se ejecuta de forma independiente: la excepción no se ingiere.

Con la introducción de KB976038 , puede hacer que esto funcione como era de esperar. Nunca instalé la revisión, así que supongo que fue parte de Win7 SP1.

Esto fue mencionado en esta publicación:

• El caso de la excepción OnLoad que desaparece: excepciones de devolución de llamada en modo de usuario en x64

Aquí hay un código que habilitará la revisión:

public static class Kernel32
{
public const uint PROCESS_CALLBACK_FILTER_ENABLED = 0x1;
[DllImport("Kernel32.dll")]
public static extern bool SetProcessUserModeExceptionPolicy(UInt32 dwFlags);
[DllImport("Kernel32.dll")]
public static extern bool GetProcessUserModeExceptionPolicy(out UInt32 lpFlags);
public static void DisableUMCallbackFilter() {
uint flags;
GetProcessUserModeExceptionPolicy(out flags);
flags &= ~PROCESS_CALLBACK_FILTER_ENABLED;
SetProcessUserModeExceptionPolicy(flags);
}
}

Llámalo al comienzo de tu aplicación:

 [STAThread]
static void Main()
{
Kernel32.DisableUMCallbackFilter();
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}

Confirmé (con el ejemplo simple que se muestra a continuación) que esto funciona, tal como esperarías.

protected override void OnLoad(EventArgs e) {
throw new Exception("BOOM"); // This will now get caught.
}

Entonces, lo que no entiendo, es por qué antes era imposible que el depurador manejara cruzando fotogramas de pila en modo kernel, pero con este hotfix, de alguna manera lo descubrieron.

Answer 3

Este es un problema desagradable inducido por la capa de emulación wow64 que permite que el código de 32 bits se ejecute en la versión de 64 bits de Windows 7. Traga excepciones en el código que se ejecuta en respuesta a una notificación generada por el administrador de ventanas de 64 bits , como el evento Load . Impedir que el depurador lo vea y al intervenir. Este problema es difícil de solucionar, los grupos de Windows y DevDiv en Microsoft apuntan hacia adelante y hacia atrás. DevDiv no puede hacer nada al respecto, Windows cree que es el comportamiento correcto y documentado, por misterioso que suene.

Sin duda está documented pero casi nadie entiende las consecuencias o piensa que es un comportamiento razonable. Especialmente no cuando el procedimiento de la ventana está oculto a la vista, por supuesto, como en cualquier proyecto que use clases de contenedor para ocultar la plomería de la ventana. Como cualquier aplicación Winforms, WPF o MFC. El problema subyacente es que Microsoft no pudo descifrar cómo hacer que las excepciones del código de 32 bits vuelvan al código de 64 bits que desencadenó la notificación de nuevo al código de 32 bits que intenta manejar o depurar la excepción.

Solo se trata de un problema con un depurador conectado, tu código funcionará como siempre sin uno.

Proyecto> Propiedades> pestaña Construir> Objetivo de plataforma = AnyCPU y deshabilitar Preferencia de 32 bits. Su aplicación ahora se ejecutará como un proceso de 64 bits, eliminando el modo de falla wow64. Algunas consecuencias, deshabilita Editar + Continuar para las versiones de VS anteriores a VS2013 y es posible que no siempre sea posible cuando tiene una dependencia en el código de 32 bits.

Otras soluciones posibles:

• Depurar> Excepciones> marque el cuadro Lanzado para excepciones CLR para forzar al depurador a detenerse en la línea de código que arroja la excepción.
• Escriba try / catch en el controlador de eventos Load y failfast en el bloque catch.
• Use Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) en el método Main() para que la excepción trampa en el bucle de mensajes no se deshabilite en el modo de depuración. Sin embargo, esto hace que todas las excepciones no controladas sean difíciles de depurar, el evento ThreadException es bastante inútil.
• Considere si su código realmente pertenece al controlador de eventos Load . Es muy raro que lo necesite, sin embargo es muy popular en VB.NET y una canción de cisne porque es el evento predeterminado y un doble clic agrega trivialmente el controlador de eventos. En realidad, solo necesita Load cuando esté interesado en el tamaño real de la ventana después de que se apliquen las preferencias del usuario y la autoescala. Todo lo demás pertenece al constructor.
• Actualice a Windows 8 o posterior, tienen este problema wow64 resuelto.

Answer 4

Estoy usando WPF y encontré este mismo problema. Ya había probado las sugerencias de Hans 1-3, pero no me gustaron porque el estudio no se detuvo donde estaba el error (así que no pude ver mis variables y ver cuál era el problema).

Así que probé la cuarta sugerencia de Hans. Me sorprendió ver cuánto de mi código podía moverse al constructor MainWindow sin ningún problema. No estoy seguro de por qué tuve el hábito de poner tanta lógica en el evento Load, pero aparentemente gran parte de esto se puede hacer en el ctor.

Sin embargo, esto tuvo el mismo problema que 1-3. Los errores que ocurren durante el ctor para WPF se envuelven en una excepción Xaml genérica. (Una excepción interna tiene el error real, pero nuevamente quería que el estudio se rompa en el lugar del problema real).

Lo que terminó funcionando para mí fue crear un hilo, dormir 50ms, enviar de vuelta al hilo principal y hacer lo que necesito ...

 void Window_Loaded(object sender, RoutedEventArgs e)
{
new Thread(() =>
{
Thread.Sleep(50);
CrossThread(() => { OnWindowLoaded(); });
}).Start();
}
void CrossThread(Action a)
{
this.Dispatcher.BeginInvoke(a);
}
void OnWindowLoaded()
{
...do my thing...

De esta forma, el estudio se rompería justo donde ocurre una excepción no detectada.

Answer 5

Una simple Form_Shown podría ser si puede mover su código de inicio a otro evento como Form_Shown que llamó más tarde que Form_Load , y usar un indicador para ejecutar el código de inicio en la primera forma que se muestra:

bool firstLoad = true; //flag to detect first form_shown
private void Form1_Load(object sender, EventArgs e)
{
//firstLoad = true;
//dowork(); //not execute initialization code here (postpone it to form_shown)
}
private void Form1_Shown(object sender, EventArgs e)
{
if (firstLoad) //simulate Form-Load
{
firstLoad = false;
dowork();
}
}
void dowork()
{
var f = File.OpenRead(@"D:/NoSuchFile756.123"); //this cause an exception!
}