Autoruns 完整教學:找出工作管理員看不到的隱藏開機項目

⚡ 站長快讀:核心重點

• 文章屬性:教學實戰
• 示範環境:Windows 11 / Windows 10(本文以 64 位元版示範)
• 難易度 / 耗時:⭐⭐⭐ / 約 30 分鐘
• 本文差異化重點:不做工具導覽,而是把 autorunsc 官方 -a 類別代號整理成可對照的判讀清單,並提供「CSV 基準線 + 差異比對」的可重複流程,取代憑印象找可疑項目。
• 適用對象:開機明顯變慢、關掉的程式又自己跑回來、懷疑機器被塞了持續化後門的 Windows 使用者

📌 快速答案

一句話答案:Autoruns 會列出 Windows 全部自動啟動位置,涵蓋工作管理員看不到的服務、排程工作、WMI 項目與 Winlogon 擴充,處置一律先取消勾選停用、不要直接刪除。

🧰 開始前的準備

• 示範環境:本文以 Windows 11 / Windows 10 的 64 位元環境示範(官方頁面未列出系統需求區塊);Autoruns 目前版本為 v14.3(2026 年 6 月 17 日發布)
• 權限需求:系統管理員(要看到 HKLM 底下的機器層項目與服務、驅動,必須提權)
• 需要工具:Autoruns 與 Autorunsc 官方下載(約 3 MB,壓縮檔內同時含 GUI 版 Autoruns 與命令列版 Autorunsc);也可直接從 Sysinternals Live 執行
• 預計耗時:約 30 分鐘(第一次掃描 + 判讀 + 停用 + 重開機驗證)
• 難度門檻:會用檔案總管解壓縮、看得懂登錄檔路徑即可;命令列章節需要會開系統管理員身分的 PowerShell

🔍 為什麼你需要這個?

你大概做過這件事:開工作管理員切到「啟動應用程式」,把一堆看起來沒必要的東西停用,重開機——結果開機還是慢,某個你明明關掉的常駐程式又自己回來了,系統匣裡多出一個你沒裝過的圖示。

問題不在你手速不夠快,而在你看的那張清單本來就不完整。微軟官方支援文件在說明「開機自動啟動」時,列出的是啟動資料夾(shell:startup、shell:common startup)與登錄檔 Run 機碼這類應用程式層級的啟動項——含使用者與全機兩種位置;而 Autoruns 的官方說明自述,它「對自動啟動位置的掌握度是所有啟動監控工具中最完整的」,並直接點名它會回報 Explorer 殼層擴充、瀏覽器輔助物件、Winlogon 通知、自動啟動服務,以及更多其他位置。

換句話說,工作管理員給你的是冰山露出水面的那一角。真正讓開機拖慢的自動啟動服務、被排程工作偷偷叫起來的程式、以及惡意程式最愛用的那幾個冷門持續化位置,都不在那張清單上。

這篇要做的,是把 Autoruns 從「一個看起來很嚇人的長清單」變成一套可執行的流程:先降噪、再查證、最後才動手,而且每一步都留得住退路。

🛠️ 實戰步驟

⚠️ 執行前務必詳讀:本文步驟會停用系統層級的自動啟動項目,並涉及登錄檔設定值的變更與刪除。動手前請先建立系統還原點,並依 Windows 11 登錄檔備份與還原完整教學匯出一份完整登錄檔備份。筆電請接上電源,操作過程中不要斷電。

停止條件清單(符合任一,請停手):①不確定自己的 Windows 版本或版次;②尚未完成登錄檔備份或還原點;③已啟用 BitLocker 但手上沒有修復金鑰;④公司或學校管控的設備而未取得 IT 授權;⑤看到的項目與本文描述明顯不符;⑥停用後畫面或功能出現非預期變化。

步驟一:以系統管理員身分執行 Autoruns

