里面的try / catch，Visual Studio中休息，结束于未处理的异常的应用程序 [英] Inside Try/Catch, Visual Studio breaks and ends app on Unhandled exception

查看：713
本文介绍了里面的try / catch，Visual Studio中休息，结束于未处理的异常的应用程序的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我在运行相同的code内，在Visual Studio之外时，得到不同的行为。

私人小组MyApplication_Startup（...）处理Me.Startup     ---处理程序处理异常     AddHandler的AppDomain.CurrentDomain.UnhandledException，AddressOf UnhandledExHandler     ---处理程序0     AddHandler的System.Windows.Forms.Application.ThreadException，AddressOf ThreadExHandler     Utils.RememberMainThreadId（） 结束小组 子OpenMyForm（）入口点     Debug.Assert的（Utils.RunningOnMainThread（））     尝试         MyForm.Show（）     抓住EX作为例外---处理1         LOGERROR（前）---到这里只有在Visual Studio之外启动     结束尝试 结束小组 子MyForm_Load（）处理MyBase.Load     Debug.Assert的（Utils.RunningOnMainThread（））     FillMyDataTable（）'---如果我把try / catch语句在这里，它永远是可行的（测试） 结束小组 子FillMyDataTable（）     尝试         新SqlClient.SqlDataAdapter（SQLCMD）.fill伪（myDataTable）     抓住EX作为例外---处理2         如果ex.Number = Constants.ConnectionBroken然后             ReconnectRetry（）         其他             投掷---进入UnhandledExHandler（）时，在Visual Studio         结束如果     结束尝试 结束小组

在Visual Studio中，在恶劣的SQL命令的错误去 UnhandledExHandler（）， 但如果同样的EXE是VS外推出，抓住EX作为例外在包装（）被触发（这是预期结果）。什么是错在这里？

  • Visual Studio中的错误信息是类型'System.Data.SqlClient.SqlException'的未​​处理的异常的文件名.exe发生。

  • 这在通话过程是发生在 MyForm.Show（）间接调用 MyForm_Load（）事件处理程序，并调用 MyComboBox_SelectedIndexChanged（）事件处理程序（而这一次间接地执行查询）。

  • 如果我找到并点击例外休息期间包装（）堆栈帧，我可以看到突出显示的呼叫FillMyDataTable（） 位于之间的尝试 / 捕捉。

  • 我总是在主线程（ ManagedThreadId 是启动活动过程中存储，则多个断言校验它插在上面的code）。

  • 堆栈跟踪是完全一样的（通过差异选中），除了最底层的框架（ System.Windows.Forms.NativeWindow.DebuggableCallback（）与 System.Windows.Forms.NativeWindow.Callback（））。

    • 在最上面的帧 System.Data.SqlClient.SqlConnection.OnError（SqlException异常，布尔breakConnection）。

  • 这是直到昨天的问题。我想我已经改变了一些选项。

  • 重新启动Visual Studio没有帮助的。

  • 目前的行为没有改变，如果在异常助手启用或禁用。

  • 选项和异常的设置是这样的：

  • 堆栈跟踪：

