遊戲開發人員的使用者帳戶控制

發行項
11/10/2023

本文說明遊戲開發人員有效使用 Windows Vista 中引進的用戶帳戶控制（UAC）安全性功能的指導方針和最佳做法。

用戶帳戶控制概觀
Windows Vista 中的用戶帳戶
以標準使用者身分存取檔案
以標準使用者身分登錄存取
許可權提升
使用 CreateProcess 的 UAC 含意（）
在應用程式指令清單中設定執行層級
在 Visual Studio 中內嵌指令清單
UAC 與舊版遊戲的相容性
舊版案例和指令清單
結論
進一步閱讀

用戶帳戶控制概觀

在 Windows Vista 中引進的使用者帳戶控制（UAC）是一項安全性功能，旨在協助防止惡意攻擊者使用在廣泛使用的應用程式中找到的弱點或錯誤來改變操作系統或其他已安裝的程式。這可藉由以標準使用者身分執行絕大多數程式和程式來完成，即使目前的用戶帳戶具有系統管理認證，亦即有限使用者、受限制的使用者或最低特殊許可權使用者。具有標準使用者許可權的程式有許多固有的限制，可防止它進行全系統變更。

UAC 也會使用以對話為基礎的驗證配置，在執行指定為需要系統管理許可權的特定進程時，負責提高進程的許可權。許可權提升可讓系統管理員以安全許可權等級執行大部分的應用程式（與任何其他標準使用者相同），但也允許需要系統管理許可權的進程和作業。 UAC 支援過度肩部驗證，讓系統管理員可以在標準使用者目前登入系統時，將提升的許可權授與程式。

UAC 功能預設為啟用。雖然系統管理員可以停用整個 UAC 系統，但這樣做有許多負面影響。首先，這會削弱所有系統管理帳戶的安全性，因為所有程式都會以系統管理認證執行，即使大部分的應用程式實際上不需要它們也一樣。停用 UAC 之後，公開安全性中可惡意探索弱點的標準使用者應用程式可能會用來竊取私人資訊、安裝 rootkit 或間諜軟體、終結系統完整性，或在其他系統上主機殭屍攻擊。啟用UAC時，以標準使用者身分執行大部分的軟體，可大幅限制這類Bug的潛在損害。其次，關閉 UAC 會停用許多應用程式相容性的因應措施，讓真正的標準用戶能夠成功執行廣泛的應用程式。請勿建議停用UAC作為相容性因應措施。

請務必注意，如果可能的話，應用程式應該只努力使用標準用戶權力。雖然系統管理員可以輕鬆地提高程序的許可權，但每次執行需要系統管理認證的應用程式時，提高許可權仍然需要使用者互動和認可。此提高許可權也必須在程序啟動時完成，因此即使是單一作業也需要系統管理認證，才能讓系統面臨應用程式整個運行時間更大的風險。標準使用者若無法提高其許可權，在家族和商務設定中也很常見。「執行身分管理員 istrator」不是相容性的良好因應措施，可讓使用者和系統面臨更大的安全性風險，而且在許多情況下對使用者造成挫折感。

注意

Windows Vista 中引進的用戶帳戶控制功能也出現在 Windows 7 中。雖然使用各種系統功能的使用者體驗在用戶帳戶控制方面已改善，但對應用程式的影響基本上相同。本文中的所有 Windows Vista 建議也適用於 Windows 7。如需 Windows 7 UAC UI 變更的詳細資訊，請參閱使用者介面 - 用戶帳戶控制對話框更新。

Windows Vista 中的用戶帳戶

Windows Vista 會將每個使用者分類為兩種使用者帳戶類型：系統管理員和標準使用者。

標準用戶帳戶類似於 Windows XP 中的有限用戶帳戶。就像在 Windows XP 中一樣，標準使用者無法寫入 Program Files 資料夾、無法寫入登錄的HKEY_LOCAL_MACHINE部分，也無法執行改變系統的工作，例如安裝內核模式驅動程式或存取系統層級進程空間。

自 Windows XP 發行後，管理員 istrator 帳戶已大幅變更。先前，由管理員 istrators 群組成員啟動的所有進程都會獲得系統管理許可權。啟用UAC之後，除非系統管理員特別提高，否則所有進程都會以標準使用者許可權執行。這項差異可藉由降低大多數程式中潛在 Bug 所造成的安全性風險，讓管理員 istrators 群組中的帳戶更安全。

