用 Windows 沙箱加速 Windows 應用程式開發的驗證 - 以實務向整理管理員權限問題、乾淨環境、權限不足・資源不足的重現

Windows 應用程式開發中驗證變慢的理由大致相似。

• 手邊的開發機髒了，初次導入的問題重現不了
• 在客戶環境會發生，在自己的 PC 卻不會
• 「以管理員執行就能動」，但真正必要的權限邊界看不見
• 想試權限或相依不足時的行為，但不想破壞平時的環境
• 在低記憶體或無 GPU 偏向的狀態掉下，但不到每次架全 VM 的程度

這類情況，Windows 沙箱相當好用。

比全 VM 輕，啟動快，關掉每次都會乾淨地消失，所以與 「在同一 Windows 組建上，幾分鐘內重建乾淨驗證環境」 的需求相性好。

但只是沒想就每次打開全新 Sandbox，效率不會那麼提升。 實務上真正有效的是 按驗證情境固定 .wsb，把唯讀的輸入資料夾與只寫的回收資料夾分開，區分使用管理員系・標準使用者系・受限制系 的運用。

本文以 Windows 應用程式開發的觀點整理這個做法。 內容以 2026 年 4 月時點能確認的 Microsoft 官方資訊為前提。

先講結論

先排結論，實務上大致如下。

• Windows 沙箱適合乾淨環境的重現、初次導入確認、管理員權限問題的區分、相依不足的盤查。
• 比起每次用 GUI 手作業，按用途分 .wsb 更快。
• 主機共享以 輸入用 read-only、只有輸出 read-write 分開，事故會減少。
• 預設的 Sandbox 工作階段對標準使用者驗證不易直接使用。想做標準使用者驗證的話，在 Sandbox 內建立別的使用者，以該使用者啟動。
• 記憶體不足或無 GPU 偏向的重現，.wsb 的 MemoryInMB 和 VGpu / vGPU 無效化 有效。
• 但 CPU 配額、磁碟逼迫、多個同時啟動、不同 OS 版本的重現 想做的話，比起 Windows 沙箱，全 VM 更適合。

簡言之，Windows 沙箱是 「輕但用完即丟」 「快但同 OS 系列」 「有限但足夠在實務上有效」 的驗證環境。 先理解這個立場，就不會錯用處。

為何 Windows 沙箱與開發驗證相性好

Windows 沙箱與 Windows 應用程式開發相性好的理由有以下 4 個。

關掉每次都能重置

這最大。

重複試安裝程式、破壞設定、動登錄檔、放進拿出前提物。 這類作業在開發機本體做，環境會漸漸變成「不知道放了什麼的環境」。

Sandbox 關掉全部消失。 所以容易發現 只在初次導入時發生的問題 或 因前提物剛好在手邊而看不見的問題。

能立刻做出同 Windows 系列的乾淨環境

Windows 沙箱以使用與主機同系列的 Windows 組建為前提。 這是限制也是，反過來說 能立刻做出與手邊 Windows 11 同系列的乾淨環境。

「客戶是 Windows 11 24H2，這邊也是 Windows 11 24H2」的狀況下，相當好處理。

比全 VM 輕，管理成本低

Hyper-V 或 VMware 的全 VM 強大，但每次用途如果是

• 安裝步驟確認
• UAC 的出現方式確認
• 權限不足時的錯誤確認
• 相依不足時的日誌確認
• 乾淨環境的冒煙測試

程度，常常稍微重。

Windows 沙箱不用那麼帶入 OS 影像管理或快照運用，所以 容易推進「稍微想重現」的驗證 是強項。

能用 .wsb 和 CLI 固定情境

Sandbox 的真價與其說「能安全試」，不如說是 能用相同條件重複多少次都能重做。

• 網路有 / 無
• 共享資料夾 read-only / read-write
• 低記憶體
• 無 GPU 共享
• 無剪貼簿共享
• 啟動時執行特定腳本

這一帶用 .wsb 或 Windows 11 24H2 以後的 CLI 固定，驗證就從「想到的作業」變成「可重複的步驟」。

先掌握的限制

方便但不適合的也有。這裡先掌握比較好。

可使用的版本有限制

Windows 沙箱在 Windows Pro / Enterprise / Education 系可用。 Home 版不可用。

公司內的開發機是 Pro 但業務終端或個人 PC 是 Home 的情況有，會在那卡住。

有虛擬化需求

使用前提是虛擬化功能有效，有一定以上的 RAM / 磁碟 / CPU 核心。 雖說輕，但也不是完全免費。

Sandbox 會與主機同 OS 系

這在實務上相當重要。

Windows 沙箱不適合不同 OS 版本的驗證。

• 主機是 Windows 11 的話，不會成為 Windows 10 的重現環境
• 客戶使用舊組建的話，那個差異填不滿

