难倒在这里。之前发过类似的问题。我们有一个非常大的WPF应用程序，在某些机器上运行得很好，但在其他机器上，突然之间，其中一个CPU核心固定为100％（只有一个核心），应用程序冻结。通常在显示上下文菜单或组合框下拉（即弹出控件）时会发生这种情况，这就是为什么我们无法对此进行调试，因为此时没有用户代码执行。它让我们疯狂，因为在大多数机器上它运行良好，但在少数机器上，它会冻结。
奇怪的是，当我们在VM中运行它时，它也运行得很好！疯！不确定是什么导致了这个问题，或者更重要的是，哪里开始看起来因为正如我所说，没有用户代码在运行。
这只发生在我们机器的大约10％，但它始终发生在这些机器上。一切都很干净（即相对新鲜的操作系统安装，没有疯狂的应用程序等）和大多数相同的机器规格：类似的CPU，类似的RAM，相同的视频驱动程序和服务包。
正如我在标题中所述，任何人都可以提出可能的原因，为什么WPF应用会固定CPU并锁定某些计算机上的应用程序而不是其他计算机？我们只是难过！
答案 0 :(得分：7)
发现它!!事实证明.NET 4.0中有关于UI自动化和MS引入的更改的错误。这是信息，修复！ （注意：即使你打电话给MS，他们也会给你发一个链接，但它总是一个断开的链接。我设法手动跟踪它。）
注意：他们的文章讨论了导致此行为的特定情况，但如果您浏览一下，您会看到与这些DLL相关的大量问题。最新的是他们承诺在.NET 4.5运行时中提供修复（来自此问题的MS帖子。）
这是知识库文章......
http://support.microsoft.com/kb/2484841/en-us
...这是实际的修补程序 http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
答案 1 :(得分：0)
蹩脚的视频驱动程序？拉两台机器 - 一台发生，一台不发生，并开始分析差异。可能是硬件缺陷，坏视频驱动程序，该领域的任何事情。如果有人，WPF会使用GPU进行渲染。
答案 2 :(得分：0)
由于您似乎缺乏选项，我建议在Window中使用最基本的ComboBox创建一个新项目，几乎什么都不做。这应该工作（检查:-)）。然后在ComboBox中逐个添加功能并进行测试，例如添加命令时，从空的开始。这样做直到它“破裂”。所以你知道哪个特征是罪魁祸首 你没有说是否所有人都在使用软件渲染。