當以標準使用者程序執行時，所有應用程式，尤其是遊戲，都能有效且負責任地運作。所有需要系統管理許可權的作業都應該在安裝時間完成，或由明確要求系統管理認證的輔助程式來完成。雖然許可權提升對於管理員 istrators 群組的成員來說相當簡單，但標準用戶必須延遲具有系統管理認證的人員，才能實際輸入其密碼來提升許可權。由於受家長監護保護的帳戶必須是標準使用者，因此對於使用 Windows Vista 的遊戲玩家來說，這種情況非常常見。

如果您的遊戲已經在使用有限的用戶帳戶在 Windows XP 上運作，則移至 Windows Vista 上的使用者帳戶控制應該很容易。雖然強烈建議新增應用程式指令清單，但大部分這類應用程式都會依現成運作。（本主題稍後會說明指令清單在應用程式指令清單中設定執行層級。

以標準使用者身分存取檔案

受到標準使用者限制影響的遊戲層面是文件系統組織和輔助功能。您不應該假設您的遊戲可以將檔案寫入您遊戲安裝所在的資料夾。例如，在 Windows Vista 中，使用者的許可權必須由操作系統提升，應用程式才能寫入 Program Files 資料夾。若要避免這種情況，您應該依範圍和輔助功能來分類遊戲數據檔，並使用 SHGetFolderPath 函式以及Windows殼層提供的 CSIDL 常數來產生適當的檔案路徑。 CSIDL 常數會對應至操作系統所使用的已知資料夾，並升級為分割全域和使用者特定檔案。

如果應用程式沒有系統管理許可權，嘗試在資料夾下建立或寫入檔案或目錄，但未將寫入許可權授與進程將會失敗。如果您的 32 位遊戲可執行檔是在舊版模式中執行，因為它未宣告要求的執行層級，其寫入作業將會成功，但將會受到虛擬化，如本文稍後的一節所述。

資料表 1。已知資料夾

CSIDL 名稱	典型路徑（Windows Vista）	標準用戶權力	管理員 istrator Rights	存取範圍	描述	範例
CSIDL_PERSONAL	C：\Users\user name\Documents	讀取/寫入	讀取/寫入	每位使用者	讀取和修改的使用者特定遊戲檔案，而且可以在遊戲內容之外操作。	螢幕快照。已儲存具有擴展名關聯的遊戲檔案。
CSIDL_LOCAL_APPDATA	C：\Users\user name\AppData\Local	讀取/寫入	讀取/寫入	每位使用者	讀取和修改的使用者特定遊戲檔案，而且只能在遊戲內容中使用。	遊戲快取檔案。播放機設定。
CSIDL_COMMON_APPDATA	C：\ProgramData	如果擁有者，讀取/寫入	讀取/寫入	所有使用者	用戶可建立的遊戲檔案，並由所有用戶讀取。寫入許可權只會授與檔案的建立者（擁有者）。	使用者設定檔
CSIDL_PROGRAM_FILES	C:\Program Files 或 C：\Program Files （x86）	唯讀	讀取/寫入	所有使用者	由所有用戶讀取的遊戲安裝程式所撰寫的靜態遊戲檔案。	遊戲資產，例如材質和網格。

您的遊戲通常會安裝在 CSIDL_PROGRAM_FILES 常數所代表資料夾的資料夾中。不過，情況不一定如此。當產生路徑字串至位於安裝資料夾底下的檔案或目錄時，您應該改用可執行檔的相對路徑。

您也應該避免對已知資料夾路徑進行硬式編碼的假設。例如，在 Windows XP Professional 64 位版本和 Windows Vista x64 上，程式檔路徑是 32 位程式的 C：\Program Files （x86），64 位程式的 C：\Program Files。這些已知路徑會從 Windows XP 變更，而且使用者可以重新設定其中許多資料夾的位置，甚至將它們放在不同的磁碟驅動器上。因此，請一律使用 CSIDL 常數來避免混淆和潛在問題。 Windows 安裝程式了解這些已知的資料夾位置，並在從 Windows XP 升級作業系統時移動數據;相反地，在操作系統升級之後，使用非標準位置或硬式編碼路徑可能會失敗。

