自行開發的 Windows 應用程式被當成病毒處理時 ── Microsoft Defender 誤判的因應方式,以及與效能影響的相處之道

「客戶端上,我們的應用程式被當成病毒刪除了」── 只要持續發佈自行開發、受託開發的 Windows 應用程式,遲早會接到這樣的聯絡。昨天為止都正常運作的業務應用程式,因為 Defender 定義更新而突然被隔離。開發機上什麼事都沒發生,卻只在客戶環境中被偵測到。明明沒有寫過任何惡意程式碼。

這不是罕見的意外。現代的防毒軟體不只判斷「是否與已知的惡意程式一致」,還會透過機器學習、行為分析、雲端上的信譽(reputation)來推測「可疑程度」,因此沒有實績的正規二進位檔案被懷疑,是機制上無法避免的事。而對於誤判的因應,可以做的事(向 Microsoft 回報誤判、有限度的排除設定)與不該做的事(停用防毒功能、大範圍排除),有清楚的區分。

本文將以開發者的角度,整理誤判發生的機制、發佈前可以做的預防、被偵測到時的正規因應途徑、在客戶環境中作為應急處理的排除設定與其風險,以及另一個常見諮詢「Defender(MsMpEng.exe)很吃資源」的因應方式。

由於文章很長,先依情境列出切入點。正在處理客戶問題、想馬上採取行動的資訊系統・支援人員,請從第 4 章(正規因應途徑)與第 5 章(排除設定的做法與風險)開始,想在發佈應用程式前預防誤判的開發者,請從第 3 章開始,正在處理「Defender 很吃資源」諮詢的人,請從第 6 章開始閱讀。依症狀分類的速查表在第 7 章。

1. 先講結論

• 就算是正規的應用程式,也可能發生誤判。自 2015 年起,Defender 已從以靜態特徵碼為主的引擎,轉移到使用機器學習與雲端保護的預測型模型,未知檔案即使不符合已知的惡意特徵,也會依「可疑程度」被判定。¹²
• 恆久因應的正規途徑,是向 Microsoft 提交檔案申請(誤判回報)。從 Microsoft Security Intelligence 的樣本申請入口網站,以開發者身分提交,並追蹤判定結果。若對判定結果有異議,可透過開發者專用聯絡表單要求重新調查。³⁴
• 被隔離的檔案可以還原。可從 Windows 安全性中心的「保護記錄」,或以命令列的 MpCmdRun.exe -Restore 還原。⁵
• 排除設定是「在回報結果出爐前的暫時因應」。排除會造成保護上的漏洞(protection gap),Microsoft 明確指出應「謹慎使用」、「只用於特定問題」、「定期檢視」。若要設定,應以完整路徑指定最小範圍,並留下記錄。⁶
• 預防的核心是持續一致的程式碼簽章。Microsoft 並沒有提供誤判防止的事前登記計畫,官方指引的方法是持續使用受信任根憑證授權單位核發的憑證簽署,這能加快來源的確認與加入已知清單的速度。⁴
• 發佈前自行掃描與事先送審,可以減少「零實績」的情況。可用 MpCmdRun.exe 的自訂掃描檢查發佈物,而 Microsoft 官方也指出,事先將未知檔案送審有助於開始建立信譽(reputation)。⁷⁸
• 「Defender 很吃資源」要先從量測著手。先用 Performance analyzer(New-MpPerformanceRecording / Get-MpPerformanceReport)找出哪個檔案・行程是掃描負擔的核心,再考慮對策。排除設定在這裡同樣是最後手段。⁹¹⁰

2. 為什麼正規的應用程式會被當成病毒處理

如果仍停留在「防毒軟體 = 比對已知病毒的特徵碼(pattern)」這種理解,誤判就會顯得難以理解。但現代的 Defender 並非如此。Microsoft 明確指出,自 2015 年起已從以靜態特徵碼為基礎的引擎,轉移到使用機器學習、應用科學、AI 等預測技術的模型。¹

