If an exception occurs in the event handler of the Load event, then when it is run from VS, it is not displayed - the method is simply interrupted and the form is displayed. This happens both at startup and during step-by-step debugging.

In previous versions of VS, this problem was solved by creating a new x64 build configuration. Although, it was necessary to set Empty as a baseline, which in itself is inconvenient, since it is necessary to re-configure alert levels.

But in VS2015 something good is not working. What to do?

Screen video problems (27MB).

PS: I found several such questions on enSO, but there are either terrible crutches or a description of the fact that this is related to the 32 bits of the application.

  • Here is an interesting article on this topic support.microsoft.com/ru-ru/kb/976038 - Dmitry
  • @Dmitry, --------------------------- Standalone Windows Update Installer ---------------- ----------- The update does not apply to this computer. --------------------------- OK ---------------------- ----- Or do you need to create with your hands? And help? - Qwertiy ♦
  • I think it is worth looking for a similar solution for your system. The list of systems updated by this update is not very wide, unfortunately - Dmitry
  • @Dmitry, I have Win7 x64 - it was there listed. - Qwertiy ♦
  • Yes, indeed, there is such. Are there any other mistakes or just this one? - Dmitry

1 answer 1

1. The first version of the English-speaking SO. I briefly copy:

Add a class to call the required functions:

 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); } }

Call it all at the start of the application:

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

2. The second option is to break the invalid context of the Form_Load call:

  private void Form1_Load(object sender, EventArgs e) { if (System.Diagnostics.Debugger.IsAttached) { //Форме рано представать перед пользователем. this.WindowState = FormWindowState.Minimized; this.ShowInTaskbar = false; Task.Run( delegate { //Это нужно, чтобы успеть посмотреть, как процесс //загрузки будет выглядеть для пользователя. //Thread.Sleep(3000); this.Invoke( new Action(delegate { FormLoadLogic(); //Теперь можно форму показать. this.WindowState = FormWindowState.Normal; this.ShowInTaskbar = true; })); }); } else { FormLoadLogic(); } } FormLoadLogic() { this.Text = "step 1"; throw new Exception("test"); this.Text = "step 2"; }
  • But these crutches will remain in the code, although they are not needed when running without VS. I would like to somehow make the debugger work correctly without crutches in the code. - Qwertiy ♦
  • @Qwertiy Crutches can be removed through the operation mode check. Now I will enter. - Zverev Evgeniy
  • #if DEBUG arrange? - Qwertiy ♦
  • @Qwertiy I do not like #IF DEBUG because I myself often use assemblies compiled in Debug in a production environment. I prefer System.Diagnostics.Debugger.IsAttached . I wrote it all in the code, look. - Zverev Evgeniy
  • #if DEBUG will be deleted during compilation, and the debugger check will be executed each time and will leave the code in the application. - Qwertiy ♦