为任何Cpu编译以及编译为x86时都会发生这种情况。除非调整其大小，否则GUI的各个部分不会重新绘制，例如，如果主窗体已最大化，则某些控件不会随之调整其大小，而其他控件的某些部分则不会重新绘制并显示以前的内容。
这在XP和Vista的32位计算机上都可以正常运行，但是在64位Vista(没有x64 XP可以测试)上，重绘无法正常工作。
任何人都对从哪里开始追踪有任何想法？
编辑:这发生在2台单独的计算机上，并且至少我当前使用的是具有NVidia的最新驱动程序。
Edit2:在我的64位计算机上运行32位XP虚拟机，该应用程序在VM中没有出现重绘问题
Edit3:这可能是驱动程序问题，但是我们不知道是否或何时驱动程序可以解决该问题。一位同事说，家里的ATI卡问题比NVidia少，但过去几个月我一直在每月更新我的视频驱动程序，但仍未解决，因此我们不能只发布产品并告诉我们的客户，驱动器制造商有一天可能会解决这个问题。
是否有人对要避免的事情有任何见识？我们正在编译为x86，而我们所有的组件都是x86。我似乎无法在测试项目中的任何组件上重现此问题，而且我还没有听到其他人在大多数组件论坛上报告过这些问题，因此很可能是我们正在做的事情。
最佳答案
这听起来像this问题。
在Windows上调整窗口大小时，通常会得到一个链，其中每个窗口都会收到WM_SIZE消息，然后在其子级上调用MoveWindow()(或类似名称)，而子级又会收到WM_SIZE，依此类推。我确信.NET会在幕后做同样的事情。
在x64上，Windows会限制此嵌套的深度，并且在特定点(嵌套的15-15个窗口)之后，它将不再发送WM_SIZE消息。在x86上似乎不存在此限制。此限制影响在Windows x64版本上运行的x86和x64代码。
这使我们困扰了很长时间，因为不同的x64安装会显示不同的症状。上面的MSDN博客文章有一些可能的解决方法-我们最终使用辅助线程异步地处理了窗口大小，这相当巧妙地解决了该问题。
关于winforms - 什么会导致.NET WInForms中的64位Vista而不是32位重新绘制问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/386826/