偵測是以多層方式進行的。裝置端會執行輕量的機器學習模型、行為分析與啟發式(heuristic)判定;若光靠裝置端無法判斷黑白,檔案的中繼資料就會被送到雲端保護服務,多數情況下能在毫秒等級內得到判定結果。若仍無法判定,系統會要求提交檔案樣本,交由雲端進行掃描、引爆分析(detonation,在隔離環境中執行)與大數據分析。在啟用「block at first sight(初次偵測即封鎖)」的環境中,甚至會在雲端判定結果出爐前,暫時保留檔案的開啟動作。²¹¹

這套機制的含意很明確:判定的依據不只是「與惡意程式相符」,也包含「無害的實績」。Microsoft 的分類標準中明確列出了「Unknown(無法識別的軟體)」這個類別,對於未知或下載次數少的程式所發出的警告,被定位為「尚未被偵測到的惡意程式的早期預警系統」。官方的整理是:並非所有罕見的程式都是惡意的,但對一般使用者而言,未知類別本身的風險偏高。⁸

換句話說,剛發佈的自家應用程式,從 Windows 的安全機制來看,就是「世界上還沒有人執行過、零實績的二進位檔案」。若再疊加以下特徵,懷疑就會加深。

• 隱藏程式碼實體的結構。Microsoft 的惡意程式分類中有一種稱為「Obfuscator(混淆處理)」的類型,指隱藏程式碼與目的以增加偵測難度的軟體;而積極規避安全產品偵測的軟體,也被歸類為不需要的應用程式(PUA)之一。混淆處理工具、自解壓縮格式,以及將執行環境(runtime)一併封裝進單一 exe 的封裝方式,在外觀結構上與惡意程式常用的手法難以區分,即使是正規應用程式,也容易落入容易被警戒的範圍。⁸
• 沒有簽章、無法追溯來源的線索。如下一章所述,持續一致的簽章是調查方確認來源的主要線索。⁴
• 安裝程式中同捆了其他軟體。建議安裝並非同一開發商、或運作上不需要的軟體,會被歸類為「Bundling software」,屬於 PUA 分類的對象。⁸

另外,下載完成後立刻出現的「Windows 已保護您的電腦」藍色警告,是與 Defender 防毒偵測不同的機制(Microsoft Defender SmartScreen)。Microsoft 的開發者 FAQ 中也明確指出,SmartScreen 與 Defender 防毒是彼此獨立的。⁴ 關於 SmartScreen 與信譽的詳細說明,可參閱「Windows 為什麼會出現「Windows 已保護您的電腦」」,請先釐清自己遇到的是哪一種警告。

3. 發佈前可以做的預防

3.1. 持續一致的程式碼簽章 ── 不存在事前登記計畫

「為了不被誤判,能不能事先登記到 Microsoft 的白名單裡」是很自然的想法,但答案是不行。Microsoft 並不接受開發者申請加入已知清單登記或誤判防止計畫。官方 FAQ 提供的替代方案是:持續以受信任根憑證授權單位核發的憑證,為程式的檔案群組進行一致的簽署。據稱,持續一致的簽章能讓調查團隊迅速確認程式的來源並套用過去的知識,結果可能加快程式加入已知清單的速度;雖然頻率較低,但憑證本身有時也會被列入受信任發行者清單。⁴

換個角度說,簽章的效果在於把「以檔案為單位的實績」統整成「以發行者為單位的實績」。每次建置雜湊值都會改變的執行檔,若以檔案為單位來看,每次都是「第一次見到的檔案」,但只要用同一張憑證簽署,來源就能夠連續累積。簽章的實務細節(憑證種類、Azure Artifact Signing、時間戳記)請參閱前述的 SmartScreen 文章,以及「Windows 應用程式開發中遵守最低限度安全性的檢核表」。

3.2. 發佈前自行掃描

