最近平板电脑异常发烫，检查发现是bitcomet占用了大量CPU，研究发现两个现象，可能是同一个原因引起的：1.即使上传下载速度为0，也会占用了大量CPU 2.退出软件后任务管理器查看进程还在且依旧占用CPU。
如下是通过AI分析dmp文件的原因： 1. 线程 0 (ID: f34) - 主线程 (被阻塞)
- 状态 : 卡在
ntdll!NtWaitForMultipleObjects+0x14。 - 原因 : 这是问题的表象 。主线程正在调用
WaitForMultipleObjectsEx，等待一个或多个子线程的句柄发出信号（即线程结束）。因为它等不到，所以自己被挂起。
- 线程 7 (ID: 27dc) - “DnsQuery” 线程 (被阻塞)
- 状态 : 卡在
BitComet+0x19559e。这是一个BitComet内部的函数，它之上是BitComet+0x5433a2和BitComet+0x539c89。这个调用链与网络操作密切相关。 - 根本原因 : 这个负责DNS查询的线程没有在等待退出信号，而是卡在了BitComet内部的网络操作函数中 。它很可能正在执行一个DNS查询或类似的网络操作，但这个操作由于某种原因没有返回 。这可能是因为：
- 一个质量很差的DNS服务器没有响应。
- 一个防火墙/安全软件拦截了DNS流量但没有正确返回错误。
- BitComet自身的网络代码在处理特定响应时存在Bug，进入了死循环或死锁。
- 线程 9 (ID: 12f0) - “MojoThread” 线程 (被阻塞)
- 状态 : 卡在
ntdll!NtRemoveIoCompletion+0x14和KERNELBASE!GetQueuedCompletionStatus+0x4f。 - 模块 : 这个线程不属于BitComet主程序，而是属于
EmbeddedBrowserWebView模块。 - 根本原因 : 这是最关键的发现 。"Mojo"是Chromium项目使用的进程间通信系统的名称。这个线程明确表明BitComet内嵌了一个基于Chromium的浏览器组件 （极大概率用于显示软件内的广告、新闻、种子详情页等）。
- 该线程正在等待一个I/O完成端口（I/O Completion Port）上的消息。它调用
GetQueuedCompletionStatus并永远没有收到任何消息 。这强烈表明：- 该浏览器组件正在等待一个网络请求（可能是广告请求）的返回，但这个请求被无限期挂起了。
- 或者，该组件的清理逻辑存在Bug，未能正确地向工作线程发送退出消息。
(不过还是挺奇怪的，最开始登陆不上的时候是有尝试重新输密码的)