2025年趨勢QA三週年2｜從 40+ 個 Bug 中生存：誰動了我的 Handler？AMPPL整合與記憶體謎團實錄｜貢獻

當「存取拒絕」遇上「記憶體洩漏」，該如何撥雲見日？在 AMSP 與 AMPPL 的整合之路上，我與團隊經歷了三個月的 Bug 攻防戰。從百個 DLL 的認證地獄，到 ODS Only Mode 的邏輯衝突，我們在壓力測試中揪出隱藏的權限陷阱。本文不只分享如何修復 40+ 個Bug，更記錄了我們如何從失敗的 Handler Error 中尋獲關鍵暗示，將技術難題轉化為自動化監控與增量整合的工程實踐。準備好一起走進這場硬核的 Debug 現場了嗎？

快速文章連結：

  1. 2025年趨勢QA三週年1｜數十億美元的代價：BLP專案如何化危機為轉機？｜貢獻
  2. 2025年趨勢QA三週年2｜從 40+ 個 Bug 中生存：誰動了我的 Handler？AMPPL整合與記憶體謎團實錄｜貢獻


（二）AMPPL AMSP

AMPPL AMSP 專案啟動於 2025 年 Q4，歷經 10 月開發及 11、12 月的密集驗證。由於此專案涉及將微軟的 AMPPL 服務首度整合至 AMSP 產品中，複雜度極高。過程中我與RD協作修復了超過 40 個bug，涵蓋既有功能（AM/DC/AC）、AMPPL 新功能及效能優化，是我職涯中技術挑戰性最高的專案之一。

1. AMPPL 技術簡介

AMPPL 是由微軟 ELAM 驅動程式提供的保護機制。其核心功能在於防止關鍵程序被第三方程式強制終止，且僅允許載入具備微軟認證的 DLL 檔案。這能有效杜絕惡意程式碼注入與強化系統自我防禦能力。

2. 重點問題分析與解決

在開發與驗證過程中，我針對以下關鍵問題進行了深入追蹤與解決：

(1) DLL檔案認證問題

AMPPL AMSP只能載入有微軟認證的DLL檔案，以下理由說明這是一個非常繁瑣且重要的要求：

  1. 規模龐大： AMSP 包含106+ 個 DLL，任何一個未經認證皆會導致功能失效。
  2. 動態載入風險： DLL 採動態載入，手動測試難以全數覆蓋，必須仰賴自動化測試與結合 CodeIntegrity 事件監控來確保合規。
  3. 跨團隊協作： 需推動 16+ 個模組團隊同步升級至具備 LSHA2 + ACS 雙認證的版本。
  4. 精準認證策略： 
    1. 為避免覆蓋微軟既有認證導致錯誤，我們採取精確授權策略，而非全部對所有檔案進行雙認證。
    2. FIPS.dll只能使用ACS，無法使用LSHA2 ，所以必須要用New-FileCatalog去告訴Windows說，這個FIPS.dll是安全的。

(2) 複雜的初始化時序問題

開關 AMPPL、Self-protection與Security Update三者之間存在邏輯衝突。

  1. 開關AMPPL －＞ 會需要重啟AMSP
  2. AMSP的Self-protection  －＞ 會阻擋重啟AMSP
  3. 開關Self-protection時  －＞ 會觸發Security Update

初期曾出現重啟失敗或更新中斷等現象，最終透過將 AMPPL 置於初始化流程末端，並優化初始化邏輯，成功解決衝突問題。

(3) ELAM 驅動程式的健壯性

AMPPL 服務高度依賴 Windows ELAM 驅動程式，因此確保 ELAM 的存在與正常運作是啟用 AMPPL 的首要前提。為此，AMSP 實作了 ELAM 備份與救援機制，確保在各種極端情境下（如其他功能皆關閉時），ELAM 仍能正確載入以支撐 AMPPL 運行。下圖對話截圖是，在我的各種操作下，就抓到 ELAM 的bug。



