Windows 應用程式認證套件測試

以下是認證傳統型應用程式的測試詳細數據。 如需詳細資訊，請參閱 使用 Windows 應用程式認證套件。

• 清除可逆安裝
• 安裝至正確的資料夾測試
• 數字簽署的檔案測試
• 支援 x64 Windows 測試
• OS 版本檢查測試
• 用戶帳戶控制 （UAC） 測試
• 遵守系統重新啟動管理員訊息
• 保管庫 模式測試
• 多用戶會話測試
• 當機和停止響應測試
• 相容性和復原測試
• Windows 安全性 最佳做法測試
• Windows 安全性 功能測試
• 高 DPI 測試

清除可逆安裝

安裝並卸載應用程式，並檢查剩餘的檔案和登錄專案。

• 背景
  • 全新且可逆的安裝可讓使用者部署和移除應用程式。 若要通過這項測試，應用程式必須執行下列動作：
    • 應用程式不會強制系統在安裝或卸載應用程式之後立即重新啟動。 應用程式安裝或卸載程序絕對不需要在系統完成之後重新啟動。 如果這需要重新啟動系統，用戶應該能夠在方便時重新啟動系統。
    • 應用程式不相依於 8.3 簡短檔名 （SFN）。 應用程式的安裝和卸載程式必須能夠使用長檔名和資料夾路徑。
    • 應用程式不會封鎖無訊息安裝/卸載
    • 應用程式會在系統登錄中建立必要的專案。 Windows 清查工具和遙測工具需要已安裝應用程式的完整資訊。 應用程式安裝程式必須建立正確的登錄專案，才能成功偵測和卸載。
  • 如果您使用 MSI 型安裝程式，MSI 會自動建立下列登錄專案。 如果您不是使用 MSI 安裝程式，安裝模組必須在安裝期間建立下列登入專案：
    • DisplayName
    • InstallLocation
    • 發行者
    • UninstallString
    • VersionMajor 或 MajorVersion
    • VersionMinor 或 MinorVersion
  • 應用程式必須在 [新增/移除程式] 中移除其所有專案。
• 測試詳細數據
  • 此測試會檢查應用程式的安裝和卸載程式是否有必要的行為。
• 更正動作
  • 根據上述需求檢閱應用程式的設計和行為。

安裝至正確的資料夾測試

驗證應用程式是否將其程式和數據檔寫入正確的資料夾。

• 背景
  • 應用程式必須正確使用用戶系統和每個使用者資料夾，才能存取所需的數據和設定，同時保護使用者的數據和設定免於未經授權的存取。
• Program Files 資料夾
  • 應用程式預設必須安裝在 Program Files 資料夾中（%ProgramFiles% 適用於原生 32 位和 64 位應用程式，以及執行 x64 之 32 位應用程式的 %ProgramFiles（x86）%。
  • 注意： 應用程式不得將用戶資料或應用程式資料儲存在 Program Files 資料夾中，因為為此資料夾設定的安全性許可權。
  • Windows 系統資料夾中的 ACL 只允許系統管理員帳戶讀取和寫入它們。 因此，標準使用者帳戶將無法存取這些資料夾。 不過，檔案虛擬化可讓應用程式將檔案，例如組態檔儲存在通常只能由系統管理員寫入的系統位置。 在此情況下，以標準使用者身分執行程式可能會導致失敗，如果他們無法存取必要的檔案。
  • 應用程式應該使用 已知資料夾 ，以確保他們能夠存取其數據。
  • 注意： Windows 提供檔案虛擬化來改善應用程式相容性，並在 Windows 上以標準使用者身分執行應用程式時消除問題。 您的應用程式不應依賴未來版本的 Windows 中存在的虛擬化。
• 使用者特定的應用程式資料資料資料夾
  • 在「每部計算機」安裝中，應用程式在安裝期間不得寫入使用者特定數據。 只有在使用者第一次啟動應用程式時，才應該寫入使用者特定的安裝數據。 這是因為安裝時沒有正確的使用者位置可儲存數據。 在安裝之後，應用程式嘗試修改計算機層級的默認關聯行為將會失敗。 相反地，每個用戶層級上必須宣告預設值，以防止多個使用者覆寫彼此的預設值。
  • 特定使用者專屬的所有應用程式數據，且不得與計算機的其他用戶共用，都必須儲存在Users\<username>\AppData 中。
  • 計算機上用戶之間必須共用的所有應用程式數據都應該儲存在 ProgramData 內。