與其發佈後才在客戶環境中被偵測到,不如把自己的建置成果物掃描一遍,納入發行判定的一部分,成本要低得多。Defender 提供命令列工具 MpCmdRun.exe,可以用在腳本或排程工作中自動化執行。由於預設不在 PATH 中,執行前需先切換到 %ProgramData%\Microsoft\Windows Defender\Platform\<版本>(若沒有的話則是 %ProgramFiles%\Windows Defender)。⁷

rem 以系統管理員權限的命令提示字元執行
cd /d "C:\ProgramData\Microsoft\Windows Defender\Platform\<最新版本的資料夾>"

rem 對發行資料夾進行自訂掃描(-ScanType 3)
rem -DisableRemediation: 即使偵測到也不進行隔離等處置,只將結果顯示於命令輸出
MpCmdRun.exe -Scan -ScanType 3 -File "C:\Release\MyApp" -DisableRemediation

傳回值定義了 0 與 2,但作為關卡條件使用時容易忽略的一點是:0 不只代表「未偵測到」,也包含「偵測到但已修復成功」。若直接使用純粹的 -Scan,可能發生 Defender 偵測到發行成果物並完成隔離,傳回值卻是 0、被視為「乾淨」而通過流水線的最糟情況。自訂掃描時請加上 -DisableRemediation,設定為偵測時不執行處置(偵測結果會顯示在命令輸出中);除了「傳回 2 就停止出貨並調查」的判定外,也請把命令輸出中是否有偵測結果、以及成果物檔案是否完整這兩點,一併納入關卡的確認範圍。⁷

3.3. 事先送審未知檔案

Microsoft 明確指出,提交未知或可疑軟體的樣本申請,「有助於讓系統進行掃描,並開始建立信譽」。⁸ 也就是說,樣本申請入口網站不只是被偵測到之後才求助的地方,也是為零實績的新二進位檔案建立第一筆實績的預防手段。在較大的發行(主要版本、封裝方式變更、導入混淆處理工具等外觀大幅改變的時機),值得在開始發佈前先行送審。

4. 被誤判時的正規因應途徑

4.1. 先確認事實 ── 保護記錄與事件記錄檔

首先要確認「不見了」、「無法啟動」這類回報,是否真的是 Defender 偵測所造成的。在圖形介面中,Windows 安全性中心的「病毒與威脅防護」→「保護記錄」會留下偵測與隔離的記錄,也可以篩選顯示已隔離的項目。⁵

若想留存為記錄,或需要遠端確認,就要看事件記錄檔。Defender 的事件會記錄在「應用程式與服務記錄檔 → Microsoft → Windows → Windows Defender → Operational」,也可以用 PowerShell 的 Get-WinEvent 取得。¹² 偵測本身會記錄為事件識別碼 1116(偵測到惡意程式或不需要的軟體),對應的隔離等處置則記錄為 1117。¹³

# 依新到舊的順序確認 Defender 的偵測(1116)與處置(1117)事件
# 篩選在事件記錄檔端進行(-FilterHashtable),比管線後面接 Where-Object 更快
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Windows Defender/Operational'
    ID      = 1116, 1117
} -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message

這時請記錄威脅名稱(例如 Trojan:Win32/Wacatac.B!ml 這類偵測名稱),以及被偵測到的檔案路徑與版本。無論是向 Microsoft 申請,或是向客戶說明,這兩項資訊都是出發點。偵測名稱的結構(類型/平台/家族名稱)遵循CARO(Computer Antivirus Research Organization,電腦防毒研究組織) ── 一個由防毒研究人員組成的團體,其命名規則在業界廣泛使用 ── 的惡意程式命名規則,有時可以從結尾的 !ml 這類後綴,推測出偵測的來源。¹⁴

4.2. 向 Microsoft 回報誤判

這就是恆久因應方式。從 Microsoft Security Intelligence 的樣本申請入口網站(microsoft.com/wdsi/filesubmission)提交被誤判的檔案。申請需要登入,登入後就能追蹤申請的判定狀態。目前並不接受以電子郵件提交樣本。³

第一次使用時容易感到困惑,因此在官方文件所記載的範圍內,先列出步驟的大致骨架。³⁴¹⁵

