Posts

Dot 能聊天，也显示电脑已连接，却反复提示： The desktop could not prepare a task workspace 2026 年 10 月 22 日，在一台 Windows 10 LTSC 2021 电脑上排查这件事，先后遇到了网络超时、会话访问拒绝，以及 PowerShell 启动崩溃。最后一条线索最扎实：脱离 Dot，单独启动 Codex 附带的 pwsh.exe ，同样报出 Windows 未完整支持 CET 的致命错误。给 PowerShell 设置兼容例外后，用户反馈命令有效。 这篇记录保留当时的证据和修复边界：已经复现并绕过的是 PowerShell 启动故障；会话结束时，还没有一份完整的 Dot 任务创建、执行及文件落盘验收记录。 先分清“已连接”到底证明了什么 最初的日志很容易把人带偏。聊天消息返回 HTTP 200，本机执行器每分钟报告在线，但 hostId=durable 的 WebSocket 持续 open_timeout 。这三件事可以同时发生。 检查对象 当时观察到的结果 可以得出的结论 Dot 聊天消息 HTTP 200，收到回复 消息收发正常 本机执行器 持续报告已连接 执行器的连接在采样期间在线 durable 连接 15 秒后超时 这条云端连接没有建立成功 新任务 提示工作区准备失败 尚未进入可确认的正常执行状态 此前还出现过插件文件被占用的 EBUSY 和凭据过期的 401 ，但它们已经自动恢复。后来的失败窗口没有重现这两个错误，不能一直拿旧错误解释新问题。 ...

这次工作最初是一份接口问题清单：找到对应的 iFlow，用已有请求触发，结合 Trace 和 S/4 程序逻辑，判断字段为什么没有返回、应该由哪一侧调整。 随着 Bruno 请求集合和历史接口材料补齐，FAQ 接口的工作逐渐明确：先对齐已有可用接口的调用方式，再把登录逻辑从业务 iFlow 中抽出，交给公共 iFlow 管理。这里记录这条已经完成验证的改造链路，以及过程中几个容易误判的地方。 文中的流程名称使用 FAQ_FLOW 和 TOKEN_FLOW 代称。租户地址、凭据别名、业务设备号和原始 Trace 均不公开。代码片段用于说明实现原则，不是可以直接导入任意租户的完整部署包。 从“字段没返回”开始，先建立证据边界 会话前半段涉及多个接口：设备档案、特征值和 FAQ。排查材料既有接口清单，也有数据库查询结果、表截图和业务顾问对记录出现时间的反馈。 这些材料回答的问题并不相同。 材料 可以确认的事情 不能单独推出的结论 Bruno 请求 请求路径、方法、参数、认证方式 当前部署的 iFlow 一定按相同方式调用 CPI Trace 某一次运行中具体步骤的报文 所有调用都经过同一分支 S/4 表记录 查询时该环境中存在这些数据 这些记录一定由某次接口调用创建 ABAP 源码 被阅读版本的取数及处理逻辑 另一 client 的数据和运行结果必然相同 最终 HTTP 响应 调用方实际收到的内容 中间每个步骤都正确 例如，返回中没有 characteristics ，需要继续区分：后端没查到数据、程序没有填充字段、映射没有传递，还是序列化改变了空值的表达方式。 又例如，顾问说“下午之后才出现第一条记录”，这能帮助缩小时间窗口，但不能直接证明记录由我的测试创建。还需要把请求内容、运行时间、消息关联标识和后端写入路径对起来。 因此，这篇文章不把前面所有问题归结为“S/4 的问题”或“CPI 的问题”。后面 FAQ 的修复有独立的请求、部署和运行证据，其结论只覆盖这条链路。 Bruno 提供了认证协议，不能从旧 iFlow 的名字猜 补充材料中的请求集合给出了当前可用的 FAQ 调用方式：先发 JSON 登录请求，取出响应里的 token ，再把它放进业务请求的 Bearer header。 ...

什么时候需要 Autoruns Windows 登录后，一些程序会自己打开；有些软件没有窗口，却在后台运行更新器、同步服务或托盘组件。任务管理器里的“启动应用”适合日常开关，但排查范围更广时，可以使用微软 Sysinternals 的 Autoruns。 它把多种自动加载入口集中展示出来：登录启动、资源管理器扩展、计划任务、服务、驱动等。它更像一张“从哪里启动”的地图，而不是当前进程列表，也不是衡量开机耗时的性能分析器。 本文采用一个保守而实用的顺序：先观察并保存记录，再核对条目，一次只改变一个明确的目标，最后验证。 不追求把列表清空。 文中两张截图来自公开的旧版界面，均在图下注明来源，用于辨认标签页和字段；不是本文作者机器的检查结果。新版的图标、菜单位置及条目内容可能不同。 下载和首次打开 从 微软官方 Autoruns 页面 下载压缩包，解压到固定目录。常见的 x64 Windows 使用 Autoruns64.exe ；命令行程序 Autorunsc64.exe 与图形界面不是同一个入口。选择与你系统架构匹配的程序。 先打开图形界面，等待枚举完成。需要查看或修改机器级条目、遇到权限不足时，再以管理员身份运行。第一次使用时阅读软件许可提示。 不要在扫描尚未完成时根据暂时空白的列表下结论；也不要为了拍截图或整理列表而随手取消勾选。 先读懂界面：位置、名称、发布者、路径 Figure 1: Autoruns 旧版界面：上方按入口分类，中间是条目列表，下方显示所选项的详情。截图来源：Core Technologies，原始链接见下文。 图片出处：Core Technologies：Which Programs Start Automatically?。截图中的勾选状态只是演示环境的状态，不是推荐照搬的配置。 阅读一个条目时，建议按下面的顺序核对： 字段或区域 应该确认什么 分组位置 这个条目来自哪一处注册表、启动目录或其他入口？ Autorun Entry 名称能否对应到你安装的软件？不要只凭名称判断。 Description 描述是否与软件用途一致？描述本身不是可信证明。 Publisher 发布者是谁？若启用签名验证，验证结果是什么？ Image Path 实际加载哪个文件，目录是否符合预期？ 底部详情 完整路径、命令参数和文件信息有什么补充？ 例如，一个名称叫“Update”的条目几乎没有判断价值。把它的路径、发布者和完整命令放在一起，才可能确认它属于显卡工具、办公软件，还是其他程序。 还要注意：条目存在，不等于它此刻正在运行；可执行文件名相同，也不等于启动参数相同。 按问题选标签，不必从 Everything 一路翻到底 现象 优先查看 登录后自动弹出软件或出现托盘图标 Logon 过一段时间又自动启动，或周期性出现任务 Scheduled Tasks 无窗口的后台功能、同步或更新组件 Services 右键菜单、资源管理器相关扩展异常 Explorer 明确与硬件驱动有关的问题 Drivers，谨慎处理 这是一条排查路线，不是严格的一对一对应关系。同一个软件可以同时安装登录项、任务和服务。关闭其中一个入口后，其他入口仍可能启动它。 ...

这个博客以 Org 文件为原稿，以 Git 保存文章和图片，以 Hugo 生成静态网页。 内容如何流动 Org -> Markdown -> HTML -> Caddy Org 和 Markdown 都保存在仓库中，HTML 可以随时重建。VPS 只提供静态文件， 不承载写作数据库。 接下来 日常排错、读书、交易复盘和工具配置都可以先成为一则草稿，再逐步整理成文章。