• 其他系統資料夾和登錄機碼
  • 應用程式絕對不應該直接寫入 Windows 目錄或子目錄。 使用這些目錄安裝檔案的正確方法，例如字型或驅動程式。
  • 應用程式不應該在啟動時自動啟動，例如將專案新增至其中一或多個位置：
    • 登錄會在Software\Microsoft\Windows\CurrentVersion 下執行機碼 HKLM 和 或 HKCU
    • 登錄會在 Software\Wow6432Node\Microsoft\windows\CurrentVersion 下執行機碼 HKLM 和 或 HKCU
    • \[開始\] 功能表 \[所有專案\] \[啟動\ > ]
• 測試詳細數據
  • 此測試會驗證應用程式使用 Windows 提供的特定檔案系統位置來儲存程式與軟體元件、共用應用程式數據和使用者專屬的應用程式數據。
• 更正動作
  • 檢閱應用程式如何使用系統的資料夾，並確定其正確使用。
• 例外狀況和豁免
  • 寫入全域程式集緩存 （GAC） 的桌面應用程式需要豁免權（.NET 應用程式應將元件相依性保留為私用，並儲存在應用程式的目錄中，除非明確需要共用元件）。
  • 安裝至 [程序檔案] 資料夾不需要桌面 SW 套件才能達到 SW 標誌，而僅限於 SW 基本概念類別之下。

數位簽署的檔案測試

測試可執行檔和設備驅動器，以確認它們具有有效的數位簽名。

• 背景
  • 數字簽署的檔案可讓您確認檔案是否為正版，並偵測檔案是否已遭到竄改。
  • 內核模式程式代碼簽署強制執行是一項 Windows 功能，也稱為程式代碼完整性（CI）。 CI 會在每次將檔案載入記憶體時驗證檔案的完整性，藉以改善 Windows 的安全性。 CI 會偵測惡意代碼是否已修改系統二進位檔，並在核心模塊簽章無法正確驗證時產生診斷和系統稽核記錄事件。
  • 如果應用程式需要提高的許可權，提高許可權提示會顯示要求提高存取權之可執行檔的相關內容資訊。 視應用程式是否已簽署 Authenticode 而定，使用者可能會看到同意提示或認證提示。
  • 強名稱可防止第三方詐騙您的程序代碼，只要您保持私鑰的安全。 .NET Framework 會在載入元件或安裝 GAC 時驗證數位簽名。 若無法存取私鑰，惡意使用者就無法修改您的程式代碼，並再次簽署。
• 測試詳細數據
  • 所有可執行檔，例如擴展名為 .exe、.dll、.ocx、.sys、.cpl、.drv 和 .scr 的可執行檔，都必須使用 Authenticode 憑證簽署。
  • 應用程式安裝的所有核心模式驅動程式都必須透過 WHQL 或 DRS 程式取得 Microsoft 簽章。 所有文件系統篩選驅動程式都必須經過 WHQL 簽署。
• 更正動作
  • 簽署應用程式的可執行檔。
  • 使用makecert.exe 從其中一個商業證書頒發機構單位 （CA） 產生憑證或取得程式代碼簽署密鑰，例如 VeriSign、Thawte 或 Microsoft CA。
• 例外狀況和豁免
  • 豁免只會被視為未經簽署的第三方可轉散發套件。 要求簽署版本的可轉散發套件的通訊證明必須獲得此豁免。
  • 裝置增值的軟體套件不受核心模式驅動程式認證，因為驅動程式必須經過Windows 硬體認證認證。

支援 x64 Windows 測試

測試應用程式，以確定 .exe 是針對其安裝所在的平台架構所建置。

