用 Windows Sandbox 加快应用验证的方法

在 Windows 应用开发中，验证变慢的原因大都很相似。

• 手头的开发机环境已经”脏”了，首次安装时才会出现的问题无法复现
• 在客户环境中会发生，但在自己的 PC 上却不会发生
• “以管理员身份运行就能用”，但看不清真正需要的权限边界
• 想测试权限或依赖不足时的行为，又不想破坏平时使用的环境
• 在低内存或缺少 GPU 的状态下会崩溃，但又不至于每次都要搭建完整虚拟机

这种时候，Windows Sandbox 相当好用。

因为它不像完整虚拟机那样笨重，启动速度快，关闭后每次都会彻底清除，非常适合 “想在几分钟内，用相同的 Windows 版本重新搭建出一个干净的验证环境” 这种需求。

不过，如果每次都不假思索地打开一个全新的 Sandbox，效率提升其实有限。 在实务中真正有效的做法是：针对每个验证场景固定一份 .wsb 配置，将只读的输入文件夹与只写的回收文件夹分开，并区分使用管理员场景、标准用户场景和受限场景。

本文将聚焦 Windows 应用开发的视角，整理这种做法。内容以 2026 年 4 月时点可确认的 Microsoft 官方信息为前提。

先说结论

先把结论列出来。

• Windows Sandbox 适合复现干净环境、确认首次安装、排查管理员权限问题，以及找出依赖缺失。
• 相比每次都用 GUI 手动操作，按用途分别准备 .wsb 更快。
• 主机共享方面，输入设为 read-only，输出才设为 read-write，可以减少误操作事故。
• 默认的 Sandbox 会话本身不太适合直接用于标准用户验证。如果想做标准用户验证，需要在 Sandbox 内创建另一个用户，并以该用户身份启动。
• 要复现内存不足或缺少 GPU 的情况，.wsb 的 MemoryInMB 与禁用 VGpu / vGPU 会很有效。
• 但是，如果还想复现 CPU 配额、磁盘紧张、多实例同时启动、不同 OS 版本，那么完整虚拟机会比 Windows Sandbox 更合适。

总而言之，Windows Sandbox 是一种 “轻量但用后即弃”“速度快但局限于同一 OS 系列”“功能有限但足以在实务中发挥作用” 的验证环境。 先理解清楚这个定位，就不会用错场合。

Windows Sandbox 为何与开发验证相性良好

Windows Sandbox 之所以与 Windows 应用开发相性良好，有 4 个原因。

关闭后每次都能重置

这是最大的优点。

反复尝试安装程序、破坏设置、修改注册表、安装或卸载前置组件——这类操作如果在开发机本体上进行，环境会渐渐变成”说不清楚里面装了什么”的状态。

而使用 Sandbox 的话，关闭后一切都会清除。 因此，更容易发现 只在首次安装时才会出现的问题，以及 因为手头环境恰好装有某些前置组件而被掩盖的问题。

可以立即创建同一 Windows 系列的干净环境

Windows Sandbox 的前提是使用与主机相同系列的 Windows 版本。 这既是一种限制，反过来说，也意味着 可以立即创建出与手头 Windows 11 同系列的干净环境。

如果是”客户用的是 Windows 11 24H2，我们这边也是 Windows 11 24H2”这种情况，就相当好处理。

比完整虚拟机更轻量，管理成本更低

Hyper-V 或 VMware 的完整虚拟机固然强大，但如果每次的用途只是

• 确认安装步骤
• 确认 UAC 的弹出情况
• 确认权限不足时的错误
• 确认依赖缺失时的日志
• 在干净环境中做冒烟测试

这类工作的话，往往会显得有些笨重。

Windows Sandbox 不需要引入太多 OS 镜像管理或快照运维，因此优势在于 能轻松推进”想稍微复现一下”这类验证。

可以用 .wsb 与 CLI 固定验证场景

Sandbox 真正的价值，与其说是”可以安全地尝试”，不如说是 可以在相同条件下反复重来。

• 是否启用网络
• 共享文件夹 read-only / read-write
• 低内存
• 不共享 GPU
• 不共享剪贴板
• 启动时执行特定脚本

把这些内容通过 .wsb，或 Windows 11 24H2 以后的 CLI 固定下来，验证就会从”临时想到就做的操作”变成”可重复执行的步骤”。

首先要了解的限制

Windows Sandbox 很方便，但也有不适用的场景。这些内容最好先了解清楚。

可用的版本有限制

Windows Sandbox 可以在 Windows Pro / Enterprise / Education 系列版本中使用，Home 版无法使用。

