用 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 也按情境固定。

困擾	先用的
乾淨環境的初次導入確認	`00-clean-smoke.wsb`
標準使用者的權限不足重現	`10-standard-user.wsb`
切斷網路或共享的受限環境確認	`20-restricted-runtime.wsb`
低記憶體・無 GPU 偏向確認	`30-low-resource.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 應用程式開發中管理員權限的話題相當混在一起。

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

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

這裡縮在 怎麼用 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 偏向的輕度限制驗證

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

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

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

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

參考資料

Microsoft Learn, Windows Sandbox
Microsoft Learn, Install Windows Sandbox
Microsoft Learn, Use and configure Windows Sandbox
Microsoft Learn, Windows Sandbox sample configuration files
Microsoft Learn, Windows Sandbox frequently asked questions (FAQ)
Microsoft Learn, Windows Sandbox versions
Microsoft Learn, Windows Sandbox command line interface

共用相同標籤的最新文章。能以相近的主題延伸理解。

Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式

從邊界與儲存位置的角度，整理 Windows 何時真正需要系統管理員權限：UAC、保護區、HKLM、服務、驅動、防火牆。同時說明 per-user 與 per-machine 的差異，以及把管理員處理切成獨立 EXE、服務或工作的設計取捨，幫讀者判斷該不該提權。

閱讀文章

ClickOnce 是什麼 - 以實務視角整理機制、更新、適合場面・不適合場面

本文以實務視角整理 ClickOnce 是什麼，從 manifest、快取、更新、簽章的構造，到適合公司內部 .NET 桌面業務應用程式的案件與不適合 machine-wide 或 service、driver 等深度 OS 整合的案件，幫助讀者判斷是否採用並掌握 depl...

閱讀文章

哪些應該用單元測試驗證，哪些該留給整合測試 - 切界線的方法與實務判斷表

本文以「想消弭哪種不確定性」為主軸，整理單元測試與整合測試該各自承擔什麼。從純邏輯、格式、接線、環境、時間五個切面歸納成判斷表，並列出 Repository 全 mock、Controller 連框架一起驗等常見誤區，幫讀者在實務上不再為界線猶豫。

閱讀文章

Windows 的 DLL 名稱解析機制 - 以實務角度整理搜尋順序、Known DLLs、API set、SxS

從實務角度整理 Windows 的 DLL 名稱解析，說明 loader 在掃描檔案系統前會先處理 DLL redirection、API set、SxS、Known DLLs，並用 SetDefaultDllDirectories 與 LoadLibraryEx 旗標縮小...

閱讀文章

Windows 應用程式中把「僅需要系統管理員權限的處理」分離出來的具體寫法

本文以 .NET 8 桌面應用程式為例,具體展示如何讓 UI 保持 asInvoker,把僅需系統管理員權限的處理切到 helper EXE。涵蓋 manifest、runas 啟動、具名管道 ACL、PID 驗證、固定 operation 與請求驗證,以及 Explore...

閱讀文章

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

Windows 應用程式開發

支援包含常駐處理、設備連動、運作日誌與可維護結構的 Windows 桌面應用程式。

查看服務聯絡我們

作者檔案

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

Go Komura

小村軟體有限公司代表

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

查看檔案聯絡我們

公開連結

GitHub LinkedIn X COM_BLAS COM_BigDecimal

先講結論

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

關掉每次都能重置

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

比全 VM 輕，管理成本低

能用 .wsb 和 CLI 固定情境

先掌握的限制

可使用的版本有限制

有虛擬化需求

Sandbox 會與主機同 OS 系

不能同時啟動多個

預設網路和剪貼簿有效

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

先做好較快的目錄結構

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

例: 00-clean-smoke.wsb

這樣容易發現的問題

網路有版也另外檔案持有

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

先看的觀點

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

例: 10-standard-user.wsb

例: Prep-StandardUser.ps1

這樣看得到什麼

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

例: 20-restricted-runtime.wsb

這個設定檔想看的

共享資料夾不要廣泛顯示

做資源不足偏向的環境

例: 30-low-resource.wsb

這樣容易看見的問題

Sandbox 不夠的情況

Windows 11 24H2 以後 CLI 也容易轉

CLI 適合的場面

仍要保留 .wsb 的理由

CLI 的注意點

運用上不想漏的注意點

共享資料夾最小化

日誌和傾印關掉前回收

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

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

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

總結

相關文章

參考資料

相關文章

Windows 什麼時候需要系統管理員權限 - UAC、保護區、設計上的分辨方式

ClickOnce 是什麼 - 以實務視角整理機制、更新、適合場面・不適合場面

哪些應該用單元測試驗證，哪些該留給整合測試 - 切界線的方法與實務判斷表

Windows 的 DLL 名稱解析機制 - 以實務角度整理搜尋順序、Known DLLs、API set、SxS

Windows 應用程式中把「僅需要系統管理員權限的處理」分離出來的具體寫法

相關主題

Windows 技術主題

與本主題相關的服務

Windows 應用程式開發

作者檔案

Go Komura

能用 `.wsb` 和 CLI 固定情境

例: `00-clean-smoke.wsb`

例: `10-standard-user.wsb`

例: `Prep-StandardUser.ps1`

例: `20-restricted-runtime.wsb`

例: `30-low-resource.wsb`

仍要保留 `.wsb` 的理由