这是wow64仿真层引起的一个令人讨厌的问题，它允许32位代码在64位版本的Windows
7上运行。它吞噬了响应64位窗口管理器生成的通知而运行的代码中的异常。
，就像
Load活动一样。阻止调试器看到它并介入。这个问题很难解决，Microsoft的Windows和DevDiv组正在来回指责。DevDiv对此无能为力，Windows认为这是正确且有据可查的行为，听起来像是神秘的。
它当然有据可查，但几乎没有人了解后果或认为这是合理的行为。当然，尤其是当窗口过程从视图中隐藏时，尤其是在使用包装程序类来隐藏窗口管道的任何项目中，这种情况尤其如此。像任何Winforms，WPF或MFC应用程序一样。根本的问题是Microsoft无法弄清楚如何将异常从32位代码流回到触发通知的64位代码，再流回到尝试处理或调试异常的32位代码。
连接调试器只是一个问题，您的代码将像往常一样炸毁而没有一个。
项目>属性>生成选项卡>平台目标=
AnyCPU并取消选中“首选32位”。您的应用程序现在将作为64位进程运行，从而消除了wow64故障模式。某些后果是，它会禁用VS2013之前的VS版本的“编辑+继续”功能，并且当您依赖于32位代码时，可能并非总是可能的。
其他可能的解决方法：
- 调试>异常>选中CLR异常的“抛出”框，以强制调试器在引发异常的代码行处停止。
- 在
Load
事件处理程序中编写try / catch，在catch块中进行failfast。 Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException)
在Main()
方法中使用，以便在调试模式下不禁用消息循环中的异常陷阱。但是，这使所有未处理的异常难以调试，该ThreadException
事件几乎没有用。- 考虑一下您的代码是否真正属于
Load
事件处理程序。很少需要它，但是它在VB.NET和一首天鹅之歌中非常流行，因为它是默认事件，并且双击可以轻松添加事件处理程序。在应用用户首选项和自动缩放后，您对实际窗口大小感兴趣时，才 真正 需要Load
。其他所有内容都属于构造函数。 - 更新到Windows 8或更高版本，他们解决了wow64问题。