公司内部的开发机可能是 Pro 版，但销售端的设备或个人电脑往往是 Home 版，这一点很容易踩坑。

有虚拟化方面的前提要求

使用 Windows Sandbox 需要启用虚拟化功能，并具备一定以上的内存、磁盘和 CPU 核心数。虽然它比较轻量，但也并非完全没有成本。

Sandbox 与主机是同一 OS 系列

这一点在实务上相当重要。

Windows Sandbox 不适合用来验证不同的 OS 版本。

• 如果主机是 Windows 11，就无法用它来复现 Windows 10 环境
• 如果客户使用的是较旧的版本，这部分差异无法弥补

因此，不同 OS 版本的兼容性验证 以及 依赖旧版本的问题，最好从一开始就选择完整虚拟机。

无法同时启动多个实例

目前，Windows Sandbox 不适合用于同时运行多个实例的场景。

如果想并行运行测试矩阵，使用 Hyper-V 之类的方案会更自然。

默认启用网络和剪贴板

这一点很容易被忽略。

Windows Sandbox 默认启用网络连接，剪贴板共享默认也是启用的。

也就是说，如果不假思索地启动它，它并不是一个”完全封闭的世界”。在确认来源不明的文件或复现依赖缺失的情况时，最好一开始就通过 .wsb 明确加以控制，这样更安全。

Windows 11 24H2 及之后版本部分内置应用无法使用

在 Windows 11 24H2 之后的 Sandbox 中，记事本、终端、计算器、照片等部分内置 Store 应用无法使用。

因此，启动时的自动化或辅助操作，稳妥的做法是 以 cmd.exe、powershell.exe、explorer.exe 为前提来搭建。

提前准备好会更快的目录结构

与每次现场决定共享文件夹相比，一开始就固定准备一个验证用的存放位置会轻松很多。

例如可以采用这样的结构。

C:\SandboxFixtures\
├─ AppUnderTest\
│  ├─ MyAppInstaller.msi
│  ├─ MyApp.exe
│  └─ sample-data\
├─ Scripts\
│  └─ Prep-StandardUser.ps1
├─ Outbox\
├─ 00-clean-smoke.wsb
├─ 10-standard-user.wsb
├─ 20-restricted-runtime.wsb
└─ 30-low-resource.wsb

各部分的作用划分如下。

• AppUnderTest：验证对象，read-only 共享
• Scripts：启动脚本，read-only 共享
• Outbox：日志、dump、导出结果，read-write 共享

采用这种划分方式后，Sandbox 能写入主机的位置就只限于 Outbox，相当安全。

此外，.wsb 也按场景分别固定下来。

只靠这一点，验证的启动成本就会大幅降低。

让干净环境下的冒烟测试只需双击一次

最先要准备的是 用于干净环境冒烟测试的 Sandbox。

示例：00-clean-smoke.wsb

<Configuration>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

这个用途下要把握的是以下 4 点。

• 将发布物放在 AppUnderTest 中
• 该文件夹以 read-only 方式提供
• 只把日志和结果输出到 Outbox
• 如果不想看到网络依赖的问题，一开始就直接关闭网络

这样一来，只需替换发布物、双击 .wsb，每次都能进行一次干净的首次验证。

这样容易发现的问题

在这个阶段，经常会发现以下问题。

• 开发机上装有的前置 DLL / 运行时，在生产环境中并不存在
• 对 WebView2 或 VC++ 可再发行组件包的依赖成了隐性前提
• 只在首次启动时创建的目录或配置文件，创建位置不合理
• 试图向 Program Files 目录写入运行时数据而崩溃
• 前提条件依赖于”只在开发者手头存在”的证书、字体、设置

重点是：Sandbox 中发生的一切都必须输出到 Outbox。因为一旦关闭就会全部消失，日志和 dump 都不能就这样留在 Sandbox 内。

联网版本也单独准备一份文件

如果验证对象是 Web installer 或带有在线认证的应用，一直关闭网络的话，只会看到另外一类问题。

这种情况下，可以用相同结构再创建一份 01-clean-online.wsb 之类的文件，不要把”离线前提的复现”和”在线前提的复现”混在一起，这样更容易梳理。

排查管理员权限问题的步骤

在 Windows 应用开发中，管理员权限的话题经常会混在一起。

• 是只在安装时需要
• 还是运行时也一直需要
• 还是只有部分设置变更需要
• 又或者其实只是保存位置不对

这个话题本身，我在之前写的以下文章中已经整理过。