1. 登入。樣本申請入口網站在未登入狀態下無法提交。自 2024 年 5 月 20 日起,此入口網站的登入已轉移至 Microsoft Entra ID。若組織租用戶設定為需要系統管理員同意,就需要請 IT 管理員授予該應用程式的存取權限。
2. 上傳被誤判的檔案。同時詳細填寫所使用的產品(例如 Microsoft Defender 防毒)、以及在什麼情況下遇到這個檔案。這裡填寫的資訊會直接成為分析的材料,因此請附上在 4.1 確認的偵測名稱、檔案路徑與版本。
3. 將提交者的類別選為 software developer(軟體開發者)。以此類別提交,若之後對判定結果有異議,申請結果就會附上開發者專用聯絡表單。
4. 若擁有 Software Assurance ID(SAID),請一併輸入。入口網站接受 SAID,擁有有效 SAID 的客戶可以用更高優先度提交。若客戶企業持有 SAID,有時由客戶端提交反而更快。
5. 提交後,在申請歷史記錄頁面(microsoft.com/wdsi/submissionhistory)追蹤狀態。狀態分為 Submitted(已受理)、In progress(分析師已開始確認)、Closed(已得出最終判定)三種。若想確認判定是否有更新,可以在申請的詳細頁面選擇重新掃描(rescan)。
6. 等待最終判定,若有異議則要求重新調查。等到判定確定為止;若對結果不滿意,可透過申請結果附帶的開發者專用聯絡表單,聯絡 Microsoft。

畫面上的項目名稱與排列順序有時會更新,若感到困惑,請確認官方文件的說明。另外,提交的檔案會先由自動系統即時掃描,若是已經處理過的檔案,可以很快得到判定。尚未處理的申請,會優先分析影響範圍較大的檔案,或是擁有 Software Assurance ID 的企業客戶所提交的申請。¹⁵

若 Microsoft 因誤判而更新定義,該檔案之後就不會再被偵測到。反過來說,只要不回報,即使用排除設定撐過去,其他客戶環境仍會持續被偵測到。另外,即使是不會留下檔案的行為型偵測,也有提交由 MpCmdRun.exe -GetFiles 產生的診斷檔案(MpSupportFiles.cab)以委託分析的途徑。¹⁵⁷

若客戶是導入了 Microsoft Defender for Endpoint(EDR)的組織,也有管理員途徑可用:由客戶端的資安管理員從 Microsoft Defender 入口網站的申請(Submissions)頁面提交,同時搭配「允許」指標抑制組織內的誤判。¹⁵ 這種情況請不要只靠自家公司處理,務必與客戶的 IT 部門協同進行。

4.3. 還原被隔離的檔案

若能確信是誤判的檔案,可以從隔離中還原。在圖形介面中,從保護記錄選取目標項目後執行「還原」。命令列則使用 MpCmdRun.exe。⁵

rem 列出目前隔離中的項目
MpCmdRun.exe -Restore -ListAll

rem 指定隔離時的檔案路徑,還原到原本的位置
MpCmdRun.exe -Restore -FilePath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

也可以用 -Path 選項指定將檔案還原到其他資料夾(此時該項目仍會保留在隔離中)。⁷ 不過,若在定義更新前就還原,理所當然還是可能再次被偵測到,實務上依「回報誤判 → 視需要進行暫時排除 → 還原」的順序進行才安全。

4.4. 被其他公司的防毒軟體偵測到時

若不是 Defender,而是被 EDR 或其他公司的防毒產品偵測到,向 Microsoft 回報並不能解決問題。必須依偵測到的產品廠商,個別向誤判回報(false positive submission)的窗口提出申請。多數廠商都備有專用表單,可用「廠商名稱 + false positive submission」搜尋窗口,並比照 Defender 的做法,附上偵測名稱、檔案與簽章資訊提出申請。若同時被多個產品偵測到,也可作為懷疑建置端因素(混淆處理、封裝工具、同捆項目)的線索。

5. 客戶環境中的應急處理 ── 排除設定與其風險