下載回來的 Autoruns.zip 解壓縮後,64 位元 x64 機器用的是 Autoruns64.exe(GUI)與 autorunsc64.exe(命令列);壓縮檔內另含 32 位元版(Autoruns.exe)與 ARM64 版(Autoruns64a.exe),ARM 筆電請認明檔名尾巴的 a。一定要用滑鼠右鍵 →「以系統管理員身分執行」,否則 HKEY_LOCAL_MACHINE 底下的機器層設定、服務與驅動程式清單會不完整,你等於又看了一次半殘的清單。

第一次啟動時 Autoruns 會跑一輪完整掃描,底部狀態列會顯示正在讀取的位置。官方說明的用法很直接:執行 Autoruns,它就會列出目前設定好的自動啟動應用程式,以及所有可供自動啟動設定的登錄檔與檔案系統位置;要看不同類別,切換上方分頁即可。

先別急著取消勾選任何東西。第一次跑就動手,是這個工具最常見的翻車方式。

步驟二:開啟簽章驗證與 VirusTotal 查詢

這是把 Autoruns 從「清單工具」升級成「鑑識工具」的關鍵一步。

依官方說明,Options 選單裡除了數個顯示過濾選項(例如只顯示非 Windows 項目),還有一個掃描選項對話框,可以在裡面啟用簽章驗證,以及 VirusTotal 雜湊值查詢與檔案送驗。

💡 為什麼要這樣做? 簽章驗證會告訴你這個執行檔是誰簽的、簽章是否有效;VirusTotal 查詢則是把檔案的雜湊值送去比對。兩者合起來,你判斷的依據就從「這個檔名看起來怪怪的」變成「這個檔案沒有有效簽章,而且 VirusTotal 有回報偵測」。

⚠️ 隱私提醒:官方明確標示,使用 VirusTotal 功能前必須先接受 VirusTotal 服務條款。雜湊值查詢只送出檔案指紋;但若你另外開啟「送出檔案」,那是把檔案本體上傳到第三方服務。公司機密環境請只開雜湊查詢,不要開檔案上傳。

步驟三:用「Hide Signed Microsoft Entries」降噪

打開 Autoruns 第一眼會看到滿滿一整頁項目,其中絕大多數是 Windows 自身已簽署的東西。官方說明指出,Hide Signed Microsoft Entries 選項的用途,正是幫你聚焦在「被加進系統的第三方自動啟動映像」。

勾選之後,清單通常會大幅縮短(實際剩幾列視機器上裝了多少第三方軟體而定)。剩下的那些才是你要看的東西。

判讀順序建議如下:

選到可疑項目後,用 Entry 選單的 Jump to Entry(或工具列按鈕)可以直接跳到該項目對應的登錄檔或檔案系統位置;若 Process Explorer 正在執行,而且該執行檔目前有活動中的處理程序,Entry 選單裡的 Process Explorer 項目會直接開啟那個處理程序的內容對話框。要看執行檔本身的屬性,選取後用 Properties 選單或工具列按鈕。

步驟四:逐分頁看重點,不要只看 Logon

Logon 分頁是大家最熟的那一塊,但真正的差異在其他分頁。官方說明列出的自動啟動位置包含:登入項目、Explorer 附加元件、Internet Explorer 附加元件(含 Browser Helper Objects)、AppInit DLLs、映像挾持(image hijacks)、boot execute 映像、Winlogon 通知 DLL、Windows 服務與 Winsock 分層服務提供者、媒體轉碼器等等。

命令列版 autorunsc 的 -a 開關把這些類別編成代號,對照著看最清楚:

工作管理員的「啟動應用程式」分頁,管的是註冊為啟動工作的應用程式;上面表格中 * 是「全選」而非類別,官方文件用法表所列的類別代號共十六個;其中絕大多數在該分頁根本沒有對應介面。開機被拖慢時,最常見的元兇其實在 s(自動啟動服務與驅動)與 t(排程工作)這兩類;而持續化後門偏好躲的位置,則集中在 m(WMI 項目)、w(Winlogon)與 h(映像挾持)——這三類幾乎沒有一般使用者會主動去看。