在 2025 年 12 月驗證新功能「ODS Only Mode」時，我發現該模式為追求極簡化，並未載入支援自我保護（Self-protection）的模組，進而導致 ELAM 驅動程式無法載入，造成 AMSP 重啟失敗。透過對模組依賴關係的細緻觀察，我成功定位並排除了這項隱含的交互作用錯誤，確保了新舊功能的相容性。

(4) 記憶體效能優化與根因分析

由於本專案涉及 11 個模組的大規模升級，考量到效能調優的複雜度，我於專案中期便提前啟動效能評估，以避免後期修復成本過高。在長效測試 (Longevity Test) 中數據尚稱平穩，但在壓力測試 (Stress Test) 下，發現 AMSP 的 Working Set (WS) 異常飆升至常態的 3 倍，且伴隨每日約 100 MB 的記憶體洩漏現象。我立即回報研發團隊並啟動專案調查。

為釐清 AMPPL 對記憶體管理的影響，我們針對以下四個維度進行排查：

  1. 系統 Page-out 機制限制： 懷疑 AMPPL 的程序保護限制了系統換出記憶體的能力。經與同樣導入 AMPPL 的 A1 團隊交叉比對，確認該現象並非系統共性問題，排除此假說。
  2. 模組升級： 透過版本對比測試，確認在未升級模組的環境下問題依然存在，排除了新版模組導致的可能性。
  3. UMDH 日誌分析 (RTS/iCRC)： 分析顯示記憶體佔用前兩名為 RTS cache 與 iCRC 更新。經過兩週的追蹤測試，確認該記憶體隨後會正常釋放，僅為暫時性佔用而非真正的洩漏 (Leak)。
  4. 權限隔離導致機制失效（根因）： 最終鎖定 AMSP 與 DSA 間的權限問題。原設計中，DSA 會呼叫 ReduceAmspWorkingSet() 並透過 SetProcessWorkingSetSize() 清理 AMSP 的記憶體；然而在啟用 AMPPL 後，DSA 因權限不足無法取得 AMSP  handler，導致清理動作失效。

此次經驗顯示，在 AMPPL 的高安全性框架下，任何「存取拒絕 (Access Denied)」或「取得控制權失敗 (Handler Failure)」的錯誤訊息都不應被輕忽。初期若能對 ReduceAmspWorkingSet() 的錯誤提示與底層 API 功能進行深度關聯分析，將能大幅縮短排錯時程，這也成為未來處理權限變更類專案的重要參考指標。

(5) 跨區域協作與平台相容性

  • 跨團隊溝通： 在處理 AC（Application Control）功能異常時，克服了與北美團隊的時差與長假協作障礙，確保問題被有效追蹤。
  • V1ES 平台整合： 針對 V1ES 平台上設定值在重啟後被清空的疑慮，經與資深架構師討論，確認其為符合設計預期的 ResetPolicy 邏輯，並據此優化了部署流程。

(5) 跨功能影響驗證與協作挑戰 (DC/AC)

由於 AMPPL 具備系統級的保護效力，其影響範疇不限於 AM 功能，亦涵蓋 DC、AC 與 IM 等模組。為確保產品穩定性，我在每一版本交付時均執行詳盡的回歸測試。

12 月底，測試發現 AC 功能出現異常。我隨即聯繫位於加拿大的 AC 開發團隊請求支援，然適逢北美聖誕長假，導致溝通與修復進度受限。至 1 月底，該問題因環境變動導致難以復現，經評估後決定將此問題暫列掛起，待後續有更明確的跡證時再行重啟調查。

(6) V1ES 平台整合與設定問題

在專案後期，測試重點轉向新世代整合平台 V1ES。我們發現在 V1ES 環境下，AMPPL 的設定在派送至 DSA 後，若重啟 DSA，設定值會遭到清空。

起初懷疑此現象為程式bug，我們投入一週時間深入追蹤代碼邏輯，並與 UpdatePolicy() 的原作者探討為何會誤觸 ResetPolicy() 函數。最終在資深架構師的指引下，確認此設計在 V1ES 平台架構下屬於預期行為。在釐清設計原委後，迅速調整了設定保存的實作邏輯，成功解決此專案上線前的最後一項技術瓶頸。