5.1. 排除設定的定位 ── 並非恆久因應

在誤判回報的判定結果出爐前,客戶的業務因此停擺的情況下,Defender 的排除(exclusion)設定就成為應急處理手段。但不能弄錯它的定位。正如 Microsoft 自己再三提醒的,排除設定在技術上就是保護上的漏洞(protection gap),官方原則是:(1)謹慎使用,(2)只用於效能問題或應用程式相容性等特定問題,(3)留下為何需要該排除設定的來龍去脈,並定期檢視。⁶ 另外,這裡說明的排除設定,指的是針對 Defender 防毒掃描(排程/隨選/即時保護)的排除。在導入了 Microsoft Defender for Endpoint 的環境中,即使檔案已排除,EDR 的警示或其他偵測仍可能持續發生。¹⁶「明明加了排除卻還是跳出警示」是這項規格造成的,並非故障。

而且即使要加入排除設定,建議停用即時保護本身或整個 Defender 的做法完全不能考慮。這麼做會讓該裝置對應用程式以外的威脅的防禦能力也整體下降。以因應誤判為名義,要求客戶停用資安功能的紀錄,日後在資安稽核時必定會成為問題。

5.2. 正確的設定方式 ── 以完整路徑指定最小範圍

排除設定也可以透過 Windows 安全性中心的圖形介面(病毒與威脅防護設定 → 排除項目)新增,但若要寫成操作手冊,用 PowerShell 比較確實。管理排除清單可使用 Add-MpPreference(新增)、Remove-MpPreference(移除)、Set-MpPreference(整份清單取代)。由於 Set-MpPreference 會覆寫既有的排除清單,為避免不小心刪除客戶環境中既有的排除設定,新增時請務必使用 Add-MpPreference。¹⁶

# 以系統管理員權限的 PowerShell 執行

# 以檔案為單位的排除(最小範圍。不是資料夾,而是以完整路徑指定執行檔)
Add-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

# 確認目前的排除設定
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# 誤判解決後撤除
Remove-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

-ExclusionPath 可以指定到檔案層級,也可以指定到資料夾層級,但若指定資料夾,連子資料夾都會整個納入排除範圍,因此請先考慮以檔案為單位。¹⁶ 另一個選項 -ExclusionProcess 從名稱上容易被誤解,它並不是排除指定的行程本身,而是把該行程開啟的檔案排除在掃描對象之外。若想排除行程的執行檔本身,官方的整理是應該使用 -ExclusionPath。¹⁷ 應用程式因為開啟大量資料檔案而造成偵測或效能問題的情況,用 -ExclusionProcess;執行檔本身被誤判的情況,則用 -ExclusionPath,依情況區分使用。

是否如預期般完成排除,可以用 MpCmdRun.exe -CheckExclusion -Path <路徑> 驗證。⁷ 另外,在受管理的環境中,前提是不應逐台端點手動設定,而是透過 Intune 或群組原則(電腦設定 → 系統管理範本 → Windows 元件 → Microsoft Defender 防毒 → 排除項目)集中管理。Microsoft 建議使用 Intune 定義與編輯排除設定。¹⁶¹⁵

5.3. 不該做的排除設定

排除的資料夾會成為「Defender 不會檢查的地方」,同樣也會被攻擊者利用。Microsoft 具體列出了「即使信任其沒有惡意,也不該排除」的項目。¹⁸

• 像 C:\、C:\Temp、C:\Users\、%Windir%\Temp 這類通用資料夾的排除。為了自家應用程式而把暫存資料夾整個排除,等於是為所有惡意程式提供了安全地帶。
• 像 .exe、.dll、.tmp、.zip 這類以副檔名為單位的排除。
• 像 cmd.exe、powershell.exe、msbuild.exe、java.exe 這類通用行程的排除。
• 只用檔名、不含路徑的排除(例如 ContosoApp.exe)。因為同名的惡意程式無論放在哪裡都會被排除,務必以完整路徑指定。

