[Bug] backend 始终无法就绪：broker 恒定占用CPU约60秒、自身日志0字节、客户端持续 broker unavailable (-2)
环境
| 项目 |
值 |
| WeChatDataAnalysis |
v2.3.0（v2.2.1 / v2.1.5 表现完全一致） |
| native core |
buildId wcdb-prod-20260829-weixin-actions-1，有效期至 2026-10-13（未过期） |
| 微信客户端 |
Weixin 4.1.12.55（单实例，已登录并正常运行） |
| 操作系统 |
Windows 10 Pro 22H2 (10.0.19045)，系统代码页 936 |
| CPU / 内存 |
Intel i7-7500U（2核4线程 2.7GHz） / 16GB |
| TPM |
TPM 2.0 存在，状态 OK |
现象
启动失败：Backend process exited before becoming ready: http://127.0.0.1:10392/api/health
backend-stdio.log：
NativeCoreUnavailableError: wechatdb native get status failed: broker unavailable (-2)
NativeCoreUnavailableError: wechatdb native broker did not become ready in time.
Broker log: ...\logs\native-core-broker.log
The current broker run wrote no diagnostic output.
logs\native-core-broker.log 始终 0 字节。
broker 进程实测行为（多次重复，结果高度一致）
app 实际启动 broker 的命令行（进程监控捕获）：
wechatdb_broker.exe --endpoint \\.\pipe\LifeArchiveProject.WeChatDB.Native.<pid>.<hex>
--parent-pid <pid>
--device-key-name LifeArchiveProject.WeChatDB.Native.Device.v1
--disable-database
| 观测项 |
结果 |
| 命名管道 |
启动后 1 秒内创建成功 |
| CPU |
恒定约 87% 单核，线性累积，无收敛迹象 |
| 文件 I/O |
ReadTransferCount 全程 0.0 MB |
| 网络 |
全程 0 条对外TCP连接、0 条新DNS查询 |
| 工作集 |
恒定 约 23MB |
| 已加载模块 |
在 CPU=2.5s / 16s / 48s 三个时间点完全相同（含 bcrypt/ncrypt/crypt32/cryptnet/wintrust/ntasn1/dpapi/tbs.dll/PCPKsp.dll） |
| 句柄数 / 线程数 |
恒定 277~279 / 9（末期降至6） |
| 自身日志 |
0 字节，从未写入 |
| 存活时长 |
每次约 60~62 秒，与完成的工作量无关 |
| 客户端侧 |
全程 get_status 返回 broker unavailable (-2) |
关键观察：将 broker 进程优先级提升到 High 后，相同时间内多完成约 15% 的 CPU 工作量，但仍在完全相同的墙钟时间（~62秒）结束。加上模块/句柄/线程数在整个过程中毫无变化，这更像固定超时下的空转循环，而非"工作量太大没算完"。
另：单独手工启动 broker（相同参数、--parent-pid 指向自建进程）并等待 10 分钟——进程 CPU 全程 0%、不退出、日志仍为 0 字节。说明 CPU 消耗发生在有客户端接入之后。
已实测排除的可能
| 假设 |
验证方式 |
结论 |
| 程序版本 |
v2.3.0 / v2.2.1 / v2.1.5 全部实测 |
表现完全一致 |
| 管理员权限 |
提权启动 |
完全一致 |
| 杀毒软件（火绒） |
加信任区 + 完全关闭防护，两种状态 |
CPU曲线与默认状态几乎重合 |
| 非ASCII路径（#117） |
安装/数据/output/微信数据目录、用户名 |
全部纯ASCII |
| 代码签名 |
用随附 windows-private-pki.ps1 -Action Verify 验证 |
通过（signer/root SHA256 与 build.json 一致；0x800B0109 为设计预期） |
| TPM 缺失或过慢 |
TPM 2.0 存在；Platform Crypto Provider 建 RSA-2048 持久化密钥仅 0.54s |
健康 |
| 设备密钥损坏 |
LifeArchiveProject.WeChatDB.Native.Device.v1 已存在于 TPM；打开 0.39s，ECDSA 签名 0.13~0.65s，验签通过，公钥可导出 |
健康 |
| 联网授权 / CRL 吊销检查 |
全程零TCP连接、零DNS；二进制内除微软PKI时间戳外无外部域名 |
无网络行为 |
| 磁盘扫描 / 数据量 |
I/O 计数全程 0（数据目录约 10GB / 12万文件） |
无关 |
| CPU 性能不足 |
提升优先级后多干 15% 活，仍同一时刻结束 |
非算力问题 |
| 端口冲突 |
日志 port 10392 remains available |
无冲突 |
问题
broker unavailable (-2) 的确切含义是什么？是握手鉴权失败、能力协商失败，还是 broker 侧主动拒绝？- broker 在什么情况下会完全不写自己的日志（连启动行都没有）？能否提供强制开启 broker 侧日志的环境变量或命令行开关？ 这是目前最需要的东西——只要日志能出来，问题基本可以立刻定位。
- 实际启动命令中不含
--trust-key，而 broker 的 usage 将其列为必填。这在 --disable-database 模式下是预期行为吗？还是说客户端本应先生成 trust key、而该步骤在本机静默失败了？（数据目录中未发现任何 trust key 文件）
- 客户端
native_core_broker.py::_wait_until_ready 的超时是否可配置？
- broker 在拿到客户端连接后、持续占满一个CPU核心约60秒的这段处理，具体是在做什么？是否有已知的会导致该循环无法收敛的环境条件？
如需更多数据（完整日志、进程/模块/句柄快照、ETW采样等）我可以随时提供。
[Bug] backend 始终无法就绪：broker 恒定占用CPU约60秒、自身日志0字节、客户端持续
broker unavailable (-2)环境
wcdb-prod-20260829-weixin-actions-1，有效期至 2026-10-13（未过期）现象
backend-stdio.log：logs\native-core-broker.log始终 0 字节。broker 进程实测行为（多次重复，结果高度一致）
app 实际启动 broker 的命令行（进程监控捕获）：
get_status返回broker unavailable (-2)关键观察：将 broker 进程优先级提升到 High 后，相同时间内多完成约 15% 的 CPU 工作量，但仍在完全相同的墙钟时间（~62秒）结束。加上模块/句柄/线程数在整个过程中毫无变化，这更像固定超时下的空转循环，而非"工作量太大没算完"。
另：单独手工启动 broker（相同参数、
--parent-pid指向自建进程）并等待 10 分钟——进程 CPU 全程 0%、不退出、日志仍为 0 字节。说明 CPU 消耗发生在有客户端接入之后。已实测排除的可能
windows-private-pki.ps1 -Action Verify验证0x800B0109为设计预期）LifeArchiveProject.WeChatDB.Native.Device.v1已存在于 TPM；打开 0.39s，ECDSA 签名 0.13~0.65s，验签通过，公钥可导出port 10392 remains available问题
broker unavailable (-2)的确切含义是什么？是握手鉴权失败、能力协商失败，还是 broker 侧主动拒绝？--trust-key，而 broker 的 usage 将其列为必填。这在--disable-database模式下是预期行为吗？还是说客户端本应先生成 trust key、而该步骤在本机静默失败了？（数据目录中未发现任何 trust key 文件）native_core_broker.py::_wait_until_ready的超时是否可配置？如需更多数据（完整日志、进程/模块/句柄快照、ETW采样等）我可以随时提供。