诊断为控件的Paint事件或OnPaint方法行为不当。这些方法在设计时运行，因此您将获得控件的准确可视表示形式，例如，您可以在设计时查看PictureBox的Image属性。当这样的绘制事件陷入循环时，整个窗体将停止正确渲染。除了一个简单的bug之外，典型的原因是代码在设计模式下被非标准的运行时环境弄得很混乱。使用DesignMode属性可确保此类代码不会引起问题，并在设计模式下禁用。
找到行为不当的代码是一个挑战，特别是当这些不是您自己编写的控件时。除了逐个删除控件以找到麻烦制造者之外，您还可以通过启动Visual Studio的另一个示例来使用调试器，并使用Tools + Attach to Process来附加到第一个示例。

从个人经验来看，我可以确认这是Visual Studio 2003和2005中偶尔出现的问题，无论是使用VB还是C#。我们将两个版本都修补到最新的服务包，甚至直接从Microsoft获得了修补程序，但这两个版本都没有解决问题。
在Visual Studio 2003中的VB中，控件的消失也删除了底层设计器代码，因此我们必须从版本控制系统中恢复已删除的代码。非常烦人--因为我们经常会丢失代码更改，不得不重新开始。

你应该大胆地检查下一个链接：https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4
以下是网页上的一句话：
使用StarDefinitionsCanExceedAvailableSpace覆盖此设置覆盖新的GridRendering行为，基本上允许您在项目中使用.NET 4.7.x目标运行，但保留在以前版本中使用的旧行为。
可以在app.config中为应用程序设置一个配置设置：

<configuration>
     <runtime>
        <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
     />
    </runtime>
</configuration>

字符串
我可以验证使用该开关可以让我运行4.7.1，并且在任何缩放模式下都不会看到锁定。在我之后
我在4.6.2中运行的版本回来了，我再次在一个单独的分支中升级到4.7.1来尝试这个，果然切换使应用程序以4.7.1为目标运行。所以有一个很简单的解决方法。
不过，这是个变通办法。根据微软的说法，这个“修复”改进了网格渲染分配，提供了更精确的大小，还提高了性能并减少了内存使用。在纸面上这是一个很大的进步，但是...副作用😃
我怀疑这个问题并不普遍，因为没有太多关于它的信息。我认为Markdown Monster使这个问题出现，因为启动序列有很多窗口操作。MM使用MahApps UI框架，该框架使用窗口动画和主窗口的额外渲染帧，并且MM本身将窗口移到屏幕外以进行初始渲染，并且如果窗口不适合屏幕或将以其他方式移到屏幕外，则根据屏幕大小和DPI设置调整窗口大小。IOW，有一点旋转，以获得初始窗口到屏幕上，这是更有可能击中这个错误比一个简单的WPF形式。
因此，我怀疑每个应用程序都需要担心这一点，但如果您有一个4.7.x WPF应用程序，那么在各种分辨率和缩放级别下尝试它可能是一个好主意，只是为了看看它的表现如何。