• 背景
  • 可執行文件必須針對安裝可執行檔的處理器架構建置。 某些可執行檔可能會在不同的處理器架構上執行，但這並不可靠。
  • 架構相容性很重要，因為 32 位進程無法載入 64 位 DLL，而 64 位進程無法載入 32 位 DLL。 同樣地，64 位版本的 Windows 不支援執行 16 位 Windows 應用程式，因為句柄在 64 位 Windows 上有 32 個顯著位，因此無法傳遞至 16 位應用程式。 因此，嘗試在64位版本的Windows上啟動16位應用程式將會失敗。
  • 32 位設備驅動器無法在64位版本的 Windows 上執行，因此，它們必須移植到64位架構。
  • 對於使用者模式應用程式，64 位 Windows 包含 WOW64，可讓 32 位 Windows 應用程式在執行 64 位 Windows 的系統上執行，儘管效能遺失。 設備驅動器沒有對等的翻譯層。
  • 若要維持與64位版本的Windows相容性，應用程式必須原生支援64位，或至少32位 Windows 應用程式必須在64位系統上順暢執行：
    • 應用程式及其安裝程式不得包含任何16位程式代碼，或依賴任何16位元件。
    • 應用程式安裝必須在64位版本的Windows上偵測並安裝適當的驅動程式和元件。
    • 任何殼層外掛程式都必須在64位版本的 Windows 上執行。
    • 在 WoW64 模擬器下執行的應用程式不應該嘗試略過 Wow64 虛擬化機制。 如果有特定案例需要偵測應用程式是否在 WoW64 模擬器中執行，則應該呼叫 IsWow64Process 來執行此動作。
• 測試詳細數據
  • 應用程式不應該安裝任何16位二進位檔。 如果應用程式應該在64位電腦上執行，則不應該安裝32位核心模式驅動程式。
• 更正動作
  • 建置您要安裝之處理器架構的可執行檔和驅動程式。

OS 版本檢查測試

測試應用程式如何檢查其執行所在的 Windows 版本。

• 背景
  • 應用程式會測試大於或等於所需版本的版本，以確保與未來的 Windows 版本相容，以檢查操作系統版本。
• 測試詳細數據
  • 模擬在不同的 Windows 版本上執行應用程式，以查看其回應方式。
• 更正動作
  • 測試目前版本是否大於或等於您的應用程式、服務或驅動程式所需的版本，以測試正確的 Windows 版本。
  • 驅動程式安裝程式和卸載模組絕對不能檢查 OS 版本。
• 例外狀況和豁免
  • 符合下列準則 的應用程式將考慮豁免：（僅適用於傳統型應用程式認證）
    • 傳遞為在 Windows XP、Windows Vista 和 Windows 7 上執行之套件的應用程式，且需要檢查作業系統版本，以判斷要安裝在指定操作系統上的元件。
    • 僅使用已核准的 API 呼叫，並視需要在應用程式指令清單中列出最低版本需求，只檢查作業系統的最低版本版本的應用程式（僅在安裝期間，而非在運行時間期間）。
    • 安全性應用程式，例如防毒和防火牆應用程式、重組公用程式、備份應用程式等系統公用程式，以及僅使用已核准的 API 呼叫來檢查 OS 版本的診斷工具。

使用者帳戶控制 (UAC) 測試

測試應用程式，以確認它不需要不必要的提高許可權才能執行。

• 背景
  • 只有當使用者是系統管理員強制使用者使用不必要許可權執行應用程式時，才會操作或安裝的應用程式，這可讓惡意代碼進入用戶的計算機。
  • 當使用者一律強制使用提升許可權的存取令牌執行應用程式時，應用程式可以伺服器做為欺騙性或惡意代碼的進入點。 此惡意代碼可以輕鬆地修改操作系統，或更糟地影響其他使用者。 幾乎無法控制具有完整系統管理員存取權的使用者，因為 管理員 istrators 可以安裝應用程式，並在計算機上執行任何應用程式或腳本。 IT 管理員一律會尋求建立「標準桌面」的方法，讓使用者以標準使用者身分登入。 標準桌面可大幅降低技術支援中心成本，並減少IT額外負荷。
  • 大部分的應用程式在運行時間不需要系統管理員許可權。 標準用戶帳戶應該能夠執行它們。 Windows 應用程式必須有指令清單（內嵌或外部），才能定義其執行層級，告知 OS 執行應用程式所需的許可權。 應用程式指令清單僅適用於 .exe 檔案，不適用於 .dll 檔案。 用戶帳戶控制 （UAC） 不會在建立程式期間檢查 DLL。 UAC 規則不適用於 Microsoft 服務。 應用程式指令清單可以內嵌或外部。
  • 若要建立指令清單，請建立名稱 <為 app_name.exe.manifest> 的檔案，並將它儲存在與 EXE 相同的目錄中。 請注意，如果應用程式有內部指令清單，則會忽略任何外部指令清單。
    • 例如，<requestedExecutionLevel level=“”asInvoker | highestAvailable | require 管理員 istrator“” uiAccess=“”true|false“”/>
    • 應用程式的主要程序必須以標準使用者身分執行（asInvoker）。 任何系統管理功能都必須移至使用系統管理許可權執行的個別程式。
    • 需要提高許可權的使用者面向應用程式必須經過 Authenticode 簽署。