若你要追的是「開機階段到底誰在吃資源」,Autoruns 負責回答「有哪些東西被設定成自動啟動」,而 ProcMon 的 Boot Logging 負責回答「它們在開機當下實際做了什麼」,兩者是互補關係。

步驟五:用 Autorunsc 建立基準線,之後只看差異

這是本文最想推的一招。憑記憶比對「上次好像沒有這一項」不可靠;正確做法是在系統乾淨時存一份基準線,日後只看新增了什麼。

autorunsc 是 Autoruns 的命令列版本,官方列出的相關開關包括:-c 輸出 CSV、-ct 輸出 tab 分隔、-h 顯示檔案雜湊、-s 驗證數位簽章、-m 隱藏微軟項目、-t 以正規化 UTC 顯示時間戳記(格式 YYYYMMDD-hhmmss)、-x 輸出 XML。

以系統管理員身分開啟 PowerShell,切換到解壓縮後的資料夾,執行:

# 掃描全部類別,含雜湊與簽章驗證,輸出 CSV 基準線
.\autorunsc64.exe -accepteula -nobanner -a * -c -h -s -t -o baseline.csv

ℹ️ -accepteula 與 -nobanner 是 Sysinternals 系列共通的慣例開關(前者略過首次執行的授權對話框,後者不印版權橫幅),未列在 Autoruns 官方用法表中;-nobanner 可避免版權橫幅混進輸出——若改用 > 重新導向,橫幅會被寫進檔案並破壞後續的 CSV 解析。

日後懷疑機器被動過手腳時,再跑一次,存成另一個檔名:

# 事後重新掃描
.\autorunsc64.exe -accepteula -nobanner -a * -c -h -s -t -o current.csv

接著用 PowerShell 比對兩份清單的差異:

# 列出新增的自動啟動項目
$a = Import-Csv baseline.csv
$b = Import-Csv current.csv
Compare-Object $a $b -Property Entry,'Image Path' |
  Where-Object SideIndicator -eq '=>'

💡 為什麼要這樣做? 這招把「憑印象判斷」換成「差異比對」。多數持續化手法會新增一個自動啟動項,差異比對讓它無所遁形;而且 CSV 存下來就是一份帶時間戳記的證據,交給資安人員或送修時都用得上。

官方另外提供兩個實用開關:-u 在啟用 VirusTotal 檢查時,只顯示 VirusTotal 未知或偵測數非零的檔案(未啟用 VirusTotal 時則只顯示未簽章檔案);-z 則可指定離線的 Windows 系統進行掃描——這是在「機器已經開不了機」時的關鍵武器,詳見下方回退章節。

步驟六:驗證結果

處置一律遵守這個順序:取消勾選 → 重開機 → 觀察 → 確認無副作用後再考慮刪除。

官方對這兩個動作的定義很明確:取消勾選核取方塊 = 停用該自動啟動項目;要刪除自動啟動設定項目,則是使用 Delete 選單或工具列按鈕。兩者的差別在可逆性——停用可以隨時勾回來,刪除是把設定項目移除。

重開機後回到 Autoruns 確認三件事:

1. 你停用的項目仍維持未勾選狀態(若又自己勾回來,代表有東西在重建它,這本身就是強烈的異常訊號)
2. 開機時間是否改善(可用 Windows 事件檢視器的診斷-效能記錄檔比對,或單純用手機碼錶,但別把碼錶數字當成精確測量)
3. 有沒有任何功能不見了——常見的是輸入法工具列、顯示卡控制面板、雲端同步軟體的系統匣圖示

若你是在排查「電腦莫名卡頓」而不是抓惡意程式,乾淨開機 Clean Boot 是微軟官方的標準二分法診斷流程,和 Autoruns 搭配使用效率最高:Autoruns 負責看清楚有哪些項目,乾淨開機負責用二分法縮小範圍。

🔬 底層機制:這個問題到底在系統哪一層?

