Windows 沙箱里 scipy.linalg / np.linalg 一调用就崩（0xc06d007f），但系统 shell 里正常——有人遇到过或知道怎么豁免吗？

[sailorhero]

我在 DSH v0.1.5-rc2（Windows 版，Web GUI）里用 pwsh 工具跑 Python 时，碰到一个问题，发出来看看有没有人踩过同样的坑、或知道怎么绕开。

现象

在 DSH 内执行：

D:\miniforge3\envs\py313\python.exe -c "import faulthandler; faulthandler.enable(); import numpy as np; from scipy.linalg import lu; print(lu(np.array([[1.,2.],[3.,4.]])))"

直接崩：

Windows fatal exception: code 0xc06d007f
  File "...\scipy\linalg\_decomp_lu.py", line 350 in lu

但完全一样的解释器、完全一样的命令，在 DSH 之外的系统 cmd / PowerShell 里跑，正常返回 (P, L, U)。

哪些会崩（都走 OpenBLAS 的 LAPACK 初始化）

• np.linalg.det / inv / solve / svd / qr
• scipy.linalg.lu / qr

哪些在 DSH 里反而正常（不触发 OpenBLAS LAPACK 初始化）

• np.array、np.fft、np.dot、np.matmul（小矩阵走轻量 BLAS 路径）
• np.linalg.eig、scipy.linalg.solve（走参考实现 lapack_lite）
• scipy.special、scipy.sparse

我试过但都没用的

• 设 OPENBLAS_NUM_THREADS=1 / OPENBLAS_MAIN_FREE=1 / OMP_NUM_THREADS=1
• 给 pwsh 加 danger-full-access 提权（排除文件权限沙箱）
• 用 .bat 让 cmd.exe 拉起 python 孙进程（限制随进程树继承，照样崩）

环境

Windows x86_64，CPython 3.13.15（conda-forge），numpy 2.5.3 / scipy 1.18.1，OpenBLAS 后端。

想请教大家

1. DSH 的 Windows 沙箱有没有办法对某条命令/进程豁免这个限制（类似 allowlist，或类似 --no-sandbox 的开关）？
2. 还是说这就是预期行为、只是官方兼容文档里没写，建议我在项目里继续用纯 Python 兜底？

如果官方想知道更精确的根因（OpenBLAS 到底踩了哪条 Windows API），告诉我抓什么诊断信息，我可以提供。

谢谢！

[PerryLink]

先说清哪些是查证过的、哪些只能算判断。

这不是文件权限问题，也不是「命令允许列表」能解决的问题。

Windows 沙箱（sandbox-windows-acl）把调用者的令牌复制成一个 WRITE_RESTRICTED 受限令牌，Windows 做两遍访问检查（普通 SID 一遍、restricting SID 一遍），只有两遍都过才授予写访问。这个令牌是进程属性，在进程创建时建立，不能被任何应用层开关「放行某一条命令」。它的边界在包文档里写得很明确：Writes are restricted; reads, network, and process visibility are not（packages/sandbox/sandbox-windows-acl/README.md:116）。所以纯粹的「读/计算」路径理论上不该被它影响。

但同一份文档也记录了一类确定存在的失败模式：受限令牌会让原生 DLL 初始化挂掉。文档原文有两处：

• packages/sandbox/sandbox-windows-acl/README.md:94 ——「保活组（登录 SID + Everyone）在两种模式下都必须存在：没有它，早期 DLL 初始化会以 0xC0000142 死亡，CNG 会让 pwsh 以 0xE0434352 崩溃」；
• packages/sandbox/sandbox-windows-acl/README.md:117 ——「控制台隔离不可用 —— 以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡」。

也就是说「受限令牌 → 某个 DLL 在初始化阶段失败」这条路子是官方文档承认的既有类别。

但要诚实说明两点：

1. 你看到的 0xc06d007f 是 delay-load 失败异常：facility 0x6D = FACILITY_VISUALCPP，低 16 位 0x007F = ERROR_PROC_NOT_FOUND（出错文案就是「找不到指定的程序」），也就是延迟加载的函数/导入解析（GetProcAddress/导入过程查不到）失败时 delay-load 辅助代码抛的那个异常；姊妹码 0xc06d007e 对应 ERROR_MOD_NOT_FOUND。它和上面记录的 0xC0000142 / 0xE0434352 不是同一个码 —— 顺带说一句，ERROR_DLL_INIT_FAILED 那个名字对应的是 1114（0x45A），跟 0x7f 没有关系，别被这个码的常见误标带偏。我在这台机器上装不了 scipy/numpy，也没有 conda-forge 3.13 环境，复现不了你这一例。所以「就是受限令牌导致的」这句话我不下结论，只能说：机制类别吻合（延迟加载失败也是「某个 DLL 在这一步没起来」），具体实例待你这边一条实验定性。
2. 你的 faulthandler 输出 Windows fatal exception: code 0xc06d007f 只给了一帧。仅凭这一帧我无法判断是 faulthandler 没拿到更深的栈、还是输出被截断了 —— faulthandler 对 Windows 致命异常是会打印当前线程的 Python 栈的，所以如果后续帧存在，把它们一起贴出来会更有用。