• 測試詳細數據
  • 所有使用者面向 exes 都應該標示為 AsInvoker 屬性。 如果它們標示為 highestAvailable 或 require 管理員 istrator，則應該正確簽署 authenticode。 任何應用程式 exe 不應該將 uiAccess 屬性設定為 true。 以服務身分執行的任何 exe 都會從這個特定檢查中排除。
• 更正動作
  • 檢閱應用程式的指令清單檔，以取得正確的專案和許可權等級。
• 例外狀況和豁免
  • 執行其主要程式且具有較高許可權的應用程式需要豁免（需要 管理員 istrator 或 highestAvailable）。 主要進程是提供使用者進入點至應用程式的程式。
  • 下列案例將考慮豁免：
    • 管理員 執行層級設定為 highestAvailable 的系統工具、需要 管理員 istrator 或兩者。
    • 只有輔助功能或UI自動化架構應用程式會將UIAccess旗標設定為TRUE，以略過使用者介面許可權隔離 （UIPI）。 若要正確啟動應用程式使用率，此旗標必須經過 Authenticode 簽署，而且必須位於文件系統中的受保護位置，例如 Program Files。

遵守系統重新啟動管理員訊息

測試應用程式回應系統關機和重新啟動訊息的方式。

• 背景
  • 當應用程式收到通知時，應用程式必須儘快結束，系統正在關閉，以提供回應式關機或電源關閉體驗給使用者。
  • 在重大關機中，傳回 FALSE 至 WM_QUERYENDSESSION 的應用程式將會傳送 WM_ENDSESSION 並關閉，而回應WM_QUERYENDSESSION的逾時應用程式將強制終止。
• 測試詳細數據
  • 檢查應用程式如何回應關閉和結束訊息。
• 更正動作
  • 如果您的應用程式未透過此測試，請檢閱它如何處理這些 Windows 訊息：
    • WM_QUERYENDSESSION與 LPARAM = ENDSESSION_CLOSEAPP（0x1）：傳統型應用程式必須立即回應（TRUE），以準備重新啟動。 控制台應用程式可以呼叫 SetConsoleCtrlHandler 以接收關機通知。 服務可以呼叫 RegisterServiceCtrlHandlerEx ，以在處理程式例程中接收關機通知。
    • WM_ENDSESSION LPARAM = ENDSESSION_CLOSEAPP（0x1）：應用程式必須在 30 秒內傳回 0 值並關閉。 應用程式至少應該藉由儲存任何用戶數據來準備，並指出重新啟動後所需的資訊。
  • 接收CTRL_C_EVENT通知的主控台應用程式應立即關閉。 驅動程式不得否決系統關機事件。
  • 注意： 由於無法中斷的作業而必須封鎖關機的應用程式應該使用 ShutdownBlockReasonCreate 來註冊說明使用者原因的字串。 作業完成時，應用程式應該呼叫 ShutdownBlockReasonDestroy 來指出系統可以關閉。

保管庫 模式測試

測試驅動程式或服務是否已設定為以安全模式啟動。

• 背景
  • 保管庫 模式可讓用戶診斷和疑難解答 Windows 的問題。 只有操作系統基本作業所需的驅動程式和服務，或提供診斷和復原服務應該以安全模式載入。 以安全模式載入其他檔案時，較難針對操作系統的問題進行疑難解答。
  • 根據預設，只有預安裝 Windows 的驅動程式和服務會以安全模式啟動。 除非系統要求它們進行基本作業或診斷和復原，否則應該停用所有其他驅動程式和服務。
• 測試詳細數據
  • 應用程式安裝的驅動程式不應標示為以安全模式載入。
• 更正動作
  • 如果驅動程式或服務不應該以安全模式啟動，請從登錄機碼中移除應用程式的專案。