3. 未來改進方向

基於 AMPPL AMSP 專案的執行經驗，針對未來類似的高複雜度整合專案，建議導入以下優化機制：

(1) 建立自動化認證檢測機制

  • 改善目標： 降低對人工測試與末端驗證的依賴，實現認證合規的「持續監測」。
  • 具體作法： 在 CI/CD 流程中加入腳本，於模組交付階段自動校驗 DLL 是否具備 LSHA2 + ACS 雙認證。同時，將 Windows CodeIntegrity 事件追蹤納入自動化測試判定準則，一旦偵測到認證錯誤即自動判定為 Fail。

(2) 效能測試左移與錯誤優先級定義

  • 改善目標： 提前識別由權限變更引發的隱性效能瓶頸。
  • 具體作法： 針對涉及 AMPPL 等高權限保護的功能，應在開發早期監控任何 Access Denied 或 Get Handler Failure 的錯誤。此類錯誤在 PPL 環境下往往是效能失效（如清理機制被阻斷）的先兆，應優先提升處理權級。

(3) 導入模組分階段整合策略

  • 改善目標： 控制測試變因，避免多模組同時升級導致的問題定位困境。
  • 具體作法： 推動 RD 採行「增量整合」，QA 仍應在測試環境中分批次更換 1-2 個核心模組進行初步驗證，確認基本功能穩定後再進行全數合併。

(4) 強化跨時區協作與資源風險管理

  • 改善目標： 降低外部不可控因素（如假期、時差）對專案進度的衝擊。
  • 具體作法： 在專案啟動階段即將「全球團隊資源可用性」納入風險評估。針對北美或歐洲團隊的長假季（如 12 月聖誕假期），應將關鍵整合測試排程提前至 11 月底，以確保技術支援不中斷。

(5) 應用狀態機 (State Machine) 驗證時序邏輯

  • 改善目標： 徹底解決 AMPPL、自我保護與安全更新之間的初始化衝突。
  • 具體作法： 建議於設計階段定義 AMSP 的狀態機模型，明確界定各服務在不同狀態下的運作權限。這有助於在開發初期與研發團隊達成共識，確立正確的「初始化優先權」與時序邏輯。


縮寫名詞解釋

  1. A1 (Apex One)：友隊維護的端點防毒產品
  2. AC (Application Control)：控制哪些應用程式可在端點上執行
  3. AM (Anti-Malware)：偵測並阻擋惡意軟體的功能模組
  4. AMPPL (Anti-Malware Protected Processes Light)：Windows 機制，以 PPL 等級保護防毒程序不被惡意程式終止
  5. AMSP (Anti-Malware Solution Platform)：Trend Micro 內部防毒核心平台，供各產品共用掃描引擎與元件
  6. BLP (BSoD Loop Prevention)：防止系統因驅動問題陷入藍屏重開機無限迴圈的保護機制
  7. DC (Device Control)：管控 USB 等外接裝置的存取權限
  8. DLL (Dynamic Link Library)：Windows 動態連結函式庫，供多個程序共用程式碼與資源
  9. DSA (Deep Security Agent)：我們團隊維護的端點防護代理程式
  10. ELAM (Early Launch Anti-Malware)：Windows 啟動早期載入的防毒驅動，確保開機時最先接管掃描
  11. IM (Integrity Monitoring)：監控系統檔案、登錄等是否遭未授權竄改
  12. QA (Quality Assurance)：負責驗證產品品質、執行測試的工作
  13. RCA (Root Cause Analysis)：針對問題或事故追查根本原因的分析流程
  14. RD (Research and Development)：負責產品研究與功能開發的工作
  15. RTS (Real Time Scan)：即時監控檔案存取並即時掃描的功能
  16. UMDH (User-Mode Dump Heap)：Microsoft 提供的工具，用於分析使用者模式程序的堆積記憶體洩漏
  17. V1 (Vision One)：Trend Micro 的資安營運平台，整合各端點與雲端的威脅可視性

參考資料

留言

張貼留言