Aspen Plus V14：STRGXI2.dll 崩溃的后续排查

上一篇记录处理了 Aspen Plus V14 并发自动化中的归档冲突和退出异常。短路径、独立 worker、启动锁和归档锁投入使用后，4-worker 验证可以稳定完成。

事情没有在这里结束。后续排查中，即使不运行优化器，只启动一个空白 Aspen GUI，apmain.exe 和 AspenSplash.exe 仍会在 STRGXI2.dll 中崩溃。原先的结论因此需要增加一层：并发保护规避了自动化任务中的触发条件，但没有修复本机共享组件的基础故障。

与上一篇的分工

本文不再展开 STA worker、两把互斥锁、归档事务和 PID 清理的实现，只记录后来出现的新证据、对故障链路的修正，以及安装层的后续处置。

新证据来自空白 GUI

并发任务稳定后，普通 GUI 启动仍留下了重复的 Application Error：

进程	故障模块	异常代码	现象
apmain.exe	STRGXI2.dll	0xc0000409	相同模块版本和偏移重复出现
AspenSplash.exe	STRGXI2.dll	0xc0000409	32 位 Splash 在同一共享组件中退出，偏移与 64 位宿主不同
空白 Aspen GUI	同上	同上	不加载优化任务也能复现；主界面有时仍会在 Splash 退出后出现

这组事件排除了“必须运行并发优化才会发生”的前提。特定 BKP、工艺参数和贝叶斯优化器都不是复现该故障的必要条件。

它仍然不能回答 DLL 内部哪条语句出错。相同宿主、相同模块版本和固定偏移说明故障具有重复性，但不能进一步区分文件损坏、组件版本不一致或系统兼容性问题。

后续又出现了两类 COM 错误

上一篇已经记录过 0xc0000409 与 0x800706BE 的先后关系，这里不再重复。后续批次又出现了两个需要单独归档的错误：

错误码	标准含义	出现阶段
0x80010105	COM 服务端抛出异常	load_seed_archive；同批有 apmain.exe → STRGXI2.dll 的 Event 1000
0x80080005	COM server execution failed	create_com_document；Aspen 本地 COM 服务器没有正常启动

两者都发生在模型节点修改之前，不能记成流程不收敛。0x80080005 也不能单独证明许可证故障；它只描述 COM 激活失败时调用方看到的状态。

这些定义可分别在 Microsoft 的 RPC 类 COM 错误码和 OLE 类 COM 错误码中查到。现场判断仍以错误阶段和同一时间的 Event 1000 为准。

STRGXI2.dll 的身份需要纠正

早期记录曾把 STRGXI2.dll 简称为“归档层”。这个表述不准确。

AspenTech 的知识库将它定义为 Software License Manager（SLM）客户端的核心动态链接库。AspenTech：How do I check the version of the SLM client (STRGXI2.dll)?

归档操作期间在该 DLL 中崩溃，只能说明故障发生时的宿主正在执行归档相关流程，不能把这个 DLL 的官方职责改写成归档处理。许可证服务处于 Running 状态也只能说明服务没有停止，不能证明客户端 DLL、Common Components 和 Aspen Plus 的版本组合没有问题。

并发措施解决了哪一层

上一篇的方案建立了当前项目的并发运行合同，具体锁范围、worker 所有权和验证结果不在本文重复。

空白 GUI 的新证据只改变了对这套方案的解释：它规避了自动化任务中的并发触发窗口，不代表 STRGXI2.dll 已经修复。非并发场景继续崩溃时，应转向组件更新、安装修复和厂商分析，而不是继续扩大锁的范围。

OneDrive 不是这次等待的直接证据

故障文件位于较深的中文 OneDrive 路径，因此曾怀疑 BKP 下载或磁盘读取导致长时间等待。

对原文件和本地副本进行原始读取时，首次读取约为 10—13 ms；同一 BKP 通过 GUI 可以完整加载，流程加载约为 6—7 s。现有数据不支持“OneDrive 下载卡住”这个解释。

短 ASCII 运行目录仍然保留。它能减少路径长度、编码、sidecar 文件和临时目录共享等变量，但在当前试验中属于组合防护措施，不能单独作为崩溃根因。

当 DontShowUI=1 时，native 崩溃及 WER 处理没有可见窗口，用户看到的往往只是 Aspen 长时间等待。这个设置改变的是错误界面，不是崩溃行为。

再次出现时的判断顺序

第一步先看 worker 最后停在哪个阶段，第二步查询同一时间的 Event 1000，最后才检查 Aspen History 中的流程收敛信息。

$start = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    Id        = 1000
    StartTime = $start
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Message -match 'STRGXI2\.dll|simdll\.dll|ucrtbase\.dll'
} |
Select-Object TimeCreated, ProviderName, Message

同一时间如果已有 apmain.exe、AspenPlus.exe 或调用方进程的 native 崩溃，就把该点记为基础设施故障，不计算 TAC，也不调整塔板数、物性或收敛参数。

处理顺序保持简单：

1. 停止调度器继续派点，保存评价 JSON、Event 1000 和 dump；
2. 只清理 ownership 文件记录的 Aspen 进程，不按名称结束全部 Aspen；
3. 全新 worker 仍在 COM 创建阶段报 0x80080005 时，停止重试并重启 Windows；
4. 重启后先跑一个已知可行点，再逐步恢复 2 和 4 worker；
5. 只有 RPC 错误、Event 1000 和残留 PID 都为 0，且数值一致时，才恢复长时间任务。

如果没有 native 崩溃，而 Aspen History 明确显示 RadFrac、Recycle 或物料衡算未通过，才把它归入候选工艺状态。

安装层的后续处置

空白 GUI 能复现以后，继续修改优化代码已经不能覆盖全部故障面。后续应检查 Aspen Plus V14、Common Components 与 SLM 客户端的补丁和安装一致性。

AspenTech 建议使用 Update Agent 保持产品补丁最新。AspenTech Support Welcome Center 如果更新后仍复现，应使用同版本官方介质修复安装，或向 AspenTech 提交 Aspen build、STRGXI2.dll 版本、故障偏移、事件记录、dump 和最小复现。不能从其他机器单独复制 DLL 覆盖，也不应只替换 x86 或 x64 中的一份。

Windows Error Reporting 可以按进程保存 user-mode dump。LocalDumps 中的 DumpType=2 表示完整 dump；DontShowUI=1 只隐藏 WER 界面。Microsoft：WER Settings 完整 dump 可能包含流程数据、路径和进程内其他敏感内容，对外提交前需要确认接收渠道。

记录结论

并发保护使自动化任务恢复可用，但后续的空白 GUI 复现证明问题没有停留在调度器内。0x800706BE 等 HRESULT 是调用方看到的后续状态，Event 1000 中的 STRGXI2.dll / 0xc0000409 才是这批故障需要优先保留的证据。

当前做法是继续使用已经验证过的 4-worker 运行合同，同时把非并发复现作为独立的安装问题处理。两条线分开后，优化器不再为软件崩溃背锅，代码规避也不会被误写成 DLL 已经修复。