Repository navigation
Windows: 非 ACP 工作目录下 mcpp --version 静默退出 0xC0000409（先修进程边界，再验证构建链） #693
Description
Activity
- added a commit that references this issue
on Sep 25, 2026 - added a commit that references this issue
on Sep 25, 2026 Fixed by openxlings/xlings#613, released as xlings 2026.9.26.2, and by #698, released as mcpp 2026.9.26.1 (commit
f61b46632), which bundles that xlings. This issue closed automatically when #698 merged; this note records what changed.The silent
0xC0000409came from the xlings shim in front ofmcpp.exe: it threw during start-up in a directory outside the ANSI code page and had no exception boundary.mcpp.exeitself printed its version (measured onwindows-latest, ACP 1252, through the temporary PR #697). Behind it was a larger defect the report did not reach: with the project or the mcpp home under a non-ASCII name, every build failed with an internal exception, including names the ANSI code page can represent.The fix is one text model, UTF-8 throughout:
xlings.exeandmcpp.exedeclareactiveCodePageUTF-8 in an embedded manifest, and xlings'smainhas an exception boundary.- Build programs carry the same manifest, and so do host tools built for the graph by default; a target chooses with
windows_code_page = "utf-8" | "legacy", and a manifest the package embeds itself takes precedence. - Response files for the MSVC tools begin with a UTF-8 byte-order mark, because
cl.exe,link.exeandlib.exeread a response file without one as ANSI (measured). - A path with no UTF-8 spelling is refused by name where it is the project or the mcpp home, and skipped and reported where it is a file inside a project. On a Windows host that ignores the manifest, the diagnostic names the process code page.
Criteria: Windows CI builds every toolchain row in non-ASCII project directories (
.github/tools/check_unicode_paths.sh), andtests/e2e/776_a_path_with_no_utf8_spelling_is_named.shfails on 2026.9.25.1 and passes on 2026.9.26.1. The releasedmcpp.exeand its bundledxlings.exeboth carry the manifest, read from the release archive.Update with
xlings update mcpp -y.Record:
.agents/docs/2026-09-25-issues-693-696-triage-and-repair-plan.md§6.
实测现象
在 Windows（本机
GetACP() == 936）上，mcpp 2026.9.25.1 从含有当前 ANSI 代码页无法表示的字符的工作目录启动时，连--version都会无输出地退出：同一目录下
mcpp build --configure-only也是无输出、同一退出码。目录里放了最小的mcpp.toml和src/main.cpp，但--version已能复现，因此故障发生在读取源码之前。ASCII 工作目录下同一mcpp.exe正常。这个签名比 #518 A 中的“没有源文件”更早，也不能靠改进 glob 的诊断覆盖。同机的 mcpp 自带 Ninja 1.12.1 在该目录能正常运行，
ninja.exe -t wincodepage输出Build file encoding: UTF-8。Ninja 上游也随 Windows 版本提供 UTF-8 activeCodePage manifest。这说明当前复现至少不是 Ninja 首先拒绝工作目录；其他编译器和构建工具仍需逐一验证。与已有问题的关系
activeCodePage=UTF-8的方向，并明确指出仅给 mcpp 加 manifest 不等于端到端支持 Unicode 路径。这个新复现聚焦进程启动/命令分派阶段的静默终止，并希望把修复和后续验证的边界写清楚。
建议方案
build.mcpp.exe。 在 Windows PE 产物里嵌入activeCodePage=UTF-8manifest（Windows 10 1903+ 支持），让 MSVC STL 的窄路径转换与构建图中的 UTF-8 字符串一致。mcpp.exe可走现有[resources]构建能力；build.mcpp.exe是单独的 host 编译/链接路径，需要单独接入。同一阶段修掉--version的静默退出，失败时至少给出准确诊断。Microsoft 的应用程序 manifest 文档说明了这个设置及系统版本要求。build.ninja/CDB 的路径字节约定为 UTF-8；进入 Win32 文件、命令行和环境 API 时使用 UTF-16/W API，或明确做 UTF-8↔UTF-16 转换。目前 Windows bounded process 路径仍使用CreateProcessA、GetEnvironmentStringsA；只依赖进程 ACP 会让这个约定隐含在 manifest 和 OS 版本里。这个重构可以分阶段做，不必阻塞第 1 步的止血。-t wincodepage），再分别测试编译器驱动、链接器、资源编译器和项目声明的 host tool/action。第三方可执行文件的代码页不会因为 mcpp 的 manifest 自动改变；如果某一环不能消费 Unicode 路径，应点名该环和失败的路径，而不是宣称整个构建已受支持，也不宜静默修改第三方 exe。建议验收
GetACP() != 65001，否则该回归用例不构成证据；在含🧪的工作目录运行mcpp --version和mcpp build --configure-only，均应正常退出并有预期输出。build.mcpp项目，再测试含非 ACP 字符的成员目录和源文件名；验证 Ninja 构建文件、CDB 与子进程收到的路径没有乱码。至少对一条固定的 Windows 工具链实测端到端成功；其他工具链若有边界，应给出分阶段诊断。