先做一件事：确认 danger-full-access 真的生效了。

这一点很关键。dsh-pwsh-sandbox 对 danger-full-access 的处理是先于沙箱提供方直接走原始 argv：源码 packages/shell/pwsh-sandbox/src/index.ts:99-102 判断 mode === 'danger-full-access' 就 super.run(spec) 并返回 sandbox: { mode, denied: false }，README :40 也写着「No confinement; the provider is never consulted」。不生效就不会有任何受限令牌。

所以逻辑上只有两种可能：

• 那次调用其实没升上去（比如审批没批、或只对别的调用生效了）→ 那么受限令牌还在，结论还没排除；
• 确实生效了却照样崩 → 那么受限令牌不是原因，问题在别处（我倾向查原生扩展自己的 DLL 加载链，见下）。

请先确认调用结果里的 sandbox 字段是不是 { mode: 'danger-full-access', denied: false }。

关于你试的「用 .bat 让 cmd.exe 拉起 python 孙进程」为什么一定无效。

受限令牌不是 dsh 给主进程打的标，而是每次受限调用由 runner 现场创建并赋予那个子进程的（packages/sandbox/sandbox-local/src/index.ts:317-336 的 confine() 返回 runner + -- 原始 argv）。所以限制不是从 dsh 主进程往下继承的，而是「这一次调用的进程树根节点」自带。加一层 .bat 只是在自己底下多一层子孙，令牌一层不少。

想请你提供的诊断信息（按性价比排序）

1. 上一条：danger-full-access 那次调用的 sandbox 字段实际值，以及是否仍然崩。

2. 区分「延迟加载失败」还是「普通加载失败」：对你的 _multiarray_umath.pyd 和 scipy 的 _fblas / _flapack 跑一次 dumpbin /imports，看导入表里有没有 Delay Import 段、指向哪个 DLL。0xc06d007f 只可能来自延迟加载路径，能直接指认是哪一个依赖。

3. 最强的一条：把「进程内计算」换成「子进程 helper」，同一份解释器、同一个环境：

   python -c "import subprocess,sys; r=subprocess.run([sys.executable,'-c','import numpy as np;print(np.linalg.det(np.array([[1.,2.],[3.,4.]])))'],capture_output=True,text=True); print(r.returncode); print(r.stdout); print(r.stderr[-2000:])"

   这条命令依赖管道抓取内层输出（capture_output=True 让内层 python 的 stdio 是管子而不是继承来的控制台）——受限会话下「通过管道 stdio 捕获另一程序输出」会直接 EPERM，所以要么先用 danger-full-access 跑这条，要么改成让内层把输出写文件再读。这条能一次性分开「进程内 DLL 初始化失败」与「解释器/加载器本身的问题」。

4. 环境对照：这条命令在你配置 danger-full-access 之外的第二个会话里，用系统 cmd 跑（你已经跑过，正常），再把区别缩到最小 —— 用同一个 python.exe、同一份 numpy/scipy，只换「由谁启动」。

绕过路径（按代价从低到高）

1. 先确认这是不是 py313 + conda-forge 的组合特有的：conda 环境会在 DLL search path 里塞 Library\bin，是延迟加载类故障的高发区。用另一个解释器（比如 uv/官方 CPython 装的 numpy+scipy，不经过 conda-forge）跑同一条 lu()，如果好了，根因就在那条搜索路径/那批 DLL，而不是沙箱。
2. 换 BLAS 后端：你的崩溃点全部集中在「会初始化 OpenBLAS LAPACK」的调用上，而 np.linalg.eig / scipy.linalg.solve（走参考实现 lapack_lite）正常 —— 这个边界很干净。换 numpy 的 MKL/其他后端构建（或 pip 版 wheel）再试一次，能验证「是 OpenBLAS 那条 DLL 链」这个判断。
3. 对这一次调用用 danger-full-access：这是官方唯一的内置「关掉沙箱」开关，没有更细粒度的 allowlist。代价说明：它意味着该次调用完全不受限，与你在自己终端里敲命令等价 —— 可以写工作区外的任何路径、跑任何命令。它是逐调用的（每次更宽模式都要一次审批），不是给某条命令开一个长期白名单。
4. 整个会话切到 danger-full-access：如果你要跑一长串数值实验，逐调用审批不现实，就切会话默认模式。同样请理解代价：整个会话失去文件写入约束。

关于你问的第 2 点：如果你确认 danger-full-access 下仍然崩，那就是「预期行为之外」的现象，值得作为独立问题反馈——因为那说明它和文件沙箱无关。如果只有受限模式下崩，那它属于上面文档已承认的「受限令牌下 DLL 初始化」这一边界类别，官方兼容文档里确实没有针对第三方原生扩展的专门条目，这条反馈本身有价值。

如果这条思路帮你把范围缩下来，可以把它标为 answer，方便后面遇到同类 0xc06d007f 的人找到。