• Windows 的管理员特权何时才是必需的 - UAC、受保护区域与设计上的判断方法
• 在 Windows 应用中把”只有需要管理员权限的处理”分离出来的具体写法

本文这里聚焦于 如何借助 Sandbox 加快验证速度。

首先应关注的角度

在 Sandbox 中首先想确认的是以下这些边界。

• 安装程序是否写入了 Program Files 或 HKLM
• 是否有服务注册、驱动安装、防火墙设置变更
• 更新程序是否试图进行 machine-wide 替换
• 运行时的设置、日志、缓存是否试图写入受保护区域
• 是否存在 Shell Extension 或 COM 注册之类的 OS 集成

换句话说，目的是要 区分”真正需要管理员权限的处理”和”只是运行时存放位置不当的处理”。

仅靠 Sandbox 的默认状态，无法完成标准用户验证

这一点很重要。

Windows Sandbox 的登录命令，是以容器内的用户账户运行的。Microsoft Learn 的说明中也提到，该容器用户账户应当是管理员账户。

也就是说，默认的 Sandbox 会话本身并不便于直接用来”以标准用户身份复现”。

如果想切实排查管理员权限问题，比较清晰的做法是在 Sandbox 内创建另一个标准用户，并以该用户身份启动应用。

示例：10-standard-user.wsb

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Scripts</HostFolder>
      <SandboxFolder>C:\Work\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>powershell.exe -NoExit -ExecutionPolicy Bypass -File C:\Work\Scripts\Prep-StandardUser.ps1</Command>
  </LogonCommand>
</Configuration>

示例：Prep-StandardUser.ps1

$UserName = 'wsbuser'
$Password = 'P@ssw0rd-For-Test-Only!'

$existing = Get-LocalUser -Name $UserName -ErrorAction SilentlyContinue
if (-not $existing) {
    $secure = ConvertTo-SecureString $Password -AsPlainText -Force
    New-LocalUser -Name $UserName -Password $secure -AccountNeverExpires | Out-Null
}

try {
    Remove-LocalGroupMember -Group 'Administrators' -Member $UserName -ErrorAction Stop
}
catch {
}

try {
    Add-LocalGroupMember -Group 'Users' -Member $UserName -ErrorAction Stop
}
catch {
}

Write-Host ''
Write-Host 'Standard user has been prepared.'
Write-Host "User     : $UserName"
Write-Host "Password : $Password"
Write-Host ''
Write-Host 'Run your app as the standard user with:'
Write-Host 'runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"'
Write-Host ''

Start-Process explorer.exe 'C:\Work\AppUnderTest'

采用这种配置后，Sandbox 启动时就已经准备好了标准用户，可以直接这样测试。

runas /user:wsbuser "C:\Work\AppUnderTest\MyApp.exe"

这样能看到什么

采用这种方式，以下问题会更容易暴露出来。

• 试图把运行时设置保存在 EXE 旁边而失败
• 试图写入 HKLM 而失败
• 更新程序以 machine-wide 为前提
• 日志保存位置在 Program Files 目录下
• 明明只有一个按钮需要管理员权限，却让整个应用都以提升权限为前提

有些管理员权限问题，光靠代码审查就能发现。不过，亲眼看到”实际以标准用户运行时会卡在哪里”，会让设计上的边界变得清晰得多。

有意制造权限或依赖不足的状态

不仅仅是”不是管理员”，有意去掉环境中部分便利之处，也能让隐藏的依赖暴露出来。

示例：20-restricted-runtime.wsb

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ProtectedClient>Enable</ProtectedClient>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

这个配置想要观察的内容

这个受限配置适合用来做以下确认。

• 是否存在没有网络就无法启动的 hidden dependency
• 是否以”通过剪贴板传入文件”为前提
• UI 或报表处理是否以”能看到默认打印机”为前提编写
• 是否存在在 RDP 会话下勉强能用、却带有多余依赖的操作
• 是否存在以”可以自由写入共享文件夹”为前提的粗糙实现

尤其是业务应用中，”在自己手头能正常操作”，但在现场终端上却可能

• 存在网络限制
• 存在剪贴板限制
• 没有打印机
• 存在共享文件夹写入限制

这类情况很常见。

如果先在 Sandbox 里贴近这种受限环境去验证，之后被现场问题卡住的情况会少很多。

不要把共享文件夹开放得太广

这一点也相当重要。

Sandbox 的 mapped folder 很方便，但 对设有 write 权限的共享文件夹所做的更改，即使关闭 Sandbox 后，也会残留在主机端。

因此，最好避免以下这类共享方式。

• 把整个 C:\Users 共享出去
• 把整个仓库以 write 方式开放
• 随意把 Downloads 或 Documents 设为 write 共享