總結來說,排除設定要「以完整路徑・最小範圍・留下記錄・訂定期限」進行。加入排除設定的事實與理由,應與客戶端的 IT 管理員共享,確認誤判回報的判定出爐、且不再被偵測到之後,就要撤除。

6. 與效能影響的相處之道 ── 「MsMpEng.exe 很吃資源」

與誤判並列的另一個常見諮詢是效能問題。症狀是在工作管理員中看到 MsMpEng.exe(Antimalware Service Executable)吃掉大量 CPU,或應用程式的檔案輸出、建置作業變慢。MsMpEng.exe 是 Defender 防毒服務的主體,即時保護的預設行為是「在檔案開啟的當下同步掃描(open now, scan now)」。¹⁹ 也就是說,大量開關小型檔案的工作負載 ── 建置作業、細碎的記錄檔寫入、頻繁使用暫存檔 ── 掃描次數就會愈多,結構上愈容易受到影響。

6.1. 先量測 ── Performance analyzer

在直接跳到「因為很吃資源所以排除」之前,應先量測掃描負擔的核心究竟是什麼。Defender 提供專用的 Performance analyzer,可用 PowerShell 的 New-MpPerformanceRecording 採集掃描的效能記錄(ETL),再用 Get-MpPerformanceReport 彙整。⁹

# 以系統管理員權限的 PowerShell 執行

# 開始記錄,重現吃資源的操作(建置、批次處理等)後按 Enter 停止
New-MpPerformanceRecording -RecordTo .\Defender-scans.etl

# 顯示掃描時間排名前面的檔案,以及該檔案的掃描明細
Get-MpPerformanceReport -Path .\Defender-scans.etl -TopFiles 3 -TopScansPerFile 10

除了 -TopFiles / -TopScansPerFile 之外,也能取得依行程、依副檔名的彙整,因此可以具體找出「自家應用程式的哪個檔案存取觸發了掃描」。

輸出的內容會因環境而有很大差異,因此這裡整理會顯示哪些項目與該看哪裡。根據官方文件,報告會顯示以下資訊。⁹

所有報告都會以所需時間的降序排列。閱讀順序是:先用 -TopFiles 或 -TopProcesses 瀏覽排名靠前的項目,有頭緒後再用 -TopScansPerFile 展開該檔案的個別掃描。若筆數太多不易閱讀,可以像 -MinDuration 100ms 這樣加上下限,降低雜訊。¹⁰ 若想用其他工具處理記錄,可以像下面這樣輸出成 CSV。⁹

# 將以掃描為單位的原始資料,最多前 1000 筆輸出成 CSV
(Get-MpPerformanceReport -Path .\Defender-scans.etl -TopScans 1000).TopScans |
    Export-Csv -Path .\Defender-scans.csv -Encoding UTF8 -NoTypeInformation

看到這裡之後要判斷的是「排名靠前的是不是自家應用程式產生的東西」。若自家應用程式的暫存檔或記錄檔佔據前列,就依照下面 6.2 的方式,先考慮能否在應用程式端減少。若開發機的建置輸出或套件快取排在前面,6.3 的 Dev Drive 就能發揮效果。只有在兩者都無法解決時,才考慮排除設定。要注意的是,官方文件本身也提醒,這項工具是用來洞察問題檔案,並不是用來建議排除設定的。¹⁰

6.2. 在排除之前,應用程式端可以做的事

若透過量測發現「自家應用程式寫出的大量暫存檔是掃描的核心」,在排除之前還有重新檢視應用程式寫入模式的空間。既然即時保護是以檔案的開啟為觸發契機¹⁹,以下這類設計變更就能直接減少掃描次數本身。

• 把開關數千個小型中繼檔案的處理,整合成對少數檔案的附加寫入,或改為記憶體內處理
• 減少「寫入暫存檔後再重新命名・刪除」這種反覆進行的模式
• 停止逐行開啟並關閉記錄檔的實作方式,改為保持串流開啟狀態下寫入