所以 不同 OS 版的相容性驗證 或 舊組建依賴的問題，從一開始選全 VM 比較好。

不能同時啟動多個

目前 Windows 沙箱 不適合同時跑多個實例的運用。

想並行跑測試矩陣，Hyper-V 等比較自然。

預設網路和剪貼簿有效

這容易漏看。

Windows 沙箱預設網路連線有效。 剪貼簿共享也預設有效。

也就是說，沒想就啟動 「不是完全封閉的世界」。 確認不明檔案或重現相依不足時，從一開始用 .wsb 明確控制比較安全。

Windows 11 24H2 以後部分 inbox 應用程式不可用

Windows 11 24H2 以後的 Sandbox，記事本、終端機、計算機、照片等部分 inbox Store 應用程式不可用。

所以啟動時自動化或輔助操作，以 cmd.exe、powershell.exe、explorer.exe 為前提組 比較無難。

先做好較快的目錄結構

每次現場決定共享資料夾不如先建 1 處驗證用放置處就相當輕鬆。

例如這種結構。

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: 日誌、傾印、匯出結果。read-write 共享

這樣分，Sandbox 側能寫回主機的位置限定在 Outbox，相當安全。

此外 .wsb 也按情境固定。

光這些驗證的開始成本就大幅降低。

把乾淨環境的冒煙測試做成 1 次雙擊

先想做的是 乾淨環境冒煙測試用 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>

這用途重要的是以下。

• 發佈物放在 AppUnderTest
• 該資料夾以 read-only 顯示
• 只把日誌或結果寫到 Outbox
• 不想看網路相依就從一開始切掉

這樣只要替換發佈物並雙擊 .wsb，每次都能做乾淨的初次驗證。

這樣容易發現的問題

此階段常發現的例如以下。

• 開發機有但正式沒有的前提 DLL / 執行環境
• WebView2 或 VC++ 可轉散發套件的前提變成隱性
• 只在初次啟動時建立的目錄或設定檔的建立處不好
• 想寫執行時資料到 Program Files 下而掉
• 「開發者手邊有」的憑證・字型・設定變成前提

重點是 在 Sandbox 側發生的事一定輸出到 Outbox。 關掉的瞬間全部消失，日誌或傾印都不要就那樣留。

網路有版也另外檔案持有

如果對象是 Web installer 或有線上認證的應用程式，切斷網路看到的只是別的問題。

此情況以同樣構成做成 01-clean-online.wsb 這樣的另外檔案，不要混合「離線前提的重現」和「線上前提的重現」 比較好整理。

區分管理員權限問題的步驟

Windows 應用程式開發中管理員權限的話題相當混在一起。

• 只有安裝時必要嗎
• 到執行時都必要嗎
• 只有部分設定變更必要嗎
• 其實只是儲存處不好嗎

這個話題本身整理在之前寫的下列文章。

• Windows 的系統管理員特權什麼時候必要 - UAC、保護區域、設計上的辨別法
• Windows 應用程式中「只把需要系統管理員權限的處理」分離的具體寫法

這裡縮在 怎麼用 Sandbox 加速驗證。

先看的觀點

Sandbox 先想確認的是以下邊界。

• 安裝程式是否寫到 Program Files 或 HKLM
• 是否有服務註冊、驅動程式導入、防火牆設定變更
• 更新程式是否試圖 machine-wide 替換
• 是否試圖把執行時的設定、日誌、快取寫到保護區域
• 是否有 Shell Extension 或 COM 註冊這類 OS 整合

也就是以 分開「真正需要管理員的處理」和「只是執行時放置處不好的處理」 為目的。

Sandbox 的預設狀態不會成為標準使用者驗證

這裡重要。

Windows 沙箱的登入命令以容器的使用者帳戶運作。 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 下
• 只有 1 個按鈕需要管理員，卻以整個應用程式提升為前提

管理員權限問題光程式碼審查就能知道的情況有。 但 「實際以標準使用者運作會在哪卡」 用眼看，設計上的邊界會變相當清楚。

意圖製作權限或相依不足的狀態

不只「不是管理員」，故意消掉一部分環境側的便利，隱藏的相依會看見。

例: 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 顯示整個儲存庫
• 粗略地 write 共享 Downloads 或 Documents

基本是，

• 輸入物以 narrow 資料夾 read-only
• 只有輸出物到專用 Outbox read-write

這 2 段推薦。

做資源不足偏向的環境

Windows 沙箱的資源控制自由度不高。 但 「稍微縮減資源的驗證」 能用。

例: 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 沙箱的低記憶體驗證大致以 2GB 為下限基準思考 比較現實。

Sandbox 不夠的情況

反之以下 Windows 沙箱不夠。

• 想強力縮減 CPU 使用率
• 想嚴格製造磁碟容量不足
• 想製造 I/O 延遲
• 想以多種記憶體大小矩陣式跑
• 想持續跑長時間運行的 soak test

