太長不看版癥狀對照 一分鐘藥方 如果你也碰到了這些癥狀文件明明躺在磁盤上資源管理器里看得一清二楚Everything 卻告訴你查無此物搜出來的結果路徑很離譜文件明明在 D 盤它非說在 G 盤程序能打開、不報錯、托盤圖標也老實待著——看起來歲月靜好實際上已經擺爛。那基本就是索引庫僵死了直接按下面抓藥打開 Everything →工具 → 選項 → 索引 → 強制重建然后去倒杯水喝喝完水回來還沒好管理員 PowerShell 里三連Stop-ServiceEverything-Force;Stop-Process-Name Everything-ForceRename-Item$env:LOCALAPPDATA\Everything\Everything.dbEverything.db.bakStart-ServiceEverything再打開 Everything讓它自己重新掃一遍收工。就這么簡單不用重裝。絕大多數Everything 突然瞎了的病例這兩步之內都能治好。至于它為什么瞎、怎么確診的、以及我是怎么一步步破案并差點把自己繞暈的——往下看。有空詳聊版一、故障現象它開始一本正經地胡說八道一臺使用 Everything 多年的機器某天起出現兩個怪異癥狀明明存在的文件搜不到——文件就在磁盤上資源管理器能看到Everything 卻查無此物搜索結果里的路徑很怪異——部分結果顯示的路徑張冠李戴和文件實際位置對不上。軟件沒有報錯界面能打開服務也在跑看起來一切正常就是不好使。屬于是體檢報告全綠人已經躺平了的典型病例。二、排查思路先搞懂它是怎么記住你的文件的Everything 的搜索完全依賴內存中的索引索引由兩部分支撐Everything 服務Everything.exe -svc負責讀取各分區的 NTFS USN 日志實時維護索引索引數據庫文件Everything.db索引的持久化快照位于%LOCALAPPDATA%\Everything\。因此排查方向依次為進程/服務狀態 → 配置文件 → 卷與 USN 日志 → 數據庫文件本身。由外到內逐層扒皮。三、排查過程四步排除法第 1 步檢查進程與服務Get-Process-NameEverything*Get-WmiObjectWin32_Service-FilterName LIKE %Everything%|Select-ObjectName,State,StartMode,PathName結果界面進程和服務進程都在運行服務狀態Running啟動類型自動可執行文件路徑正常正版安裝非便攜版劫持。結論進程層面沒問題排除程序沒啟動。很好嫌疑人 0案件繼續。第 2 步檢查配置文件讀取%APPDATA%\Everything\Everything.ini重點看卷映射部分ntfs_volume_guids\\?\Volume{xxxxxxxx-...},\\?\Volume{yyyyyyyy-...},... ntfs_volume_pathsC:,D:,E:,F:,G: ntfs_volume_includes1,1,1,1,1 ntfs_volume_monitors1,1,1,1,1再用系統命令核對當前各卷的真實 GUIDGet-Volume|Where-ObjectDriveLetter|ForEach-Object{[PSCustomObject]{Drive$_.DriveLetter;GUID$_.Path}}逐一比對配置里的 5 個卷 GUID 與系統現狀完全一致盤符映射沒有錯位。結論排除換盤/改盤符導致卷映射失效這一常見原因。冤枉排除了一個還剩仨。第 3 步檢查 USN 日志與磁盤健康Everything 依賴每個 NTFS 卷的 USN 變更日志做增量更新。逐卷檢查foreach($dinC:,D:,E:,F:,G:){$dfsutil usn queryjournal$d}5 個卷的 USN 日志全部存在且有效。同時查看系統事件日志無磁盤、分區、卷相關的錯誤事件。結論排除USN 日志被優化軟件刪除和磁盤故障。硬盤表示很委屈它確實沒毛病。第 4 步檢查索引數據庫——抓到元兇 Get-ChildItem$env:LOCALAPPDATA\Everything-Force|Select-ObjectName,Length,LastWriteTime關鍵發現Everything.db ~48MB 最后寫入時間兩天前的 19:10數據庫的寫入時間停在兩天前而期間系統已多次開機、關機Everything 服務也一直處于運行狀態。換句話說保安還在崗亭里坐著但監控錄像早就停止錄制了。正常情況下Everything 退出含關機時會把內存索引落盤Everything.db的時間戳應當隨最近一次關機更新。時間戳凍結 索引早已停止維護界面里展示的是一個兩天前的快照且快照內部的目錄引用已經與真實文件系統脫節。這就完整解釋了兩個癥狀癥狀原因存在的文件搜不到快照里沒有新增/移動后的文件路徑顯示怪異舊索引中的父目錄引用錯位文件掛在了錯誤的目錄下至于觸發點數據庫最后一次成功落盤的時間與一次疑似異常關機斷電/強關的時間吻合——臟關機導致的索引庫失同步是這類故障最常見的誘因。它走的那天連句保存一下都沒來得及說。四、修復方案三板斧專治各種僵死核心思路備份舊庫 → 清空重來 → 全量重建。不需要重裝軟件。方式一圖形界面推薦最安全零門檻打開 Everything →工具 → 選項 → 索引點擊強制重建Force Rebuild確認等待后臺掃描完成視文件數量通常幾分鐘。方式二命令行 / 腳本本次實際采用的方式# 1. 停止服務和界面需要管理員權限Stop-ServiceEverything-ForceStop-Process-Name Everything-Force# 2. 備份舊數據庫不要直接刪留個后路Rename-Item$env:LOCALAPPDATA\Everything\Everything.dbEverything.db.bak# 3. 重啟服務Start-ServiceEverything# 4. 啟動界面會自動發現數據庫缺失并全量重建Start-ProcessD:\...\Everything.exe-ArgumentList-startup注意Everything 1.4 安裝版的數據庫存放在%LOCALAPPDATA%\Everything\配置文件在%APPDATA%\Everything\兩個目錄不要搞混。搞混了的后果就是你刪了個寂寞病還在那兒。五、修復后驗證別急著慶祝先考它三道題重建完成后從三個維度驗證1. 基礎搜索搜索win.ini正常命中系統文件路徑顯示為標準盤符路徑如C:\Windows不再出現怪異路徑。第一題及格。2. 跨卷搜索搜索軟件自身配置文件C、D、G 三個分區的結果全部出現路徑正確。第二題不偏科。3. 實時監控能力最關鍵在兩個數據盤根目錄各新建一個測試文件等待 2 秒后搜索文件名——立即命中。說明 USN 實時監控已恢復之后新產生的文件都能被即時索引。第三題反應速度滿分。E:\ev_test_*.txt ? 命中 F:\ev_test_*.txt ? 命中同時觀察到索引總數仍在緩慢上漲——全量掃描還在后臺收尾屬正常現象幾分鐘后穩定。別看到數字在動就慌那不是故障復發是它在補作業。六、經驗總結給后來者的七句話Everything “能打開不等于能用”。服務活著、界面正常索引照樣可能僵死。遇到搜不到文件先看Everything.db的最后寫入時間這是最快的一招。數據庫時間戳是最直觀的健康指標。只要它在正常關機后仍長期不更新基本可以斷定索引鏈路已斷。修復三板斧強制重建索引 → 無效則停服務、備份并刪除.db重建 → 仍無效再考慮重裝。絕大多數情況第一、二步就能解決。舊庫先備份再刪除重命名為.bak確認穩定幾天后再清理。排查順序建議進程/服務 → 配置中的卷映射 → USN 日志 → 數據庫文件。由外到內每一步都能排除一類原因。預防避免斷電/強制關機如果機器環境惡劣可以定期手動強制重建一次索引。最重要的一條別學我上來就懷疑人生。先看數據庫時間戳一分鐘的事。附常用診斷命令速查收藏這個就夠了# 服務狀態與路徑Get-WmiObjectWin32_Service-FilterName LIKE %Everything%|Select-ObjectName,State,PathName# 數據庫最后更新時間-Force 才能看到隱藏文件Get-ChildItem$env:LOCALAPPDATA\Everything-Force|Select-ObjectName,Length,LastWriteTime# 配置中的卷映射Select-Stringntfs_volume$env:APPDATA\Everything\Everything.ini# 各卷 USN 日志狀態fsutil usn queryjournal C:# 近期磁盤/卷相關事件Get-WinEvent-FilterHashtable {LogNameSystem;StartTime(Get-Date).AddDays(-3)}|Where-Object{$_.ProviderName-matchdisk|Ntfs|volmgr|partmgr}