若要實際量測哪個行程以什麼頻率存取哪些檔案,可以直接使用 Process Monitor。詳細步驟請參閱「Process Monitor(ProcMon)實戰指南」。

6.3. 若是開發機,可用 Dev Drive 的效能模式

在「開發機建置很慢」的情境下,Windows 11 的Dev Drive + 效能模式是第一選擇。在 Dev Drive(以 ReFS 為基礎的開發用磁碟區)上,Defender 的即時保護會以非同步的「效能模式」運作。它不是在檔案開啟時同步掃描,而是在開啟完成後延遲掃描的「open now, scan later」方式;官方將其定位為,相較於像資料夾排除那樣完全停止掃描的做法,能在維持大幅更高保護程度的同時改善效能。¹⁹ 慣例做法是把原始碼樹、套件快取、建置輸出移到 Dev Drive 上。²⁰

先掌握建立方式,執行起來會更順利。前提條件與步驟,官方文件說明如下。²⁰

• 前提條件:Windows 11(組建 10.0.22621.2338 以上)、可用空間 50GB 以上(Dev Drive 的最小容量為 50GB)、記憶體 8GB 以上,建議 16GB,以及本機系統管理員權限。在企業環境中,可能需要由資安管理員設定群組原則。
• 以圖形介面建立:從「設定 > 系統 > 儲存體 > 進階儲存體設定 > 磁碟與磁碟區」中選擇「建立 Dev Drive」。可以從建立新的 VHD / 縮小現有磁碟區 / 使用未配置空間這 3 種方式中選擇。
• 以命令列建立:以系統管理員權限執行 Format D: /DevDrv /Q(命令提示字元/PowerShell)或 Format-Volume -DriveLetter D -DevDrive(PowerShell)。若要部署到多台機器,用這種方式比較輕鬆。
• 注意事項:無法把現有的磁碟區轉換成 Dev Drive。Dev Drive 的指定只能在格式化時進行,若重新格式化現有磁碟區,裡面的內容就會消失。另外,C: 磁碟機無法設為 Dev Drive。官方的預期做法是,開發工具與 SDK 本身放在 C: 磁碟機,原始碼、套件快取、建置輸出則放在 Dev Drive 上。
• 設為信任:效能模式只對「已信任(trusted)」的 Dev Drive 生效。通常在建立時會自動設為信任,但確認或重新設定可以用 fsutil devdrv query D: 與 fsutil devdrv trust D: 進行(例如將 VHD 移到另一台電腦時,就需要重新指定信任狀態)。

不過,效能模式僅在 Dev Drive 上運作,前提是即時保護必須為啟用狀態。此外,「MsMpEng.exe 的 CPU/記憶體使用率偏高」這種症狀並不屬於效能模式的處理範圍,官方的建議是在這種情況下應使用前述的 Performance analyzer,找出負載較高的行程・路徑。¹⁹

除此之外,若隨選掃描(定期完整掃描等)在上班時段造成負擔過重,記住 MpCmdRun.exe -Scan 有 -CpuThrottling 這個開關也會有幫助。加上這個開關後,掃描的 CPU 使用率會套用上限(預設為 50%)。⁷ 不過,這並不是透過在開關後傳遞數值來指定任意百分比的形式。上限值本身要透過原則端的設定(ScanAvgCPULoadFactor)來設定,這個數值並非硬性限制,而是給掃描引擎的參考值,意義是「平均而言不要超過這個比例」。²¹

7. 判斷表 ── 依症狀分類該採取的行動

不論哪種情況,共通的都是以下三點:「先確定事實(偵測名稱・對象・偵測到的產品)」、「務必啟動回報這個恆久因應措施」、「排除・還原僅作為暫時因應,以最小範圍進行」。

8. 總結