要理解為什麼會有「工作管理員看不到的開機項目」,得先接受一個事實:Windows 從來就沒有一份「開機自動啟動項目」的統一清單。

Windows 的自動啟動是由散落在系統各處的自動啟動延伸點(Auto-Start Extensibility Point,業界慣稱 ASEP)共同構成的。登錄檔的 Run 機碼只是其中最有名的一個;殼層擴充、服務控制管理員、工作排程器、Winlogon、Winsock 分層服務、甚至媒體轉碼器註冊表,各自都是獨立的自動啟動管道。它們分屬不同的子系統,由不同的元件在不同的開機階段載入,彼此之間沒有共用的登錄中心。

工作管理員之所以只列得出一小部分,是因為它做的是「應用程式體驗」層級的事;而 Autoruns 做的是把所有子系統的自動啟動點逐一列舉出來——這也是官方說明敢寫「對自動啟動位置的掌握度是所有啟動監控工具中最完整的」的原因。

以最基本的 Run 與 RunOnce 為例,微軟 Win32 官方文件記載的行為就有幾個容易踩到的細節:

• 共有四個機碼:HKLM 與 HKCU 底下各一組 Run 與 RunOnce
• 每個值的資料是一行命令列,長度上限 260 個字元
• Run 每次使用者登入都執行;RunOnce 執行一次後該值就被刪除
• HKLM 的 RunOnce 只在重新開機後、Administrators 群組成員登入時才執行
• 預設情況下,RunOnce 的值會在命令列執行之前就被刪除;若在值名稱前加上驚嘆號 !,刪除動作會延後到命令執行完之後
• **預設情況下,電腦以安全模式啟動時會忽略這些機碼;但若值名稱前加上星號 *,程式即使在安全模式下也會被強制執行**
• 同一個機碼下若註冊了多個程式,執行順序不保證;系統也不保證 Run 機碼裡的程式多快會被執行,為了不干擾前景使用體驗,系統可能刻意延後 Run 機碼與啟動群組的執行

最後兩點對排查很關鍵。第一,那個 * 前綴意味著「進安全模式就能躲掉所有自動啟動項」這個直覺並不成立——安全模式仍可能執行被刻意加上星號的項目,這是根據官方文件所載行為的合理推論。第二,「執行順序不保證」與「系統可能延後執行」解釋了為什麼同一台機器每次開機的卡頓時間點都不太一樣,也解釋了為什麼靠碼錶量開機時間的可信度有限。

至於 WMI 項目(autorunsc -m)、Winlogon 通知 DLL(-w)與映像挾持(-h)這三類,共同特徵是不需要在使用者可見的地方留下任何圖示或捷徑,卻能在系統啟動或特定事件發生時取得執行機會。這正是它們同時具備「一般使用者看不到」與「排查價值極高」兩種性質的原因,也是 Autoruns 值得單獨學一次的理由。

🔙 萬一翻車:回退步驟

回退的第一原則:回到你操作前備份的那個值,而不是回到某個「應該是預設值」的設定。 各版本、各版次的 Windows 原廠預設不盡相同,家用版與專業版尤其容易不一致;硬填一個你以為的預設值,結果可能比原本更糟。這也是步驟一開頭要求先匯出登錄檔備份的理由。

情境一:設定生效但某個功能不見了

最常見的狀況——停用後發現輸入法工具列、顯示卡控制面板或雲端同步的系統匣圖示不見了。

處理方式:重新開啟 Autoruns(仍以系統管理員身分),找到那一列,把核取方塊勾回去,重新開機即可。這就是為什麼處置一律先停用、不要直接刪除:停用是可逆的,刪除不是。

若你當時是用 autorunsc 存過基準線,直接開 baseline.csv 對照 Entry 與 Image Path 兩欄,就能確認原本有哪些項目。

情境二:設定後系統出現錯誤

若停用後出現服務啟動失敗、應用程式報錯,或桌面異常:

