解释Visual Studio 2010及更高版本,WinForms和WPF中的严重错误 [英] Explain critical bug in Visual Studio 2010 and up, WinForms and WPF

查看:100
本文介绍了解释Visual Studio 2010及更高版本,WinForms和WPF中的严重错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请尝试将以下代码放入WinForms的Load事件处理程序中,或者将WPF放入Loaded.

Try putting the following code inside Load event handler for WinForms or Loaded for WPF.

Dim doc As New XmlDocument
Dim nsmgr As New XmlNamespaceManager(Nothing) 'this line throws an exception

问题是不会引发异常,并且会发生堆栈损坏.取决于IDE,它可能会有不同的副作用-见下文.

Problem is that exception is not thrown, and stack corruption happens. It may have different side effects, depending on the IDE - see below.

  • 受影响的IDE:2008、2010和2012(我可以测试的IDE). 2010重置堆栈状态,并从子/处理程序返回,就像什么也没发生一样(但不在那里进行其他语句). 2012可能会警告用户有关失败的应用程序以及尝试在compatibility mode中运行的信息.下次之后,它的运行方式与2010年相同.2008年会正常引发异常,但仅在默认配置(AnyCPU)上.将平台目标切换到x86也会使问题在2008年再次出现.
  • 受影响的框架是WinForms和WPF.控制台应用程序和ASP.NET 似乎工作正常. .NET v2.0-4.5.
  • 到目前为止,
  • 受影响的范围仅是Load个事件. 将此代码放入按钮即可使其工作.
  • 受影响的版本 配置=任何.尝试使用默认的DebugRelease.
  • Affected IDEs are: 2008, 2010 and 2012 (those I could test). 2010 resets stack state, and returns from sub/handler, like nothing happened (but without proceeding with other statements there). 2012 may warn a user about a failed application and an attempt to run in compatibility mode. Next time after that it runs the same as 2010. 2008 properly throws an exception, but only on default configuration (AnyCPU). Switching platform target to x86 makes the problem reappear in 2008 as well.
  • Affected frameworks are WinForms and WPF. Console apps and ASP.NET seem to work fine. .NET v2.0-4.5.
  • Affected scope is only Load event so far. Putting this code into a button makes it work.
  • Affected build configuration = any. Tried on default Debug and Release.

为什么我认为它是一个错误,是因为它会使对象处于不稳定状态-它们没有完成初始化,这不是预期的行为.至关重要的是,没有人会知道它发生了,因为它不会引发异常.根据您的设计,您最终可能会在数据库中得到不正确的数据,这在最坏的情况下可能会导致严重的后果.

Why I consider it a bug is because it can leave objects in an unstable state - they did not finish initializing, which is not an expected behavior. What's critical about it is that nobody will know it happened, as it does not throw an exception. Depending on your design, you may end up with incorrect data in your database, which in the worst case may lead to severe consequences.

有人对为什么会发生这种情况以及是否有解决方法有很好的解释吗?

Does anyone have a good explanation to why this may be happening and if there is a workaround?

推荐答案

问题是由在x64 OS上定位x86平台时发挥作用的wow64仿真层引起的. 它吞下负责引发Load事件的代码中的异常.
因此,调试器看不到异常,无法介入处理这种情况.

The problem is caused by the wow64 emulation layer that comes into play when you target x86 platform on a x64 OS.
It swallows exceptions in the code that is responsible to fire the Load event.
Thus the debugger doesn't see the exception and cannot step in to handle the situation.
This article seems to document well what's happening there,

此先前的答案(来自于Hans Passant)(所有的功劳和赞誉都来自于),解释了可能的解决方法.
我的首选之一是将所有内容移出Form_Load事件,然后将有问题的代码放入表单构造函数中. (当然,我不知道它是否适用于您的情况)

This previous answer from Hans Passant (to which goes all the credits and upvotes) explains possible workarounds.
My preferite one is to move everything out of Form_Load event and put the problematic code in the form constructor. (Of course I don't know if it is applicable in your case)

这篇关于解释Visual Studio 2010及更高版本,WinForms和WPF中的严重错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