這一帶從一開始提升到 Hyper-V 等全 VM 較自然。

Sandbox 擅長到「輕的限制環境」，不是「精確的負載試驗基礎」。

Windows 11 24H2 以後 CLI 也容易轉

Windows 11 24H2 以後的新 Windows 沙箱也能用 CLI。

能用的例如以下。

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

例如最低限這樣流程。

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

知道執行中 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 取得限制，以既有登入使用者脈絡執行時也需要有 active 的使用者工作階段。

也就是 不要過度期待為完全 headless 的自動試驗基礎。 本地重現的自動化方便，但不是放著就能代替 CI 的類型。

運用上不想漏的注意點

最後只整理實務上容易卡的點。

共享資料夾最小化

Sandbox 是 isolated，但 mapped folder 與主機連接。 write 共享的資料夾會影響主機。

不廣泛共享，可寫的共享只靠到 Outbox。 這是基本。

日誌和傾印關掉前回收

當然關了會消。 所以 輸出處從一開始固定在 Outbox 比較好。

標準使用者驗證不要「以預設 Sandbox 工作階段原樣」結束

要好好區分管理員權限問題，以別使用者啟動比較好整理。 這裡曖昧的話，「Sandbox 動了但客戶的標準使用者掉」 會留下。

OS 版本差的驗證不要過度使用

Sandbox 適合同系列 OS 的乾淨驗證，不是舊版 Windows 的重現器。 想看別 OS 從一開始全 VM。

企業管理終端可能有政策限制

被 Group Policy 控制的設定，有時從 .wsb 也變不了。 公司內嚴格終端「設定不生效」時先懷疑政策控制比較快。

總結

Windows 沙箱在 Windows 應用程式開發中大幅加速以下驗證。

• 管理員權限問題的區分
• 乾淨環境的初次導入確認
• 網路或共享相依的盤查
• 權限不足・相依不足的重現
• 低記憶體 / 無 GPU 偏向的輕度限制驗證

整理為實務有效的形式，大致如下。

1. AppUnderTest、Scripts、Outbox 固定建立
2. .wsb 按情境分
3. 輸入 read-only，只有輸出 read-write
4. 標準使用者驗證以別使用者進行
5. 需要 CPU / 磁碟 / 舊 OS 就提升到全 VM

Sandbox 的好處不是萬能。 「把驗證前的準備做小，且環境每次都能乾淨復原」。

配合這個特徵固定情境， 就能變成不是「當場的重現」，而是 可重複的驗證步驟 來跑。

相關文章

• Windows 的系統管理員特權什麼時候必要 - UAC、保護區域、設計上的辨別法
• Windows 應用程式中「只把需要系統管理員權限的處理」分離的具體寫法
• Windows 應用程式的發佈方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 獨自 updater 的判斷表
• Windows 應用程式的當機傾印收集入門 - 先如何區分使用 WER / ProcDump / WinDbg

參考資料

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 沙箱適合什麼樣的驗證？

適合乾淨環境的重現、初次導入確認、管理員權限問題的區分、相依不足的盤查，以及低記憶體或無 GPU 偏向的輕度限制驗證。它比全 VM 輕、啟動快、關掉每次都會乾淨消失，適合「在同一 Windows 組建上，幾分鐘內重建乾淨驗證環境」的需求。想固定條件重複驗證，按情境分開 .wsb 檔案會更有效率。

Windows 沙箱有什麼限制？

只在 Windows Pro / Enterprise / Education 系可用，Home 版不可用。Sandbox 與主機是同 OS 系列，不適合不同 OS 版本的相容性驗證，也不適合同時啟動多個實例，這些情況全 VM 比較適合。另外預設網路連線與剪貼簿共享是有效的，想控制要用 .wsb 明確設定。

可以在 Windows 沙箱裡做標準使用者的驗證嗎？

預設的 Sandbox 工作階段以容器的系統管理員帳戶運作，不易直接用於標準使用者驗證。文章的做法是用 .wsb 的 LogonCommand 執行 PowerShell 腳本，在 Sandbox 內另建標準使用者，再用 runas 以該使用者啟動應用程式。這樣容易看見寫到 HKLM 失敗、設定存到 EXE 旁失敗等「實際以標準使用者運作會在哪卡」的問題。

沙箱的共享資料夾該怎麼設定比較安全？

輸入物（驗證對象與腳本）以窄範圍資料夾用 read-only 共享，只有輸出用專用的 Outbox 以 read-write 共享。對有 write 權限的共享資料夾的變更，即使關了 Sandbox 也會留在主機側，所以要避免整個共享 C:\Users 或粗略地 write 共享 Downloads、Documents。日誌和傾印在關掉前要輸出到 Outbox 回收，否則會全部消失。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。