• 例外狀況和豁免
  • 必須以安全模式啟動的司機和服務需要豁免才能通過認證。 豁免要求必須包含每個驅動程式和服務，以新增至 保管庫 Boot 登錄機碼，並描述驅動程式或服務必須以安全模式執行的技術原因。 應用程式安裝程式必須在下列登錄機碼中註冊所有這類驅動程式和服務：
    • HKLM/System/CurrentControlSet/Control/保管庫 Boot/Minimal
    • HKLM/System/CurrentControlSet/Control/保管庫 Boot/Network
• 注意： 您必須測試您想要以安全模式啟動的驅動程式和服務，以確保它們以安全模式運作，而不會發生任何錯誤。

多用戶會話測試

測試應用程式在多個會話中同時執行時的行為。

• 背景
  • Windows 用戶必須能夠執行並行會話。 應用程式必須確保在本機或遠端多個會話中執行時，應用程式的一般功能不會受到負面影響。 應用程式設定和數據文件必須是使用者特定的，而且使用者的隱私權和喜好設定必須限制為使用者的會話。
• 測試詳細數據
  • 執行應用程式的多個並行實例，以測試下列專案：
    • 同時執行的多個應用程式實例會彼此隔離。
  • 這表示另一個實例看不到某個實例的用戶數據。 作用中用戶會話中的音效不應該在作用中用戶會話中聽到。 如果多個應用程式實例使用共用資源，應用程式必須確定沒有衝突。
    • 如果為多個使用者安裝應用程式，它會將資料儲存在正確的資料夾和登錄位置。
    • 應用程式可以在多個用戶會話中執行（快速使用者切換），以進行本機和遠端訪問。
  • 為了確保這一點，應用程式必須檢查應用程式現有實例的其他終端服務 （TS） 工作階段。 如果應用程式不支援多個使用者會話或遠端訪問，則從這類會話啟動時，它必須明確地對使用者說出這一點。
• 更正動作
  • 請確定應用程式不會將全系統數據檔或設定儲存在使用者特定資料存放區中，例如使用者配置檔或 HKCU。 如果這樣做，該資訊將無法供其他使用者使用。
  • 您的應用程式必須在安裝期間安裝全系統組態和數據檔，並在使用者執行時建立使用者特定的檔案和設定。
  • 請確定應用程式不會在本機或遠端封鎖多個並行會話。 應用程式不得相依於全域 Mutex 或其他具名物件，以檢查或封鎖多個並行會話。
  • 如果應用程式不允許每個使用者有多個並行會話，請針對 Mutex 和其他具名物件使用個別使用者或每個會話命名空間。

當機和停止響應測試

在認證測試期間監視應用程式，記錄該應用程式何時發生當機或停止回應情形。

• 背景
  • 應用程式失敗，例如當機和停止回應，對使用者造成重大中斷，並造成挫折。 消除這類失敗可改善應用程式穩定性和可靠性，而且整體而言，為使用者提供更好的應用程序體驗。 停止回應或當機的應用程式會導致使用者遺失資料並產生不良的使用經驗。
• 測試詳細數據
  • 我們會透過認證測試來測試應用程式的復原能力和穩定性。
  • Windows 應用程式認證套件會呼叫 IApplicationActivationManager：：ActivateApplication 來啟動 Windows 市集 應用程式。 為了讓 ActivateApplication 啟動應用程式，必須啟用使用者帳戶控制 (UAC)，而且螢幕解析度至少必須為 1024 x 768 或 768 x 1024。 如果任一條件不符合，您的應用程式就無法通過此測試。
• 更正動作
  • 請確定測試電腦上的 UAC 已啟用。
  • 請確定您在螢幕夠大的電腦上執行測試。
  • 如果您的應用程式無法啟動，但測試平台符合 ActivateApplication 的先決條件，則可以檢閱啟用事件記錄檔以疑難排解問題。 若要在事件記錄檔中尋找這些專案：
    1. 開啟 eventvwr.exe 並流覽至 \Windows Logs\Application 節點。
    2. 篩選檢視，以顯示事件識別碼：5900-6000。
    3. 查閱記錄項目，尋找說明為什麼應用程式無法啟動的資訊。
  • 針對有問題的檔案進行疑難排解，找出並修正問題。 或是重建並重新測試應用程式。
• 其他資源
  • 在您的軟體開發生命週期內使用應用程式驗證器
  • 應用程式驗證器
  • 使用應用程式驗證器
  • AppInit DLL
  • 最小化啟動時間 （使用 C#/VB/C++ 和 XAML 的 Windows 市集應用程式）