基本原则是，

• 输入内容放在范围较窄的文件夹中，设为 read-only
• 只有输出内容放在专用的 Outbox 中，设为 read-write

分成这两层，是比较推荐的做法。

构建偏向资源不足的环境

Windows Sandbox 在资源控制方面的自由度并不高。不过，它仍然可以用于 “稍微收紧资源的轻度验证”。

示例：30-low-resource.wsb

<Configuration>
  <VGpu>Disable</VGpu>
  <MemoryInMB>2048</MemoryInMB>
  <Networking>Disable</Networking>

  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\AppUnderTest</HostFolder>
      <SandboxFolder>C:\Work\AppUnderTest</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>

    <MappedFolder>
      <HostFolder>C:\SandboxFixtures\Outbox</HostFolder>
      <SandboxFolder>C:\Work\Outbox</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>

  <LogonCommand>
    <Command>explorer.exe C:\Work\AppUnderTest</Command>
  </LogonCommand>
</Configuration>

这样更容易暴露的问题

使用这个配置，以下问题会更容易暴露出来。

• 启动时占用过多内存
• 读取大文件时没有考虑内存余量
• 没有 GPU 共享时渲染会变得极其卡顿
• WPF / WebView2 / 图像处理 / 视频处理在回退（fallback）时表现不佳
• 由于”手头有高性能 GPU 所以没被发现”的 UI 问题

根据 Microsoft 的配置规范，MemoryInMB 如果低于 2048MB，会被自动提升到启动所需的最小值。也就是说，在 Windows Sandbox 中进行低内存验证时，把 2GB 作为下限来考虑 会比较现实。

仅靠 Sandbox 不够的情况

反过来说，以下这些方面单靠 Windows Sandbox 会略显不足。

• 想大幅限制 CPU 使用率
• 想严格制造磁盘容量不足的情况
• 想制造 I/O 延迟
• 想以多种内存大小做矩阵式验证
• 想持续运行长时间的 soak test

这些场景，从一开始就使用 Hyper-V 之类的完整虚拟机会更直接。

Sandbox 擅长的是”轻度受限环境”，而不是”精密的负载测试平台”。

Windows 11 24H2 及之后版本也能用 CLI 方便操作

在 Windows 11 24H2 之后的新版 Windows Sandbox 中，也可以使用 CLI。

可用的命令大致如下。

• wsb start
• wsb list
• wsb connect
• wsb exec
• wsb share
• wsb stop

举个最简单的例子，流程是这样的。

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list

另外，Windows Sandbox CLI 的官方示例中使用了 Disabled，但 .wsb 配置文件的架构说明中给出的是 Disable / Enable / Default。如果要把内联 --config 纳入实际运维流程，请在对应的 Windows 11 24H2 及之后版本的实机上确认可被接受的写法。

如果知道正在运行的 Sandbox ID，

wsb connect --id <sandbox-id>

就可以用它来连接。

CLI 适合的场景

CLI 能发挥作用的场景大致如下。

• 想把 Sandbox 的启动纳入手头的复现脚本中
• 想从批处理或 PowerShell 中调用常用配置
• 想给正在运行的 Sandbox 添加文件夹共享
• 想把本地验证步骤稍微自动化一些

即便如此，仍建议保留 .wsb 的理由

不过，目前来看最好不要放弃 .wsb。

理由很简单：它可以作为场景名称来阅读。

• 00-clean-smoke.wsb
• 10-standard-user.wsb
• 20-restricted-runtime.wsb
• 30-low-resource.wsb

这样一来，任何人看了都能明白用途。

CLI 很方便，但在运维层面， “用 .wsb 定义条件，用 CLI 包装启动” 这样的角色分工是最容易操作的。

CLI 的注意事项

目前 wsb exec 在获取进程 I/O 方面存在限制，如果要在现有登录用户的上下文中执行，还需要有一个处于活动状态的用户会话。

也就是说，不要对它抱有”完全 headless 自动化测试平台”的过高期待。它对本地复现的自动化很有用，但并不是可以直接替代 CI 的类型。

实际运维中不想遗漏的注意点

最后，把实务中容易踩坑的地方汇总一下。

共享文件夹尽量最小化

Sandbox 本身是隔离的，但 mapped folder 与主机是相连的。设为 write 共享的文件夹会影响到主机。

不要共享得太广，可写入的共享只集中在 Outbox 上。这是基本原则。

日志和 dump 要在关闭前回收

这是显而易见的：一关闭就会消失。正因如此，最好从一开始就把输出目标固定为 Outbox。

