这会发生编译任何CPU以及编译到86时。 GUI的部分不重绘，除非它的大小，例如，如果主窗体最大化一些控制不调整其大小，以及其他一些区段不重绘并显示什么是previously有

This happens when compiling for Any Cpu as well as compiling to x86. Sections of the GUI doesn't redraw unless it's resized, for instance if the main form is maximized some of the controls don't resize with it, and others have sections that don't redraw and displays the what was previously there.

这工作正常在32位机器，无论是XP和Vista，但在64位Vista（没有64位XP来测试）重绘只是不能正常工作。

This works fine on 32-bit machines, both XP and Vista, but on 64-bit Vista (don't have x64 XP to test with) the redrawing just isn't working properly.

任何人有哪里开始跟踪下来的任何想法？

Anyone have any ideas on where to start tracking this down?

编辑：这发生在2个独立的机器，以及至少一个跟我现在已经从NVIDIA最新的驱动程序。

This occurs on 2 separate machines, and at least the one I'm currently on has the latest drivers from NVidia.

EDIT2：在我的64位计算机上运行32位的XP虚拟机和应用程序不能在虚拟机表现出了重新划分问题

Running a 32-bit XP virtual machine on my 64-bit machine and the application doesn't exhibit the redrawing issue in the VM

EDIT3：这可能是一个驱动程序的问题，但我们不知道是否或何时司机将解决这个问题。一位同事说，有带有ATI卡在家里比NVIDIA较少的问题，但我一直在更新我的视频驱动程序pretty的多每月在过去的几个月里，它仍然没有得到解决，所以我们不能只释放我们的产品，只是告诉我们的客户，有一天司机制造商可能避开固定这一点。

It may be a driver issue, but we don't know if or when drivers will fix the issue. A co-worker says there's fewer issues with an ATI card at home than with NVidia, but I've been updating my video drivers pretty much monthly for the past few months and it's still not resolved, so we can't just release our product and just tell our customers that some day the driver manufacturers may get around to fixing this.

有没有人有什么事情要尽量避免任何见解？我们正在编译为x86和我们所有的组件都是86。我似乎无法与任何测试项目的组成部分重现这个问题，我没有听到任何人报告的大部分组件论坛这些问题，所以它是相当可能的，这件事情我们正在做的。

Does anyone have any insight on what things to try to avoid? We're compiling as x86 and all our components are x86. I can't seem to reproduce this issue with any of the components in test projects, and I haven't heard anyone else report these issues on most of the the component forums, so it is fairly likely that it's something we're doing.

推荐答案

这听起来很可怕像这个问题。

That sounds horribly like this problem.

在Windows上调整窗口大小，你通常得到一个链，其中每个窗口收到 WM_SIZE 消息，然后调用的MoveWindow（）（或类似），在其子从而获得 WM_SIZE 等。我敢肯定，.NET确实在幕后同样的事情。

When resizing windows on Windows you typically get a chain where each window receives a WM_SIZE message and then calls MoveWindow() (or similar) on its children which in turn receive a WM_SIZE and so on. I'm sure that .NET does the same thing under the covers.

在64位，Windows限制了这种嵌套的深度，并有一定的点（12-15嵌套窗口）后，它只是不会发送 WM_SIZE 的消息了。这一限制似乎并不存在，在x86。此限制会影响在x64版本的Windows运行于x86和x64 code。

On x64, Windows limits the depth of this nesting, and after a certain point (12-15 nested windows) it will just not send the WM_SIZE messages anymore. This limitation does not appear to exist on x86. This limitation affects both x86 and x64 code running on x64 versions of Windows.

这foxed我们的年龄，不同的x64的安装会表现出不同的症状。上面的MSDN博客中有一些可能的解决方法 - 我们最终使用辅助线程异步做窗口大小，这个问题解决了相当整齐

This foxed us for ages, as different x64 installs would show different symptoms. The MSDN blog posting above has some possible workarounds - we ended up using a secondary thread to do the window sizes asynchronously, this solved the problem fairly neatly.