• 現代的 Defender 不是靠特徵碼比對,而是依機器學習、雲端保護、實績(信譽)來判定。零實績的新二進位檔案會被懷疑,是機制上的必然;而混淆處理、自解壓縮這類「隱藏實體」的結構,則更容易被懷疑。
• 預防的核心,是以受信任憑證授權單位的憑證進行持續一致的程式碼簽章。並不存在透過事前登記來防止誤判的計畫。發佈前用 MpCmdRun.exe 自行掃描,以及在外觀大幅改變的發行版本中事先提交樣本申請,也很有效。
• 一旦被偵測到,就用保護記錄與事件記錄檔(ID 1116/1117)確定偵測名稱與對象,以開發者身分提交到 Microsoft Security Intelligence 的樣本申請入口網站。被隔離的檔案可以透過保護記錄或 MpCmdRun.exe -Restore 還原。
• 排除設定是在回報判定出爐前的暫時因應。以完整路徑、最小範圍進行,留下記錄,解決後撤除。排除暫存資料夾、副檔名或通用行程,會為惡意程式製造藏身之處,嚴格禁止。
• 效能問題應先用 Performance analyzer 量測,考慮改善應用程式端的寫入模式與 Dev Drive 的效能模式,只有在仍有必要時,才考慮有限度的排除設定。要求客戶停用即時保護是完全不能考慮的做法。

相關文章

• Windows 為什麼會出現「Windows 已保護您的電腦」
• 自動更新功能的安全性基本 - 糟糕的模式與最佳實踐
• Windows 應用程式開發中遵守最低限度安全性的檢核表
• Windows 應用發布方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 自訂 updater 的判斷表
• Process Monitor(ProcMon)實戰指南 ── 在10分鐘內找出「設定未被讀取」「ACCESS DENIED」的原因

相關諮詢領域

合同會社小村軟體處理的諮詢範圍,包括整理已發佈應用程式的誤判・SmartScreen 警告因應方針、設計包含程式碼簽章在內的發佈・更新體制、以及量測與釐清防毒軟體所導致的效能問題。

• Windows 應用程式開發
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

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

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

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

常見問題

整理諮詢這個主題時常見的問題。

自製的應用程式被 Microsoft Defender 判定為病毒,該怎麼辦？

請先不要慌張地立刻採取排除設定或停用 Defender 的做法。恆久因應的正規途徑,是從 Microsoft Security Intelligence 的檔案申請入口網站(樣本申請),以開發者(software developer)身分提交檔案。登入後就能追蹤申請的判定狀態,若被判定為誤判,之後就會透過定義更新不再被偵測到。已被隔離的檔案,可以從 Windows 安全性中心的「保護記錄」,或使用 MpCmdRun.exe 的 -Restore 還原。

要如何向 Microsoft 回報誤判？

從 Microsoft Security Intelligence 的樣本申請入口網站(microsoft.com/wdsi/filesubmission)提交檔案。申請需要登入,提交後可以在入口網站上追蹤判定狀態。提交的檔案會先由自動系統即時掃描,並視需要由分析師進行分析。以開發者身分提交,若對判定結果有異議,可透過申請結果附帶的開發者專用聯絡表單要求重新調查。

在客戶環境中設定排除設定是否恰當？

若作為誤判回報結果反映之前的暫時因應,可以是一種選項,但不應成為恆久因應方式。排除設定是在 Defender 的保護上開一個洞的設定,Microsoft 自己明確指出應「謹慎使用」、「只用於特定問題」、「定期檢視」。若要設定,應限定在執行檔的完整路徑等最小範圍,留下誰・為什麼・到何時的記錄,誤判解決後就撤除。像是整個資料夾或 C:\Temp、副檔名 .exe 這類範圍過廣的排除,等同於為惡意程式製造藏身之處。

程式碼簽章之後,誤判就不會再發生了嗎？

無法保證,但效果很大。Microsoft 並未提供如事先登記到已知清單這類誤判防止計畫,取而代之的是建議「持續以受信任根憑證授權單位的憑證進行一致的簽章」。持續一致的簽章能讓調查團隊迅速確認程式的來源,有時可以加快加入已知清單的速度。反過來說,沒有簽章、每次建置都缺乏來源線索的二進位檔案,每次都會被當作沒有實績的未知檔案,從零開始被懷疑。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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