标准用户验证不要”就用默认的 Sandbox 会话”敷衍了事

如果想切实排查管理员权限问题，用另一个用户启动会更容易梳理清楚。如果这里含糊处理，就会留下 “在 Sandbox 里能跑，但在客户的标准用户下却会崩溃” 的隐患。

不要过度依赖它来验证 OS 版本差异

Sandbox 适合用于同系列 OS 的干净验证，但它不是旧版 Windows 的复现器。如果想验证不同的 OS，从一开始就应该用完整虚拟机。

企业管理的终端可能存在策略限制

受 Group Policy 控制的设置，有时无法通过 .wsb 更改。如果在管控严格的企业终端上出现”设置不起作用”的情况，先怀疑是策略控制会更快找到原因。

总结

使用 Windows Sandbox，可以让 Windows 应用开发中的以下验证工作大幅加快。

• 排查管理员权限问题
• 干净环境下的首次安装确认
• 梳理网络或共享依赖
• 复现权限不足、依赖不足的情况
• 低内存 / 无 GPU 场景下的轻度限制验证

如果要归纳成实务中真正有效的做法，大致是以下这 5 点。

1. 固定创建 AppUnderTest、Scripts、Outbox
2. 按场景分别准备 .wsb
3. 输入设为 read-only，只有输出设为 read-write
4. 标准用户验证用另一个用户进行
5. 如果需要涉及 CPU、磁盘、旧版 OS，就升级到完整虚拟机

Sandbox 的优点并不在于万能，而在于 “能以很小的验证前准备成本，每次都把环境恢复干净”。

配合这个特点把场景固定下来，就更容易把验证从”当场临时复现”变成 可反复执行的验证流程。

相关文章

• Windows 的管理员特权何时才是必需的 - UAC、受保护区域与设计上的判断方法
• 在 Windows 应用中把”只有需要管理员权限的处理”分离出来的具体写法
• 如何选择 Windows 应用的发布方式 - MSI / MSIX / ClickOnce / xcopy / 自制 updater 的判断表
• Windows 应用崩溃 dump 收集入门 - 先弄清楚 WER / ProcDump / WinDbg 该如何分工

相关主题

• Windows 技术主题

与本主题相关的服务

• Windows 应用开发
• 技术咨询与设计评审
• 联系我们

参考资料

1. Microsoft Learn, Windows Sandbox
2. Microsoft Learn, Install Windows Sandbox
3. Microsoft Learn, Use and configure Windows Sandbox
4. Microsoft Learn, Windows Sandbox sample configuration files
5. Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
6. Microsoft Learn, Windows Sandbox versions
7. Microsoft Learn, Windows Sandbox command line interface

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

Windows Sandbox 适合哪些验证场景？

Windows Sandbox 适合干净环境下的首次安装确认、管理员权限问题的排查、网络或共享依赖的梳理、权限不足/依赖缺失的复现，以及低内存、无 GPU 等轻度限制场景的验证。它比完整虚拟机更轻量、启动更快，关闭后每次都会恢复干净状态。另一方面，如果要复现不同 OS 版本、同时启动多个实例，或严格复现 CPU 配额与磁盘紧张的情况，则更适合使用完整虚拟机。

使用 Windows Sandbox 有什么前提条件？

Windows Sandbox 可在 Windows Pro / Enterprise / Education 系列版本中使用，Home 版无法使用。此外需要启用虚拟化功能，并具备一定以上的内存、磁盘和 CPU 核心数。由于 Sandbox 使用与主机相同系列的 Windows 版本运行，如果主机是 Windows 11，就无法用来复现 Windows 10 环境。

.wsb 文件可以配置哪些内容？

可以固定网络的启用/禁用、共享文件夹的 read-only / read-write、内存上限（MemoryInMB）、禁用 vGPU、禁用剪贴板共享，以及启动时执行的命令（LogonCommand）等。按用途分别准备 .wsb 文件，只需双击即可反复创建相同条件的验证环境。需要注意的是，MemoryInMB 若设置低于 2048MB，会被自动提升到启动所需的最小值，因此低内存验证的下限现实中大约是 2GB。

可以在 Windows Sandbox 中验证标准用户的行为吗？

默认的 Sandbox 会话本身不太适合用来验证标准用户的行为，因为 Sandbox 的登录命令是以容器内的用户账户运行的，而该用户账户本应是管理员账户。如果想复现标准用户下权限不足的情况，比较清晰的做法是在启动脚本中于 Sandbox 内创建一个标准用户，再用 runas 命令以该用户身份启动应用。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。