1. 先開 Autoruns 把本次所有變更全部勾回去,重開機確認是否恢復
2. 若已按過 Delete 而無法勾回,匯入你在步驟一匯出的登錄檔備份檔還原對應機碼
3. 仍未恢復,使用系統還原點回到操作前的狀態
4. 若連桌面都進不去,先進安全模式再執行上述動作(方法見文末延伸閱讀)

情境三:系統無法開機(最壞情況)

若停用了某個關鍵驅動或服務導致無法開機:

1. 連續兩到三次在開機過程中斷電,Windows 會自動進入 WinRE(Windows 修復環境)
2. 在 WinRE 選擇「疑難排解 →進階選項 →系統還原」,套用操作前的還原點
3. 若還原點不可用,改選「啟動設定」進入安全模式,再依情境二處理
4. 進階做法:把該硬碟接到另一台正常的 Windows 電腦,用 autorunsc 的 -z 開關指定離線的 Windows 系統進行掃描,先確認故障系統上目前有哪些自動啟動項目,再決定處置方向

💡 總結:進階玩法與底層邏輯

站長我要先把話說清楚:本文的每一項行為描述、參數說明與登錄檔語意,來源都是 Microsoft Learn 的 Sysinternals Autoruns v14.3 官方頁面(2026 年 6 月 17 日發布)與 Win32 平台的 Run/RunOnce 官方文件,不是實驗室實測數據。文中沒有任何自行量測的秒數、百分比或硬體型號,原因很簡單:自動啟動項目的組成因機器而異,任何「我這台快了幾秒」的數字對你都沒有參考價值,反而容易誤導。

真正值得帶走的是三件事。

第一,分級處置。取消勾選是可逆的停用,Delete 是刪除設定項目——官方對這兩個動作的定義本來就不同,別把它們當同一件事。任何時候都先停用,觀察一到兩個完整工作日,確認沒有副作用,再考慮是否清掉。

第二,基準線思維。v14.3 這次更新的官方說明寫得很明白:修正錯誤,並讓命令列版 autorunsc 與 GUI 功能完整對齊。對系統管理員來說,這代表你可以放心把 autorunsc 排進定期工作,每月存一份 CSV;真的出事時,差異比對只要幾秒鐘,而不是靠回憶。

第三,分工觀念。Autoruns 回答「有哪些東西被設定成自動啟動」,ProcMon 的 Boot Logging 回答「它們在開機時實際做了什麼」,乾淨開機回答「到底是哪一個造成衝突」。這三個工具經常被拿來互相比較,但它們其實是排查流程上的三個不同階段。

最後提醒一次:Autoruns 是一把好用的刀,它不會阻止你砍到自己。備份、停用優先、留基準線——這三件事做到,它就只會是工具,不會變成事故來源。

🔗 延伸閱讀

• 檔案總管一直閃退或重啟?Explorer.exe 當機完整排查方法——Explorer 殼層擴充是 Autoruns 的重點分頁之一,當機排查會直接用到
• Windows 資源監視器完整教學:比工作管理員更強,揪出鎖檔與吃資源的元兇——確認可疑程式正在做什麼 I/O 與網路連線
• Windows 開不了機/狂當機?進入「安全模式」(Safe Mode) 診斷問題教學——回退情境二、三會用到
• 一個檔案裡還能藏檔案?NTFS Alternate Data Streams 原理與檢查方法——自動啟動項指向的檔案本身也可能藏東西

📎 參考資料來源

📖 第一級|廠商官方:

• Autoruns v14.3 — Sysinternals(Microsoft Learn) — 2026-08-20 查證
• Autoruns v14.3 版本說明(Microsoft Sysinternals Blog) — 2026-08-20 查證
• Run and RunOnce Registry Keys(Microsoft Learn / Win32) — 2026-08-20 查證
• Configure Startup applications in Windows(Microsoft Support) — 2026-08-20 查證
• Process Explorer — Sysinternals(Microsoft Learn) — 2026-08-20 查證

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-08-20 依 Autoruns v14.3 官方文件整理撰寫。

若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。