請注意CSIDL_PERSONAL和CSIDL_LOCAL_APPDATA所指定使用者特定資料夾之間的細微可用性差異。若要選取要用來寫入檔案的 CSIDL 常數，建議的做法是，如果使用者預期要與檔案互動 CSIDL_PERSONAL，例如按兩下檔案，以在工具或應用程式中開啟檔案，以及針對其他檔案使用CSIDL_LOCAL_APPDATA。您的應用程式可以利用這兩個資料夾來儲存及組織使用者特定的數據檔，因為其存取範圍或許可權等級沒有任何差異。請小心建立唯一的路徑名稱，使其無法與其他應用程式發生衝突，但足夠短，使完整路徑中的字元數目少於 MAX_PATH，260。

下列程式代碼提供如何將檔案寫入已知資料夾的範例：

#include <windows.h>
#include <shlobj.h>
#include <shlwapi.h>
        ...
        ...
        ...
        TCHAR strPath[MAX_PATH];
        if( SUCCEEDED(
        SHGetFolderPath( NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, strPath ) ) )
        {
        PathAppend( strPath, TEXT( "Company Name\\Title" ) );

        if( !PathFileExists( strPath ) )
        {
        if( ERROR_SUCCESS != SHCreateDirectoryEx( NULL, strPath, NULL ) )
        return E_FAIL;
        }

        PathAppend( strPath, TEXT( "gamefile.txt" ) );

        // strPath is now something like:
        // C:\Users\<current user>\Documents\Company Name\Title\gamefile.txt
        // Open the file for writing
        HANDLE hFile = CreateFile(strPath, GENERIC_WRITE, NULL, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

        if( INVALID_HANDLE_VALUE != hFile )
        {
        // TODO: Write to file
        CloseHandle(hFile);
        }
        }

以標準使用者身分登錄存取

標準使用者的登錄存取限制與文件系統類似。允許標準使用者讀取登錄中所有機碼的存取權;不過，寫入許可權只會授與目前使用者的 HKEY_CURRENT_USER （HKCU）子樹，該子樹會在內部對應至目前使用者的使用者特定子機碼HKEY_USERS\Security ID （SID）。需要寫入HKEY_CURRENT_USER以外的任何登錄位置的應用程式需要系統管理許可權。

如果 32 位應用程式在其指令清單中不包含要求的執行層級，則所有寫入HKEY_LOCAL_MACHINE\Software 都會虛擬化，而寫入HKEY_CURRENT_USER以外的其他位置將會失敗。

不建議在登錄中儲存持續性數據，例如用戶的設定。從遊戲儲存永續性數據的慣用方法是呼叫 SHGetFolderPath 並將數據寫入文件系統，並取得上一節所述的CSIDL常數值。

許可權提升

在 Windows Vista 中，任何需要系統管理許可權的應用程式都必須在其指令清單中宣告系統管理執行層級的要求（如下一節所述，在應用程式指令清單中設定執行層級）。

眾所周知，提高許可權是由UAC所驅動，以將程式升階為系統管理程式。程序的許可權只能在建立時提高。建立之後，永遠不會將程式升階為較高的許可權等級。基於這個理由。需要系統管理認證的作業應該隔離，以分隔安裝程式和其他輔助程式。

執行程式時，UAC 會檢查指令清單中所要求的執行層級，如果需要提高的許可權，則會提示目前使用者輸入兩個標準對話方塊之一：一個用於標準使用者，另一個用於系統管理員。

如果目前的使用者是標準使用者，UAC 會在允許程式執行之前，提示使用者輸入系統管理員的認證。

圖 1. 提示標準使用者輸入系統管理帳戶的認證

prompt for a standard user to enter credentials for an administrative account

如果目前使用者是系統管理員，UAC 會在允許程序執行之前，提示使用者輸入許可權。

圖 2. 提示管理員 istrator 授權計算機的變更

prompt for an administrator to authorize changes to the computer

只有在標準使用者提供適當的系統管理認證或系統管理使用者提供通知時，才會將應用程式授與系統管理許可權;任何其他專案都會導致應用程式終止。

請務必注意，具有較高許可權的程式會以在 UAC 提示中輸入認證的系統管理用戶執行，而不是以目前登入的標準使用者身分執行。這類似於 Windows XP 中的 RunAs ，提升許可權的程式在存取每個用戶數據時會取得系統管理員的資料夾和登錄機碼，而提高許可權進程啟動的所有程式也會同時繼承系統管理許可權和用戶帳戶位置。針對系統提示通知的系統管理員（繼續或取消），這些位置會符合目前使用者的位置。不過，一般而言，需要提高許可權的程式不應該對每個用戶的數據運作。請注意，這可大幅影響安裝程序必須如何運作！如果安裝程式以系統管理員身分執行、寫入 HKCU 或使用者配置檔，很可能會寫入錯誤的位置。請考慮在第一次執行遊戲時建立這些每個使用者值。

使用 CreateProcess 的 UAC 含意（）

UAC 提高許可權機制將不會從 Win32 CreateProcess（）函式的呼叫叫用，以啟動設定為需要比目前進程更高的執行層級的可執行檔。因此，呼叫 CreateProcess（）將會失敗，而 GetLastError（）會傳回ERROR_ELEVATION_REQUIRED。 只有在被呼叫端的執行層級等於或小於呼叫端時，CreateProcess（）才會成功。必須使用ShellExecute（）函式產生提升許可權進程的非提升許可權進程，這會導致 UAC 提高許可權機制透過殼層觸發。

在應用程式指令清單中設定執行層級

您可以藉由將擴充功能新增至應用程式指令清單，來宣告遊戲所要求的執行層級。下列 XML 程式代碼顯示設定應用程式執行層級所需的最小組態：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
        <ms_asmv2:security>
            <ms_asmv2:requestedPrivileges>
                <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
            </ms_asmv2:requestedPrivileges>
        </ms_asmv2:security>
    </ms_asmv2:trustInfo>
</assembly>

在上述程式代碼中，操作系統會通知遊戲只需要下列標記的標準用戶許可權：

<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />

藉由將 requestedExecutionLevel 明確設定為 “asInvoker”，此範例會判斷提示操作系統遊戲在沒有系統管理許可權的情況下正常運作。因此，UAC 會停用虛擬化，並使用與通常標準使用者許可權的叫用者相同的許可權來執行遊戲，因為 Windows 檔案總管會以標準使用者身分執行。

操作系統可以通知遊戲需要提高系統管理許可權，方法是將「asInvoker」取代為「require 管理員 istrator」，以建立下列標記：

<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

使用此設定時，操作系統會在每次執行遊戲時，以其中一個標準 UAC 提高許可權對話框提示目前使用者。強烈建議不要讓遊戲需要系統管理員許可權才能執行，因為此對話框不僅會變得令人惱火，而且還會使遊戲與家長控制不相容。將這項需求新增至任何可執行檔之前，請仔細思考。

常見的誤解是新增將 requestedExecutionLevel 設定為 “require 管理員 istrator” 的指令清單會略過提高許可權提示的需求。不正確。它只會防止作業系統猜測您的設定或更新應用程式是否需要系統管理許可權。使用者仍會提示授權提高許可權。

Windows 會在顯示 UAC 提示之前，檢查標示為提高許可權的任何應用程式簽章。標示提高許可權的大型可執行檔比小型可執行檔還要長，而且比標示為 “asInvoker” 的可執行檔還要長。因此，自我擷取的安裝程式可執行檔應該標示為「asInvoker」，而且任何需要標示為「require 管理員 istrator」的部分都應該放在個別的協助程式可執行檔中。

上述範例中顯示的 uiAccess 屬性應該一律為 FALSE。這個屬性會指定使用者介面自動化用戶端是否可以存取受保護的系統 UI，如果設定為 TRUE，則會有特殊的安全性影響。

在 Visual Studio 中內嵌指令清單

指令清單支援從 VS2005 開始首次新增至 Visual Studio。根據預設，Visual Studio 2005（或更新版本）內建的可執行檔會在建置程式中內嵌自動產生的指令清單。自動產生指令清單的內容取決於您在專案屬性對話框中指定的特定項目組態。

Visual Studio 2005 自動產生的指令清單不會包含 <trustInfo> 區塊，因為無法設定項目屬性中的 UAC 執行層級。新增這項資訊的慣用方式是讓 VS2005 將包含 trustInfo> 區塊的使用者定義指令清單與自動產生的指令清單<合併。這和將 *.manifest 檔案新增至方案一樣簡單，其中包含上一節所列的 XML。當 Visual Studio 在您的方案中遇到 .manifest 檔案時，它會自動叫用指令清單工具（mt.exe）來合併 .manifest 檔案與自動產生的指令清單檔案。

注意

Visual Studio 2005 提供的指令清單工具（mt.exe）中有一個錯誤，導致合併和內嵌指令清單，這可能會導致可執行檔在 SP3 之前於 Windows XP 上執行時發生問題。 Bug 是工具在 trustInfo> 區塊宣告<時重新定義預設命名空間的結果。幸運的是，藉由在 trustInfo> 區塊中<明確宣告不同的命名空間，並將子節點範圍設定為新的命名空間，即可完全略過此問題。上一節中提供的 XML 示範此修正程式。

使用 Visual Studio 2005 中所含 mt.exe 工具的警告是，當處理 <trustInfo> 區塊時，它會產生警告，因為此工具不包含更新的架構，以驗證 XML。若要補救此警告，建議您將Visual Studio 2005安裝目錄下的所有 mt.exe 檔案取代為最新的 Windows SDK 中提供的 mt.exe。

從 Visual Studio 2008 開始，您現在可以從專案屬性對話框（圖 3）或使用 /MANIFESTUAC 連結器旗標來指定應用程式的執行層級。設定這些選項會導致 Visual Studio 2008 自動產生，並將具有適當 <trustInfo> 區塊的指令清單內嵌至可執行檔。

圖 3. 在 Visual Studio 2008 中設定執行層級

setting the execution level in visual studio 2008

在舊版Visual Studio中內嵌指令清單，但仍可支援指令清單，但需要開發人員執行更多工作。如需如何執行這項操作的範例，請在 2008 年 3 月版本之前，檢查 DirectX SDK 中任何範例中包含的 Visual Studio 2003 專案。

UAC 與舊版遊戲的相容性

如果您的遊戲似乎已成功將檔案儲存並載入至 Program Files 目錄，但沒有任何檔案 iOn Windows Vista 的辨識項，其指令清單中未包含所要求執行層級的任何 32 位應用程式都會被視為舊版應用程式。在 Windows Vista 之前，大部分的應用程式通常是由具有系統管理許可權的用戶執行。因此，這些應用程式可以自由讀取和寫入系統檔案和登錄機碼，許多開發人員並未進行在 Windows XP 上的有限使用者帳戶上正常運作所需的變更。不過，在 Windows Vista 上，這些相同的應用程式現在會因為新安全性模型下的存取許可權不足而失敗，這會強制執行舊版應用程式的標準用戶執行。為了減輕這一點的影響，虛擬化也已新增至 Windows Vista。虛擬化會讓數千個舊版應用程式在 Windows Vista 上運作良好，而不需要這些應用程式隨時擁有更高的許可權，只要在一些次要作業中成功即可。發現，您的遊戲有可能以舊版模式執行，並受到虛擬化。

虛擬化會將系統敏感性寫入（以及後續的檔案或登錄作業）重新導向至目前使用者配置檔內的每個使用者位置，進而影響檔系統和登錄。例如，如果應用程式嘗試寫入下列檔案：

C：\\Program Files\\Company Name\\Title\\config.ini

寫入會自動重新導向至：

C：\\Users\\user name\\AppData\\Local\\VirtualStore\\Program Files\\Company Name\\Title\\config.ini

同樣地，如果應用程式嘗試寫入如下的登錄值：

HKEY\_LOCAL\_MACHINE\\Software\\Company Name\\Title

它會改為重新導向至：

HKEY\_CURRENT\_USER\\Software\\Classes\\VirtualStore\\MACHINE\\Software\\Company Name\\Title

受虛擬化影響的檔案和登錄機碼只能由以目前使用者身分執行的虛擬化應用程式進行檔案和登錄作業存取。

不過，虛擬化有許多限制。其中一個是64位應用程式永遠不會在舊版模式中執行，因為32位應用程式中受到虛擬化的相容性作業只會在64位中失敗。此外，如果以標準使用者身分執行的舊版應用程式嘗試將任何類型的可執行檔寫入需要系統管理認證的位置，則不會進行虛擬化，而且寫入將會失敗。

圖 4。虛擬化程式

virtualization process

當舊版應用程式嘗試在檔案系統或登錄中的系統敏感性位置上進行讀取作業時，會先搜尋虛擬位置。如果找不到檔案或登錄機碼，則操作系統會存取預設系統位置。

虛擬化將會從後續版本的 Windows 中移除，因此請務必不要依賴這項功能。相反地，您應該針對標準使用者或系統管理許可權明確設定應用程式指令清單，因為這會停用虛擬化。對終端用戶來說，虛擬化也並不明顯，因此即使虛擬化可能允許您的應用程式執行，它也會產生支援呼叫，並使得難以為這些客戶進行疑難解答。

請注意，如果 UAC 已停用，則虛擬化也會停用。如果虛擬化已停用，標準使用者帳戶的行為與 Windows XP 中的有限用戶帳戶完全相同，而舊版應用程式可能無法針對因虛擬化而成功的標準使用者正確運作。

舊版案例和指令清單

在大部分的使用案例中，只要以正確的 UAC 指令清單元素標記 .exe，並確保應用程式以標準使用者正確運作，就足以達到絕佳的 UAC 相容性。大部分玩家都在執行已啟用用戶帳戶控制的 Windows Vista 或 Windows 7。針對已停用用戶帳戶控制功能的 Windows Vista 或 Windows7 上的 Windows XP 和使用者，他們通常會使用系統管理員帳戶來執行。雖然這是較不安全的作業模式，但通常不會遇到任何其他相容性問題，但如上所述，停用 UAC 也會停用虛擬化。

當程式在 UAC 資訊清單中標示為「require管理員istrator」時，有一個特別的情況值得指出。在 Windows XP 和已停用使用者帳戶控制的 Windows Vista 或 Windows 7 上，系統會忽略 UAC 資訊清單元素。在此情況下，具有系統管理員帳戶的使用者一律會以完整系統管理員許可權執行所有程式，因此這些程式會如預期般運作。不過，在 Windows Vista 或 Windows 7 上執行的 Windows XP 受限制使用者和標準使用者一律會以受限制的許可權執行這些程式，而且所有系統管理員層級作業都會失敗。因此，建議標示為「requiret管理員istrator」的程式在啟動時呼叫 IsUserAn管理員 ，並在傳回 FALSE 時顯示嚴重錯誤訊息。在上述大部分案例中，這一律會成功，但提供較佳的使用者體驗，並針對這個罕見的情況提供明確的錯誤訊息。

結論

身為以 Windows 多使用者環境為目標的遊戲開發人員，您必須設計遊戲以有效且負責任地運作。遊戲的主要可執行檔不應相依于系統管理許可權。這不僅可防止每次執行您的遊戲時出現提高許可權的提示，這可能會對整體使用者體驗造成負面影響，但也可讓您的遊戲利用其他需要以標準使用者許可權執行的功能，例如家長監護。

在舊版 Windows 下，適當設計為以標準使用者（或有限使用者）認證運作的應用程式，不會受到 UAC 的影響，它們會在沒有提高許可權的情況下執行。不過，它們應該包含資訊清單，其要求的執行層級設定為「asInvoker」，以符合 Vista 的應用程式標準。

深入閱讀

如需設計符合使用者帳戶控制規範之 Windows Vista 之應用程式的協助，請下載下列白皮書：使用者帳戶控制相容性的 Windows Vista 應用程式開發需求。

本白皮書提供設計程式的詳細步驟，以及程式碼範例、需求和最佳做法。本文也會詳細說明 Windows Vista 使用者體驗的技術更新和變更。

如需使用者帳戶控制的詳細資訊，請流覽 Windows Vista：Microsoft TechNet 上的使用者帳戶控制。

另一個實用的資源是 2007 年 1 月 MSDN Magazine 的「教您的應用程式使用 Windows Vista 使用者帳戶控制」一文。本文討論應用程式相容性的一般問題，以及在 Windows Vista 上使用 Windows Installer 套件的優點和問題。

如需 Bug 和 mt.exe 修正的詳細資訊，Visual Studio 2005 用來自動將資訊清單合併並內嵌至可執行檔的工具，請參閱在 MSDN 上的 Chris Jackson 部落格上探索 Windows Vista 中的預設命名空間和 UAC 資訊清單。

共用方式為