相容性和復原測試

• 背景
  • 這項檢查會驗證應用程式的兩個層面：應用程式主要可執行檔（s）例如，使用者面向的應用程式進入點必須以指令清單來表示相容性，以及宣告正確的 GUID。 為了支援這項新的測試，報表會在 [相容性與復原能力] 下有一個子節點。 如果遺漏其中一個或兩個條件，應用程式將會失敗。
• 測試詳細數據
  • 相容性： 應用程式必須完全正常運作，而不需使用 Windows 相容性模式、AppHelp 訊息或其他相容性修正。 相容性指令清單可讓 Windows 在不同作業系統版本下提供適當的相容性行為
  • AppInit： 應用程式不得列出 DLL 以載入HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs登錄機碼。
  • Switchback： 應用程式必須提供切換回指令清單。 如果指令清單遺失，Windows 應用程式認證套件會提供警告訊息。 Windows 應用程式認證套件也會驗證指令清單包含有效的 OS GUID。
• 更正動作
  • 修正使用相容性修正的應用程式元件。
  • 請確定應用程式不會依賴其功能的相容性修正。
  • 請確定您的應用程式已顯示，且相容性區段包含適當的值
• 其他資訊
  • 如需詳細資訊，請參閱 AppInit DLL 。

Windows 安全性 最佳做法測試

• 背景
  • 應用程式不應該變更預設的 Windows 安全性設定
• 測試詳細數據
  • 執行攻擊 Surface 分析器來測試應用程式的安全性。 此方法會根據每個測試新增失敗類別。 例如，安全性測試的某些類別可能包括：
    • 初始化失敗
    • 安全性架構失敗
    • 可能的緩衝區溢位失敗
    • 當機失敗
  • 如需詳細資訊，請參閱 這裡。
• 更正動作
  • 針對測試所識別的問題進行疑難解答並修正。 或是重建並重新測試應用程式。

Windows 安全性功能測試

• 背景
  • 應用程式必須加入加入 Windows 安全性功能。 變更預設的 Windows 安全性保護會讓客戶面臨較高的風險。
• 測試詳細數據
  • 執行 BinScope 二進制分析器以測試應用程式的安全性。 如需詳細資訊，請參閱 這裡。
• 更正動作
  • 針對測試所識別的問題進行疑難解答並修正。 或是重建並重新測試應用程式。

高 DPI 測試

強烈建議 Win32 應用程式感知 DPI。 讓應用程式 UI 在各種不同的高 DPI 顯示設定中看起來一致良好是關鍵。 在高 DPI 顯示設定上執行的非 DPI 感知應用程式可能會有問題，例如 UI 元素的調整不正確、裁剪的文字和模糊影像。 有兩種方式可以宣告應用程式是 DPI 感知。 其中一個是宣告 DPI。

• 背景
  • 這項檢查會驗證應用程式的兩個層面，主要可執行檔，例如，使用者面向的應用程式進入點必須以高 DPI 感知來顯示，而且呼叫適當的 API 以支援 HIGH-DPI。 如果遺漏其中一個或兩個條件，應用程式將會失敗。 這項檢查會在桌面報表中引進新的區段，請參閱下列範例。
• 測試詳細數據
  • 當我們偵測到下列任一項時，測試會產生警告：
    • 主要 EXE 不會在其指令清單中宣告 DPI 感知，也不會呼叫 SetProcessDPIAware API。 （如果他忘記新增 DPI 感知指令清單，請警告開發人員）。
    • 主要 EXE 不會在其指令清單中宣告 DPI 感知，但它會呼叫 SetProcessDPIAware API（警告開發人員，他應該使用指令清單來宣告 DPI 感知，而不是呼叫 API）。
    • mainEXE 在其指令清單中宣告 DPI 感知，但它也會呼叫 SetProcessDPIAware API（警告開發人員呼叫該 API 並非必要）。
    • 對於不是主要EXE的二進制檔，如果他們呼叫 API，請發出警告（不建議呼叫 API）。
• 更正動作
  • 不建議使用 SetProcessDPIAware（） 函式。 如果 DLL 在初始化期間快取 DPI 設定，在應用程式中叫用 SetProcessDPIAware（） 可能會產生競爭條件。 在 DLL 中呼叫 SetProcessDPIAware（） 函式不是很好的做法。
• 其他資訊
  • 撰寫高 DPI 應用程式