MYAPP.EXE！myApp.frmAPP_ prenosWizard.frmFT_ prenosWizard_Load（对象发件人，发送System.EventArgs）125线基本
System.Windows.Forms.dll中！System.Windows.Forms.Form.OnLoad（System.EventArgs发送）+ 0x1d5字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.OnCreateControl（）+ 0x55写入字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.CreateControl（布尔fIgnoreVisible）+ 0x181字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.CreateControl（）+ 0X24字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.WmShowWindow（参考System.Windows.Forms.Message M）+ 0x98在全局字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.WndProc（参考System.Windows.Forms.Message M）+ 0x2b6字节
System.Windows.Forms.dll中！System.Windows.Forms.ScrollableControl.WndProc（参考System.Windows.Forms.Message M）+ 0x2a字节
System.Windows.Forms.dll中！System.Windows.Forms.ContainerControl.WndProc（参考System.Windows.Forms.Message M）+ 0×10字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.WmShowWindow（参考System.Windows.Forms.Message M）+ 0×41字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.WndProc（参考System.Windows.Forms.Message M）+量0x154字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.ControlNativeWindow.OnMessage（参考System.Windows.Forms.Message M）+ 0×10字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.ControlNativeWindow.WndProc（参考System.Windows.Forms.Message M）+ 0X31字节
System.Windows.Forms.dll中！System.Windows.Forms.NativeWindow.DebuggableCallback（System.IntPtr的hWnd，INT味精，System.IntPtr WPARAM，System.IntPtr LPARAM）+ 0×57字节
[原产于托管过渡]
[托管到本机转换]
System.Windows.Forms.dll中！System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx（INT dwExStyle参数，字符串lpszClassName，串lpszWindowName，诠释风格，诠释的x，INT Y，INT宽度，高度INT，System.Runtime.InteropServices.HandleRef hWndParent ，System.Runtime.InteropServices.HandleRef HMENU，System.Runtime.InteropServices.HandleRef HINST，对象pvParam）+ 0x3C符号字节
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreateParams CP）+ 0x225字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.CreateHandle（）+ 0x125字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.CreateHandle（）+ 0x9f字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.Handle.get（）+×45字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.SetVisibleCore（布尔值）+ 0x160字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.Show（）+ 0×10字节
MYAPP.EXE！myApp.APP.cls prenos.ZobrazWizard（myApp.frmAPP_ prenosWizard.enRezim prenosu rezim，myApp.APP.clsEntita.enEntita zdrojEntita，整数zdrojID，myApp.APP.clsEntita.enEntita cielEntita，整数cielID，System.Data.SqlClient.SqlConnection CN1）线8212 +为0xA字节基本
MYAPP.EXE！myApp.frmMain.FCreateTransferUI（myApp.frmAPP_ prenosWizard.enRezim prenosu模式，myApp.APP.clsEntita.enEntita sourceEntity，整数的sourceID，myApp.APP.clsEntita.enEntita targetEntity，整型目标ID，系统.Data.SqlClient.SqlConnection CN1）线2410 + 0x17已字节基本
MYAPP.EXE！myApp.frmMain.frmMain_Receive（对象发件人，myApp.clsFisCommandProcessor.ReceivedEventArgs五）线239 + 0xa7字节基本
MYAPP.EXE！myApp.clsFisCommandProcessor.raise_Received（对象发件人，myApp.clsFisCommandProcessor.ReceivedEventArgs e）项96 + 0x2E读取字节基本
MYAPP.EXE！myApp.clsFisCommandProcessor.Execute（myApp.clsFisCommand命令，对象发件人）线136 + 0×57字节基本
MYAPP.EXE！myApp.clsFisCommandProcessor.Execute（myApp.clsFisCommand（）命令，对象发件人）线128 + 0x27字节基本
MYAPP.EXE！myApp.clsFisCommandProcessor.Execute（字符串进行扫描，布尔requireMarking，对象发件人）线122 +的0x30字节基本
MYAPP.EXE！myApp.frmCommandPad.TSMI_Execute_Click（对象发件人，发送System.EventArgs）线94 + 0x51字节基本
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripItem.RaiseEvent（对象键，System.EventArgs发送）+将0x58字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripMenuItem.OnClick（System.EventArgs发送）+ 0×46字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripItem.HandleClick（System.EventArgs发送）+ 0x6e字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripItem.FireEventInteractive（System.EventArgs发送，System.Windows.Forms.ToolStripItemEventType满足）+ 0X83字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripItem.FireEvent（System.EventArgs发送，System.Windows.Forms.ToolStripItemEventType满足）+量0x118字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripMenuItem.ProcessCmdKey（参考System.Windows.Forms.Message男，System.Windows.Forms.Keys KEYDATA）+ 0X47字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripManager.ProcessShortcut（参考System.Windows.Forms.Message男，System.Windows.Forms.Keys快捷键）+ 0x2dc字节
System.Windows.Forms.dll中！System.Windows.Forms.ToolStripManager.ProcessCmdKey（参考System.Windows.Forms.Message男，System.Windows.Forms.Keys KEYDATA）+ 0x2d字节
System.Windows.Forms.dll中！System.Windows.Forms.ContainerControl.ProcessCmdKey（REF System.Windows.Forms.Message味精，System.Windows.Forms.Keys KEYDATA）+ 0x3C符号字节
System.Windows.Forms.dll中！System.Windows.Forms.Form.ProcessCmdKey（REF System.Windows.Forms.Message味精，System.Windows.Forms.Keys KEYDATA）+ 0x29字节
System.Windows.Forms.dll中！System.Windows.Forms.Control.ProcessCmdKey（REF System.Windows.Forms.Message味精，System.Windows.Forms.Keys KEYDATA）+ 0x96字节
System.Windows.Forms.dll中！System.Windows.Forms.TextBoxBase.ProcessCmdKey（REF System.Windows.Forms.Message味精，System.Windows.Forms.Keys KEYDATA）+ 0xda字节
System.Windows.Forms.dll的！System.Windows.Forms.Control的。preProcessMessage（REF System.Windows.Forms.Message MSG）+ 0×90字节
System.Windows.Forms.dll!System.Windows.Forms.Control.$p$pProcessControlMessageInternal(System.Windows.Forms.Control目标，参考System.Windows.Forms.Message MSG）+ 0x101字节
System.Windows.Forms.dll的！System.Windows.Forms.Application.ThreadContext。preTranslateMessage（REF System.Windows.Forms.NativeMethods.MSG MSG）+ 0xf6字节
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.F$p$pTranslateMessage(ref System.Windows.Forms.NativeMethods.MSG MSG）+ 0x5的字节
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID，诠释原因，诠释pvLoopData）+ 0x22e字节
System.Windows.Forms.dll中！System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner（INT原因，System.Windows.Forms.ApplicationContext上下文）+ 0x177字节
System.Windows.Forms.dll中！System.Windows.Forms.Application.ThreadContext.RunMessageLoop（INT原因，System.Windows.Forms.ApplicationContext上下文）+ 0x61字节
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext上下文）+为0x18字节
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() + 0×81字节
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() + 0xef字节
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(string[]命令行）+ 0x68字节
[原产于托管过渡]
[托管到本机转换]
mscorlib.dll中！System.AppDomain.nExecuteAssembly（System.Reflection.Assembly组装，字串[] args）+的0x19字节
MSCORLIB.DLL！System.Runtime.Hosting.ManifestRunner.Run（布尔checkAptModel）+ 0x6e字节
mscorlib.dll中！System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly（）+的0x84字节
mscorlib.dll中！System.Runtime.Hosting.ApplicationActivator.CreateInstance（System.Activati​​onContext activati​​onContext，字符串[] activati​​onCustomData）+ 0x65字节
mscorlib.dll中！System.Runtime.Hosting.ApplicationActivator.CreateInstance（System.Activati​​onContext activati​​onContext）+是0xA字节
mscorlib.dll中！System.Activator.CreateInstance（System.Activati​​onContext activati​​onContext）+ 0x3E的字节
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() + 0x23字节
mscorlib.dll中！System.Threading.ThreadHelper.ThreadStart_Context（对象状态）+ 0x66字节
mscorlib.dll中！System.Threading.ExecutionContext.Run（System.Threading.ExecutionContext的ExecutionContext，System.Threading.ContextCallback回调，对象的状态）+ 0x6f字节
mscorlib.dll中！System.Threading.ThreadHelper.ThreadStart（）+ 0x44字节

解决方案

这个问题有许多移动部件，不知道我可以做正义的全部。出发点是，如果你使用一个调试器，你应该不订阅这些事件。总结了code与如果不System.Diagnostics.Debugger.IsAttached然后这样你就可以正确地诊断和修复未处理的异常。

一个显著随机发生器是将被扔在Load事件处理程序异常发生什么。微软有一个很大的上调，而在Windows回调是积极的麻烦妥善处理异常。如其中一种是引起Load事件火灾。他们改变了规则，在Vista中，再次Win7的，再次Win8的。他们是不同的，如果您运行的64位版本的32位。而你的程序是否为32位或64位进程运行。使用调试器改变的行为。当异常发生时，问你，如果你想你的程序是兼容的程序兼容性助手可能会出现。大家都说是的，当然，一个非常糟糕的主意。加入他们，你可以得到的 32 的不同的结果之一。哎哟。

这是正式的 但没有人能理解它这个MSDN文章。直到它不会做什么，他们希望，满身是一个问题<一href="http://stackoverflow.com/questions/4933958/vs2010-does-not-show-unhandled-exception-message-in-a-winforms-application-on-a">like这个。减轻处罚的情节是，当你调试应用程序这只是个字节，一般例外背停在消息循环确保这不会失控你的用户的机器上。换句话说，你所看到的，当你preSS Ctrl + F5键或运行与浏览器的程序，你可以期望它的工作方式。

这是一个影响到的任意的图形界面的Windows程序有问题。但它有被在WinForms应用程序特别麻烦的诀窍，程序员使用Load事件完全是太多了。蒙骗到它被它的默认事件Form类，它需要但双击生成它。尤其是在VB.NET，它不会自动创建构造形式和Visual Basic有使用Load事件初始化形式的遗产，可以追溯到VB6。

我通常会避免来看我看到的编程实践，但使用Load事件是因为这些问题今天真的相当糟糕的做法。总是青睐构造函数初始化类，任何.NET程序员都知道的规则，它不是Form类不同。有极其几个原因的有无的使用负载，包括在这个帖子。

I'm getting different behavior when running the same code inside and outside the Visual Studio.

Private Sub MyApplication_Startup(...) Handles Me.Startup
    '--- handler for unhandled exceptions
    AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf UnhandledExHandler
    '--- handler 0
    AddHandler System.Windows.Forms.Application.ThreadException, AddressOf ThreadExHandler
    Utils.RememberMainThreadId()
End Sub

Sub OpenMyForm()  'entry point
    Debug.Assert(Utils.RunningOnMainThread())
    Try
        MyForm.Show()  
    Catch ex As Exception  '--- handler 1
        LogError(ex)   '--- goes here only if launched outside the Visual Studio
    End Try
End Sub

Sub MyForm_Load() Handles MyBase.Load
    Debug.Assert(Utils.RunningOnMainThread())
    FillMyDataTable() '---if I put try/catch here, it will always work (tested)
End Sub

Sub FillMyDataTable()
    Try
        New SqlClient.SqlDataAdapter(sqlCmd).Fill(myDataTable)
    Catch ex As Exception '--- handler 2
        If ex.Number = Constants.ConnectionBroken then
            ReconnectRetry()
        Else
            Throw  '--- enters UnhandledExHandler() when in Visual Studio
        End If
    End Try
End Sub

In Visual Studio, error in bad SQL command goes to UnhandledExHandler(), but if the same EXE is launched outside the VS, Catch ex As Exception inside Wrapper() is triggered (this is expected result). What is wrong here?

  • Visual Studio error message is An unhandled exception of type 'System.Data.SqlClient.SqlException' occurred in filename.exe.

  • This is happening during call to MyForm.Show() which indirectly calls MyForm_Load() event handler and it calls MyComboBox_SelectedIndexChanged() event handler (and this one indirectly executes the query).

  • If I find and click Wrapper() stack frame during break on exception, I can see the higlighted call to FillMyDataTable() located between Try/Catch.

  • I'm always on main thread (ManagedThreadId is stored during Startup event, then multiple asserts verifying it are inserted in the above code).

  • Stack traces are exactly the same (checked via diff) except the bottommost frame (System.Windows.Forms.NativeWindow.DebuggableCallback() vs. System.Windows.Forms.NativeWindow.Callback()).

    • Topmost frame is System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection).

  • This was not the problem until yesterday. I think I have changed some option.

  • Restart of Visual Studio did not help.

  • There is no change in behavior if Exception assistant in enabled or disabled.

  • Options and exception settings are like this:

  • Stack trace is: 

myApp.exe!myApp.frmAPP_PrenosWizard.frmFT_PrenosWizard_Load(Object sender, System.EventArgs e) Line 125 Basic
System.Windows.Forms.dll!System.Windows.Forms.Form.OnLoad(System.EventArgs e) + 0x1d5 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Form.OnCreateControl() + 0x55 bytes   
System.Windows.Forms.dll!System.Windows.Forms.Control.CreateControl(bool fIgnoreVisible) + 0x181 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Control.CreateControl() + 0x24 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Control.WmShowWindow(ref System.Windows.Forms.Message m) + 0x98 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x2b6 bytes 
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) + 0x2a bytes    
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) + 0x10 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Form.WmShowWindow(ref System.Windows.Forms.Message m) + 0x41 bytes    
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x154 bytes    
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x10 bytes    
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes  
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes 
[Native to Managed Transition]  
[Managed to Native Transition]  
System.Windows.Forms.dll!System.Windows.Forms.UnsafeNativeMethods.CreateWindowEx(int dwExStyle, string lpszClassName, string lpszWindowName, int style, int x, int y, int width, int height, System.Runtime.InteropServices.HandleRef hWndParent, System.Runtime.InteropServices.HandleRef hMenu, System.Runtime.InteropServices.HandleRef hInst, object pvParam) + 0x3c bytes  
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.CreateHandle(System.Windows.Forms.CreateParams cp) + 0x225 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.CreateHandle() + 0x125 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Form.CreateHandle() + 0x9f bytes  
System.Windows.Forms.dll!System.Windows.Forms.Control.Handle.get() + 0x45 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Form.SetVisibleCore(bool value) + 0x160 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.Show() + 0x10 bytes   
myApp.exe!myApp.APP.clsPrenos.ZobrazWizard(myApp.frmAPP_PrenosWizard.enRezimPrenosu rezim, myApp.APP.clsEntita.enEntita zdrojEntita, Integer zdrojID, myApp.APP.clsEntita.enEntita cielEntita, Integer cielID, System.Data.SqlClient.SqlConnection cn1) Line 8212 + 0xa bytes   Basic
myApp.exe!myApp.frmMain.FCreateTransferUI(myApp.frmAPP_PrenosWizard.enRezimPrenosu mode, myApp.APP.clsEntita.enEntita sourceEntity, Integer sourceID, myApp.APP.clsEntita.enEntita targetEntity, Integer targetID, System.Data.SqlClient.SqlConnection cn1) Line 2410 + 0x17 bytes  Basic
myApp.exe!myApp.frmMain.frmMain_Receive(Object sender, myApp.clsFisCommandProcessor.ReceivedEventArgs e) Line 239 + 0xa7 bytes  Basic
myApp.exe!myApp.clsFisCommandProcessor.raise_Received(Object sender, myApp.clsFisCommandProcessor.ReceivedEventArgs e) Line 96 + 0x2e bytes Basic
myApp.exe!myApp.clsFisCommandProcessor.Execute(myApp.clsFisCommand command, Object sender) Line 136 + 0x57 bytes    Basic
myApp.exe!myApp.clsFisCommandProcessor.Execute(myApp.clsFisCommand() commands, Object sender) Line 128 + 0x27 bytes Basic
myApp.exe!myApp.clsFisCommandProcessor.Execute(String scan, Boolean requireMarking, Object sender) Line 122 + 0x30 bytes    Basic
myApp.exe!myApp.frmCommandPad.TSMI_Execute_Click(Object sender, System.EventArgs e) Line 94 + 0x51 bytes    Basic
System.Windows.Forms.dll!System.Windows.Forms.ToolStripItem.RaiseEvent(object key, System.EventArgs e) + 0x58 bytes 
System.Windows.Forms.dll!System.Windows.Forms.ToolStripMenuItem.OnClick(System.EventArgs e) + 0x46 bytes    
System.Windows.Forms.dll!System.Windows.Forms.ToolStripItem.HandleClick(System.EventArgs e) + 0x6e bytes    
System.Windows.Forms.dll!System.Windows.Forms.ToolStripItem.FireEventInteractive(System.EventArgs e, System.Windows.Forms.ToolStripItemEventType met) + 0x83 bytes  
System.Windows.Forms.dll!System.Windows.Forms.ToolStripItem.FireEvent(System.EventArgs e, System.Windows.Forms.ToolStripItemEventType met) + 0x118 bytes    
System.Windows.Forms.dll!System.Windows.Forms.ToolStripMenuItem.ProcessCmdKey(ref System.Windows.Forms.Message m, System.Windows.Forms.Keys keyData) + 0x47 bytes   
System.Windows.Forms.dll!System.Windows.Forms.ToolStripManager.ProcessShortcut(ref System.Windows.Forms.Message m, System.Windows.Forms.Keys shortcut) + 0x2dc bytes    
System.Windows.Forms.dll!System.Windows.Forms.ToolStripManager.ProcessCmdKey(ref System.Windows.Forms.Message m, System.Windows.Forms.Keys keyData) + 0x2d bytes    
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.ProcessCmdKey(ref System.Windows.Forms.Message msg, System.Windows.Forms.Keys keyData) + 0x3c bytes  
System.Windows.Forms.dll!System.Windows.Forms.Form.ProcessCmdKey(ref System.Windows.Forms.Message msg, System.Windows.Forms.Keys keyData) + 0x29 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Control.ProcessCmdKey(ref System.Windows.Forms.Message msg, System.Windows.Forms.Keys keyData) + 0x96 bytes   
System.Windows.Forms.dll!System.Windows.Forms.TextBoxBase.ProcessCmdKey(ref System.Windows.Forms.Message msg, System.Windows.Forms.Keys keyData) + 0xda bytes   
System.Windows.Forms.dll!System.Windows.Forms.Control.PreProcessMessage(ref System.Windows.Forms.Message msg) + 0x90 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Control.PreProcessControlMessageInternal(System.Windows.Forms.Control target, ref System.Windows.Forms.Message msg) + 0x101 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.PreTranslateMessage(ref System.Windows.Forms.NativeMethods.MSG msg) + 0xf6 bytes    
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FPreTranslateMessage(ref System.Windows.Forms.NativeMethods.MSG msg) + 0x5 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason, int pvLoopData) + 0x22e bytes  
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason, System.Windows.Forms.ApplicationContext context) + 0x177 bytes  
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x61 bytes    
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext context) + 0x18 bytes 
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun() + 0x81 bytes    
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel() + 0xef bytes   
Microsoft.VisualBasic.dll!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(string[] commandLine) + 0x68 bytes  
[Native to Managed Transition]  
[Managed to Native Transition]  
mscorlib.dll!System.AppDomain.nExecuteAssembly(System.Reflection.Assembly assembly, string[] args) + 0x19 bytes 
mscorlib.dll!System.Runtime.Hosting.ManifestRunner.Run(bool checkAptModel) + 0x6e bytes 
mscorlib.dll!System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly() + 0x84 bytes 
mscorlib.dll!System.Runtime.Hosting.ApplicationActivator.CreateInstance(System.ActivationContext activationContext, string[] activationCustomData) + 0x65 bytes 
mscorlib.dll!System.Runtime.Hosting.ApplicationActivator.CreateInstance(System.ActivationContext activationContext) + 0xa bytes 
mscorlib.dll!System.Activator.CreateInstance(System.ActivationContext activationContext) + 0x3e bytes   
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() + 0x23 bytes   
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x66 bytes   
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes    
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes

解决方案

This question has many moving parts, not sure I can do justice to all of them. Starting point is that you should not subscribe those events if you use a debugger. Wrap that code with If Not System.Diagnostics.Debugger.IsAttached Then so you can properly diagnose and repair unhandled exceptions.

A significant randomizer is what will happen with exceptions that are thrown in a Load event handler. Microsoft had a great deal of trouble properly handling exceptions that are raised while a Windows callback is active. Such as the one that causes the Load event to fire. They changed the rules at Vista, again at Win7, again at Win8. They are different if you run the 32-bit of the 64-bit version. And whether your program runs as a 32-bit or 64-bit process. Using a debugger alters the behavior. The Program Compatibility Assistant may appear when the exception occurs, asking you if you want your program to be "compatible". Everybody says Yes of course, a very bad idea. Adding them up, you can get one of thirty-two different outcomes. Ouch.

It is formally described in this MSDN article but nobody understands it. Not until it doesn't do what they hope for, covered in a question like this one. Mitigating circumstance is that this only bytes when you debug an app, the normal exception back-stop in the message loop ensures this doesn't get out of hand on your user's machine. In other words, what you see when you press Ctrl+F5 or run the program with Explorer is the way you can expect it to work.

This is a problem that affects any GUI program on Windows. But it has a knack of being especially troublesome in a Winforms app, programmers use the Load event entirely too much. Deluded into it by it being the default event for the Form class, it takes but a double-click to generate it. Especially so in VB.NET, it doesn't automatically create the constructor for a form and Visual Basic has a legacy of using the Load event to initialize a form, goes back to VB6.

I normally avoid judging programming practices I see, but using the Load event is today a really rather bad practice because of these problems. Always favor the constructor to initialize a class, a rule that any .NET programmer knows, it isn't different for the Form class. There are exceedingly few reasons to have to use Load, covered in this post.

这篇关于里面的try / catch，Visual Studio中休息，结束于未处理的异常的应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
C#/.NET最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