当重装也无效时：我是如何揪出 Qt Designer 致命的“死循环幽灵”

案情回顾：诡异的“假死”事情是这样的：在一次手滑打开了别人发来的、存在格式错误的 .ui 文件后，我的 Qt Designer / Creator 就陷入了“永久罢工”——再也无法打开任何 .ui 文件。

具体症状是：Designer 一启动便疯狂吞噬内存（在我的电脑上甚至飙到 26GB），CPU 占用率拉满，但界面却迟迟不出现。

更诡异的是，程序并非“崩溃”，而是一种“假死”状态。因此，Windows 事件查看器里空空如也，没有任何错误日志。它只是在“穷忙”，忙到快要“撑死”，这让常规的日志分析方法彻底失效。

第一轮排查：清理、重装，然后绝望1. 清理项目缓存

我首先怀疑是程序在反复尝试加载那个已损坏的 .ui 文件。于是我删掉了整个本地项目，从 Git 仓库重新克隆了一份最干净的版本。结果令人沮丧：即便不加载任何项目，直接启动 Designer，问题依旧。

2. 清理用户配置

既然与项目无关，那问题很可能出在 Qt 保存的用户配置上。根据网上的资料，我“地毯式”地删除了相关文件：

注册表项 HKEY_CURRENT_USER\SOFTWARE\Trolltech 和 HKEY_CURRENT_USER\SOFTWARE\QtProject用户目录下的配置文件 %APPDATA%\QtProject 和 %LOCALAPPDATA%\QtProject然而，依旧失败……

3. 终极大招：重装

黔驴技穷，只能上“重装大法”了。我在 Maintenance Tool 里卸载了所有 Qt 组件，然后重新安装。

没想到，连重装大法也失灵了！

不会吧？难道真的要走到重装系统那一步？？？

峰回路转：一个顽固的线索就在我快要放弃时，一个细节带来了转机：我发现 Qt Creator 启动时，竟然还能显示“最近打开的项目”列表！

这说明，在某个我没找到的角落，一定还藏着未被清理的配置文件！

我转而使用 Geek Uninstaller 进行了更彻底的卸载，它确实扫描出了更多残留的注册表和目录。但清理过后，问题依旧，甚至……Creator 的最近项目记录还在？？？

小东西，你到底把你的缓存塞什么地方去了啊？？？

第二轮排查：请“神器”出山常规手段已无能为力，我决定请出 Windows 平台上的两大“神器”。

1. Process Explorer

我打开 Process Explorer，捕获到了 designer.exe 在 CPU 飙升时，占用率最高的那个线程的函数调用堆栈：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

0x0000000000000000

Qt6Core.dll!z_adler32_combine+0xbd408

Qt6Core.dll!ZN16QXmlStreamReaderC2ERK10QByteArrayNS_21PrivateConstructorTagE+0x2562

Qt6Core.dll!ZN16QXmlStreamReader8readNextEv+0x61

Qt6Xml.dll!ZNK12QDomDocument11toByteArrayEi+0x1df9

Qt6Xml.dll!ZN12QDomDocumentC2ERK16QDomDocumentType+0x167

Qt6Xml.dll!ZN12QDomDocument10setContentE14QAnyStringView6QFlagsINS_11ParseOptionEE+0x72

Qt6Designer.dll!ZN18qdesigner_internal10ZoomWidget11qt_metacallEN11QMetaObject4CallEiPPv+0x2956d

Qt6Designer.dll!ZN20QDesignerIntegration21removeDynamicPropertyERK7QString+0x63a

designer.exe+0x39255

designer.exe+0x20c0d

designer.exe+0x1a631

designer.exe+0x3fe46

designer.exe+0x12ef

designer.exe+0x13e6

KERNEL32.DLL!BaseThreadInitThunk+0x17

ntdll.dll!RtlUserThreadStart+0x2c

堆栈信息直指 Qt6Xml.dll！很明显，Designer 在处理某个 XML 文件时陷入了万劫不复的深渊。

为了确认不是 I/O 等待或进程死锁，我检查了进程的等待链（Wait Chain），一片空白。

案情逐渐明朗：问题并非 I/O 阻塞，而是一个计算密集型的死循环，元凶极有可能是一个损坏的 XML 文件！

2. Process Monitor：揪出“罪魁祸首”

要找到这个“罪魁祸首”的 XML，就轮到另一位神器 Process Monitor (ProcMon) 登场了。

我设置了两个过滤器：

Process Name is designer.exeOperation is ReadFile启动 Designer，开始捕获。结果如下：

真相大白！Designer 正在以惊人的频率反复读取同一个文件：%USERPROFILE%\.designer\gradients.xml。可以看到，读操作的偏移量 (Offset) 在飞速增长，一下子就飙到了几十万。

100% 确定，就是这个文件损坏了！

真相大白：一个损坏的渐变配置文件我打开了这个 gradients.xml 文件，它定义了 Designer 中可用的一些渐变色。

既然找到了元凶，解决办法就简单了：删掉它！

根据经验，这类配置文件在丢失后，程序启动时会自动重新生成一份默认版本。（我当时直接把整个 .designer 文件夹都送走了）。

果然，删掉文件后再次启动 Designer，久违的界面终于出现了，一切恢复正常。

最后吐槽该说不说，为什么现在的程序卸载时，就不能把自己在用户目录拉的“屎”清理干净呢？！