开始菜单搜不到已装的软件怎么办？应用列表与文件索引两条通道逐项实测

开始菜单搜索是 Windows 把"应用列表"和"文件索引"两份完全不同的数据拼在同一屏结果里的机制：前者来自 shell:AppsFolder，列的是当前用户装过的应用；后者是 Windows Search 服务（进程名 SearchIndexer.exe）维护的一份数据库，列的是被爬到的文件和文件夹。装好的软件在搜索里不出现，多半是这两条通道里的一条没数据，而不是"搜索坏了"。微软在讲已知问题时甚至专门列了一条"桌面搜索或 Cortana 找不到快捷方式文件"，状态写的是"in investigating"。本文把这两条通道在本机各量一遍，再回答三个常被混在一起的问题：某个快捷方式到底进没进索引、注册表里那份"爬取范围"能不能当判据、以及标准用户能查什么、哪些动作必须管理员。

信息核验时点：2026-11-02（Windows 11 当前正式版 26H2，正式版于 2026-09-29 推出，最新内部版本 26300.9818；文中两条通道的实际数量、一次全索引扫描取回的 16,427 行明细、21 条默认爬取规则的逐条读取、系统疑难解答包内 12 个脚本的实际动作，以及索引数据库与日志目录的三处权限边界，均在 Windows 10 专业版 19045.6466 的实机上以标准用户身份执行并留存输出；引用的微软文档页面均标注了更新时间）

开始菜单里那一屏结果，是从哪两个地方拼出来的？

先各给一句能独立成立的定义。应用列表（Application Folder，资源管理器地址栏输 shell:AppsFolder 看到的那个页面）是当前用户已安装应用的登记表，登记用的标识叫 AppUserModelID；文件索引（SYSTEMINDEX）是 Windows Search 服务把"爬取范围"内的文件逐个抽取属性与正文后建出来的数据库。一屏搜索结果由这两份数据拼出来，所以"搜不到"要先问是哪一份里缺。

应用列表这一头，微软给了一条不需要任何权限、也不需要管理员的命令。Get-StartApps（模块 StartLayout，ms.date 2016-12-20、页面更新于 2025-05-14）的首句逐字是："The Get-StartApps cmdlet gets the names and AppIDs of installed apps of the current user. An AppID is an AppUserModelID."，同页的语法块只有一个可选位置参数 -Name；这一页对它有两处不一致的口径，描述段写 "You can specify a particular app by using its name, or you can specify a name that includes the wildcard character (*)"，参数表那一行却写 Supports wildcards: False，所以按名称筛的时候，别把通配符当成稳定行为。本机不带参数跑出来是 109 条，而 Get-AppxPackage 列出的包总数是 113——两个数字不一样，因为应用列表里还包括以传统方式登记的 Win32 程序。把本机 109 条按 AppID 的写法分类，是打包应用 35 条、可执行文件全路径 37 条、点号风格标识 30 条、快捷方式路径 7 条，四种写法本机的真实样本分别是 Microsoft.Microsoft3DViewer_8wekyb3d8bbwe!Microsoft.Microsoft3DViewer、C:\Users\HKC\AppData\Local\Programs\Python\Python312\python.exe、com.qoder.app、以及"字符映射表"那条 {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\charmap.exe——开头那个大括号里的标识展开就是 System32，所以这种写法同样指向一个真实存在的程序。

两条通道的差别用一张表说清：

顺带记一个观察点：本机 HKCU\Software\Microsoft\Windows\CurrentVersion\Search 这个键里，除了 SearchboxWidth、SearchboxMonitorDPI 这类界面参数，还有两个名字很直白的值——InstalledWin32AppsRevision 与 InstalledPackagedAppsRevision，数据都是一对 GUID，同批还有一个 NamespaceSettingsRevision。从名字看它们是"应用列表与命名空间重建过的第几版"这种标记，但微软没有公开它们的规则，别拿它当诊断依据；值得一提的是这一整串值所在的键，正是本文后面 Solution 6 让你删除的那个 ...\CurrentVersion\Search。本文所有判断都建立在前后可复现的读取上。

本站另一篇 双击打不开文件、默认应用被抢回怎么办？文件关联三层记录与打开方式残留项实测清理 处理的是"双击时谁被打开"，和本文的"搜索时谁被列出"是两条独立链子——一个软件完全可以搜不到但双击得好好的。

不打管理员标记，怎么把索引里到底有什么全部列出来？

这件事微软没给命令，但系统里本来就挂着一条只读通道：搜索服务的查询 provider。本机实测可用的是这一段 PowerShell（就是本文所有索引数字的来源）：

$con = New-Object -ComObject ADODB.Connection
$con.Open("Provider=Search.CollatorDSO;Extended Properties='Application=Windows';")
$rs = $con.Execute('SELECT TOP 40000 System.ItemName, System.Kind, System.ItemPathDisplay FROM SYSTEMINDEX', $null, 1)
while (-not $rs.EOF) {
    Write-Output ([string]$rs.Fields.Item('System.ItemName').Value)
    $rs.MoveNext()
}
$con.Close()

三个必须照抄的细节，都是本机踩出来的。第一，客户端必须是 COM 的 ADODB.Connection；本机换用 .NET 的 System.Data.OleDb.OleDbConnection 连同一个 provider、同一条 SQL，Open() 不报错、结果集一行都没有，扫完花了 30.2 秒返回 0 行，而 ADODB 那次 2.7 秒返回 16,427 行。第二，列名用 System.ItemName、System.Kind、System.ItemPathDisplay 这三个本机验证过能取到值的写法；查询对象名是 SYSTEMINDEX。第三，$con.Execute() 的第三个参数 1 表示只进光标，标准用户下能跑通，全程没有任何写入。

跑出来的总量要和界面上的数字对得上。微软给读法的原文在 Troubleshoot Windows Search performance（ms.date 2026-02-12、更新于 2026-02-19）里，逐字是："Windows 10: Select Settings > Search > Searching Windows, and then check the value of Indexed Items."——Windows 11 的入口换成了 Settings > Privacy & security > Searching Windows。本机这条查询取回 16,427 行，和"已索引的项目"应当是同一个量级；用脚本比用界面多能拿到的是每一行的路径和类型，这正是下面三节要用的东西。这条链子是可以复跑对账的：本机在同一天稍晚又原样跑了一遍，总行数仍是 16,427、开始菜单子树仍是 108 行，说明这段时间里索引没被重建过。

磁盘上有这个快捷方式，为什么在索引里就是搜不到它的名字？

因为索引里根本不存磁盘真名。本机两边各取一份清单，一对就现形了。

磁盘这一侧（用 Get-ChildItem -LiteralPath 走真实路径）：

• 机器级根目录是 C:\ProgramData\Microsoft\Windows\Start Menu\Programs，第一层子目录名全是英文：Accessibility、Accessories、Administrative Tools、Maintenance、StartUp、System Tools。
• 其中 Accessories 里的文件叫 Notepad.lnk、Paint.lnk、Snipping Tool.lnk、Wordpad.lnk；Accessories\System Tools 里有一个 Task Manager.lnk。

索引这一侧（同一条查询里的行）：

• 路径写成 C:\ProgramData\Microsoft\Windows\「开始」菜单\程序\Windows 附件\记事本.lnk，类型 link program。
• Task Manager.lnk 这一行是 ...\程序\Windows 系统\任务管理器.lnk；Accessibility 变成 Windows 轻松使用，Administrative Tools 变成 Windows 管理工具。

也就是说路径的每一段和文件名本身都被换成了资源管理器显示的本地化名称。想在资源管理器里核对磁盘上的真实名字，第一步是把扩展名显示出来，本站 Windows 文件资源管理器效率指南：那些被忽略但极好用的操作怎么用 讲过这一项设置怎么打开；但要看"文件夹的真实名字"仍然只能用本文这种命令行读路径，图形界面里看到的永远是显示名。这个结论的价值很直接：任何"拿磁盘文件名去索引里比对"的自查方法都会大面积报假阴性。本文第一次做这个对照时，用 92 个磁盘 .lnk 去索引里按名字精确匹配，得到"只有 44 个在、48 个不在"；而按开始菜单路径聚合再看，索引里这个子树下有 108 行，其中 .lnk 恰好 72 行、文件夹 26 行、desktop.ini 10 行——磁盘上机器级开始菜单里的 .lnk 正好也是 72 个。两边数量对得上，之前那 48 个"缺失"几乎全是被本地化显示名挡住的。

第二组数字更值得记住，因为它不是显示层的假象。索引里位于 Roaming（即当前用户 %AppData%\Microsoft\Windows\Start Menu\Programs）路径下的行是 0，而磁盘上这个目录里有 20 个 .lnk，本机实测包含 Qoder.lnk、NoteEasy.lnk、Python 3.12 那一组快捷方式。换句话说，机器级开始菜单被索引、用户级开始菜单没被索引。同一时刻，全盘索引里名字以 .lnk 结尾的一共 94 行，来源很集中：Windows 管理工具 20 行、C:\用户\公用\公用桌面 14 行、Windows 附件 10 行、程序 根目录 7 行、C:\用户\HKC\桌面 6 行。桌面上的快捷方式进索引、开始菜单用户级的不进索引——这就是为什么把程序"放到桌面"往往立刻能搜到，而装在用户级开始菜单里的东西死活搜不到。

还有一个查询层的坑：System.Kind 是复合值，等值比较会骗人。本机按 Kind='program' 查得到 75 行，而类型分布表里 program 只有 28 行、link program 有 47 行——28 加 47 正好 75，说明 program 是作为分词命中了 link program 这类复合类型；反过来按 Kind='link program' 精确等值查是 0 行。本机完整类型分布是：空值 13,092、folder 1,915、picture 982、document 308、link program 47、link 45、program 28、video 5、folder searchfolder 2、link folder 2、music 1。

注册表里那份「爬取范围」清单，能不能当判据？

位置在 HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex，下面三个子键：SearchRoots、DefaultRules、WorkingSetRules。标准用户可读，本机读出来是 5、21、21 条，且 21 条规则的 Default 标志全部为 1——这意味着这台机器没人改过索引范围，工作集就等于默认规则。

SearchRoots 的 5 条是协议根：file:///C:\[0748a69f-…]\、csc:// 加当前用户 SID、defaultroot:// 加 SID、iehistory:// 加 SID、winrt:// 加 SID。DefaultRules 里 21 条只有 5 条 Include=1：

Include=0 的 16 条里，几条眼熟的：ProgramData\、ProgramData\Microsoft\Search\Data\、Windows\、Windows.*\、Users\*\AppData\、Users\HKC\AppData\、Users\HKC\.*\、Users\*\AppData\Local\Temp\、*\$RECYCLE.BIN\、*\System Volume Information\。这里能看到一个设计：整个 ProgramData\ 被排除，但其中的 Start Menu 单独放进来——这正好解释了上一节"机器级开始菜单有 108 行"；而 Users\ 整体被放进来，Users\*\AppData\ 又被扣回去——这正好解释了"用户级开始菜单 0 行"，因为它就住在 AppData 里。索引自己的存放目录 ProgramData\Microsoft\Search\Data\ 也被排除，避免自己索引自己。

但这份清单不能反过来当判据。本机两处实测就是反例：Users\*\AppData\ 与 Users\HKC\AppData\ 都标着 Include=0，索引里路径含 AppData 的行却有 1,518 行，其中 AppData\Local\Packages 一段占 453 行；Users\HKC\.*\ 也标 Include=0，可 C:\用户\HKC\.qod 这个前缀下有 9,673 行。这些行是怎么绕开那条规则的，本文没有证据下结论——唯一能确定的是"规则表里写着 0"推不出"索引里没有"。所以判"某个文件夹到底有没有被索引"，只有两条可靠路：要么按上一节那样直接查索引，要么用微软给的界面读法，performance 那一页逐字写的是："To see a detailed list of the locations that are indexed, open Searching Windows, and select Advanced Search Indexer Settings (Windows 10) or Advanced indexing options (Windows 11). In Indexing Options, select Modify."

顺带排掉一类看起来像"被策略关了"的情况。组策略这一头本机逐个试过路径：HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search、HKCU\Software\Policies\Microsoft\Windows\Windows Search、HKLM\SOFTWARE\Policies\Microsoft\Windows\EdgeUI、HKCU\Software\Policies\Microsoft\Windows\EdgeUI、HKCU\Software\Policies\Microsoft\Windows\Explorer，五个位置用 Test-Path 读回来全部是不存在——这台机器上没有任何策略在管搜索、在改搜索框形态、或在动资源管理器与开始菜单的行为，"搜不到"不能甩锅给组策略。

服务在跑、索引在建、结果却不对，这三件事分别看哪里？

先分清楚三个状态层：服务（WSearch 有没有在跑）、进程（搜索界面和索引器是不是活着）、索引内容（SYSTEMINDEX 里有没有那一行）。三层的读法都能用标准用户权限完成。

服务层。本机 Win32_Service 读出来是 State=Running、StartMode=Auto、StartName=LocalSystem、PathName 为 C:\WINDOWS\system32\SearchIndexer.exe /Embedding。官方对"应该长什么样"写得很具体，performance 那一页在"Indexing is not running."这条状态消息的处理栏里逐字要求："The service should have the following configuration: - Status: Running - Startup Type: Automatic (Delayed Start)"，同栏还有一句该记住的外部因素："Some anti-virus programs and \"Optimize your PC\" applications disable the Windows Search service. We recommend that you don't run such applications if you want to use Search."。这一条要读两个入口才判得准：Win32_Service 那个 StartMode 只区分 Auto/Manual/Disabled，它不告诉你有没有"延迟"，只看这一项容易把自己误判成不合规；本机同一次排查里 sc qc WSearch 打的是 START_TYPE : 2 AUTO_START (DELAYED)，服务键 HKLM\SYSTEM\CurrentControlSet\Services\WSearch 下面也是 Start=2、DelayedAutostart=1，两处合起来说明本机正是官方要的那个配置。想确认服务有没有"起来又停掉"，看 System 日志里来源 Service Control Manager 关于 WSearch 的事件即可——本机在最近 3000 条 SCM 事件里检索到 0 条，也就是说那份"服务启动后停止"的官方报错在本机从来没发生过。

进程层。这里有一个文档与实机的错位，值得单独指出。Fix problems in Windows Search（ms.date 2026-02-12、更新于 2026-02-19）的 Solution 4 逐字是："Follow these steps to end the SearchUI.exe (Windows 10) or SearchHost.exe (Windows 11) process. Stopping this process stops Windows Search. The next time that you search, Windows Search automatically starts." 本机是 Windows 10 22H2，进程表里 SearchUI.exe 和 SearchHost.exe 各 0 个，实际在跑的是 SearchApp.exe（1 个实例，路径在 C:\WINDOWS\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\，该包版本 1.14.18.19041）。内存这类数字别抄死：本机隔两个多小时用同一条 Get-Process 跑了两遍，SearchApp 的工作集分别是 195.1MB 与 183.7MB。同期还在跑的配套进程：SearchIndexer 1 个（51.3MB，同一进程用 tasklist 读是 46,724K）、SearchProtocolHost 1 个（10.6MB）、SearchFilterHost 1 个（8MB）、StartMenuExperienceHost 1 个（81.4MB）、ShellExperienceHost 1 个（60.8MB）。所以要按 Solution 4 结束进程，在 19045 上结束的是 SearchApp.exe——任务管理器"详细信息"页里按名字找，找不到文档里那两个名字是正常的。

索引层。这一层最省事的读法是事件日志，来源 Microsoft-Windows-Search。本机能读到的事件 id 与中文原文（逐字）：

这五条连起来讲的是一次完整的"全部索引重置"，而且它离现在已经有四个半月——本机 6 月 17 日之后没有再重建过索引。这一点对排查很有用：如果你的软件是近期装的，而索引是几个月前建的，缺失更可能是"范围没覆盖"或"显示名对不上"，而不是"索引没建好"。另外 ESENT 来源里提到 Windows.edb 的 51 条在本机全是信息级，没有报错；更细的 Microsoft-Windows-Search-Analytic、SearchProfile-Analytic、SearchManager-Analytic 三个频道以标准用户身份读到的是 0 条可读事件，想看这些要提权。

系统自带的「搜索和索引」疑难解答，到底改了什么？

官方入口在 Solution 3，命令逐字是 msdt.exe -ep WindowsHelp id SearchDiagnostic。同一节还有两句常被忽略的话：一是"如果你运行的是 Windows 10 版本 1903 或更高版本，当 Windows 检测到问题时会自动运行 Search 疑难解答"，原文 "Windows automatically runs the Search troubleshooter. This troubleshooter resets Windows Search to the default experience."——它不是"帮你查一下"，而是把搜索拉回默认状态；二是查历史的路径："To view your troubleshooter history, select Start > Settings > Update & Security > Troubleshoot > View troubleshooting history."

它到底做了什么，不必猜。这个包真实落在 C:\Windows\diagnostics\system\Search\（本机另有常被教程提到的 C:\Windows\diagnostics\system\indexer\ 并不存在），目录里 16 个文件、13 个 .ps1：一个 467 行的公共函数库 CL_Utility.ps1，剩下 12 个才是动作脚本，全部是明文，可以直接读。诊断类的判定条件逐条摘出来：

• TS_IndexingService.ps1 只有一句核心判断：if ((get-service wsearch).status -ne "Running")，不为 Running 就把根因记为 RC_IndexingService。
• TS_SearchApp.ps1 的判据是缓存目录存不存在：%LOCALAPPDATA%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\AC\INetCache 一旦存在就记为根因 RC_SearchApp（旧版本回退到 Microsoft.Windows.Cortana_cw5n1h2txyewy 同名路径）。
• TS_CheckPermissions.ps1 对索引数据目录提了四条权限要求，原文条件是：Owner 必须等于 NT AUTHORITY\SYSTEM；给 Administrators（S-1-5-32-544）要同时有读和写；给 Users（S-1-5-32-545）必须"既读不到也写不到"，即 -not(Get-AccessGranted ... $GENERIC_READ) 与 -not(... $GENERIC_WRITE)；S-1-5-18（LocalSystem）要有 GENERIC_ALL。它对三个目录分别跑这个检查：数据目录、Applications 子目录、Windows 子目录。任何一条不满足就记 RC_BadPermissions。
• 其余诊断项说明它设想的故障比"搜不到"宽得多：TS_FilterHostCrashing.ps1、TS_ProtocolHostCrashing.ps1、TS_IndexingServiceCrashing.ps1 管三类宿主进程崩溃，TS_ForcedShutdownInRecovery.ps1 与 TS_ForcedShutdownNoCorruption.ps1 管非正常关机后的数据完整性。

修复类脚本的动作更硬，值得看清楚再决定要不要让疑难解答跑：

• RS_StartIndexingService.ps1 先用 WMI 读 win32_baseService where Name='WSearch' 的 StartMode，不是 auto 就调 changeStartMode("automatic")，然后 Start-Service WSearch——它会改启动类型。
• RS_RestoreDefaults.ps1 的注释逐字是 "Reset the SetupCompletedSuccessfully registry value and restart the indexing service (causing service to revert to default settings)"，动作是往 HKLM:\SOFTWARE\Microsoft\Windows Search 写 SetupCompletedSuccessfully 为 0，再 Restart-Service WSearch -Force。
• RS_ResetWindowsSearchApp.ps1 是 12 个动作脚本里最长的一个（3,931 字节、113 行），核心动作是 Stop-Process -Id $processList.Id -Force 加上 Remove-Item -Recurse -Force $folder，删的是 Microsoft.Windows.Search_cw5n1h2txyewy 与 Cortana 两组包目录下的 AC\AppCache、AC\INetCache、AC\INetCookies、AC\INetHistory。

也就是说，那个点两下就跑完的向导，实际会动服务配置、写一个 HKLM 值、强杀搜索界面进程并删它的缓存目录。本机没有让它跑（这些是有副作用的写操作），上面的结论全部来自读脚本原文。

索引该不该重建？先看官方给的四个数量级，再看你拿不拿得到数

performance 那一页给的数量级是排查"索引太大反而搜不好"的尺子，逐字抄下来："On a typical user's computer, the Indexer indexes fewer than 30,000 items. On a power user's computer, the Indexer might index up to 300,000 items. If the Indexer indexes more than 400,000 items, you may begin to see performance issues."，上限一句是："The Indexer can index up to 1 million items. If the Indexer tries to index beyond that limit, it may fail or cause resource problems on the computer (such as high usage of CPU, memory, or disk space)."。另外两条相关阈值：默认会把 Outlook 邮箱一起索引，单个邮箱超过 600 万项就可能拖慢；索引体积大约是被索引内容的 10%（"The index is generally 10 percent of the size of the content that is being indexed."）。

本机 16,427 行落在"典型用户 3 万以内"这一档，而且 16,427 行里有 15,938 行的路径在 C:\用户\HKC\ 之下——最大的一块是 文档\xwechat_files 的 4,756 行，其次是那个开发工具目录 .qoder 下 9,673 行的日志与历史文件。路径含 Program Files 的行数是 0。这两个数字放在一起能说明一件事：索引的大小几乎全被用户数据吃掉，程序安装目录本身从来不在里面。所以"软件装在哪"对搜索几乎没有影响，能影响结果的是快捷方式在不在爬取范围内。

想核对索引数据库体积，官方口径是别信资源管理器"大小"那一栏："To check the size of the index database, use the Size on disk property of the Windows.edb (Windows 10) or Windows.db (Windows 11) file instead of relying on the Size property or the file size that's listed in Explorer."——原因是稀疏文件与压缩算法会让"大小"包含历史分配空间。本机这一步以标准用户身份做不到：Test-Path 对 C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb 返回 False，用 .NET 直接以读方式打开它抛"对路径的访问被拒绝"，C:\ProgramData\Microsoft\Search 这一层只能列出一个 Data 名字。要看体积必须用管理员窗口打开这个目录，或直接在设置页读数字。顺带把两个常见动机分开：本文这条链子解决的是"结果不对"，如果你的目的是给 C 盘腾出空间，本站 C 盘红了怎么办？先弄清空间被谁占走，再按能腾出的量逐个处理 走的是另一套读法，那份数据库在那里的处理动作也和这里不同——这里删它换来的是重建成索引，官方给的时间是"最多 24 小时"。

如果确认要重建，官方给的入口和时间预期都在同一页，逐字是："To make sure that the index reflects your changes, select Settings > Search > Searching Windows > Advanced Search Indexer Settings > Advanced > Rebuild in Windows 10, or select Settings > Privacy & security > Searching Windows > Advanced indexing options > Advanced > Rebuild in Windows 11."，以及时间那句 "Let the Indexer run for up to 24 hours to rebuild the index database."。同页还提供两个比"重建"更温和的动作：Add an excluded folder（把整目录踢出去）和 Advanced > File Types（改某类扩展名怎么被处理，含"只索引属性不索引正文"）。

那一页还有一张 13 行的状态消息对照表，是"设置页那行字到底什么意思"的权威答案，几条常被误读的：Indexing is paused. 的官方解释是索引在设置页被暂停过，处理栏写 "Indexing resumes 15 minutes after it pauses. To resume indexing more quickly, restart the Windows Search service (wsearch)."；Indexing is waiting for computer to become idle. 说明是磁盘或 CPU 太忙导致索引器主动停下；Index is performing maintenance. Please wait. 可以等 30 分钟，且这一条被明确关联到磁盘健康——"Usually, Indexer writing issues precede drive failure. Make sure that the user has backed up personal data."；而最严重的一条是状态文字整个不见、页面变灰，官方说明是索引注册表键或数据库已损坏，处理动作是删除 C:\ProgramData\Microsoft\Search\Data 的全部内容并刷新系统。

同一页还给了一个碎片整理命令串，必须停在管理员权限的服务操作上，本文只转录不执行，因为它第一步就把服务禁用：

Sc config wsearch start=disabled
Net stop wsearch
EsentUtl.exe /d %AllUsersProfile%\Microsoft\Search\Data\Applications\Windows\Windows.edb
Sc config wsearch start=delayed-auto
Net start wsearch

顺带说清"重置"和"重建"不是一回事。微软的 Fix problems in Windows Search 的 Solution 5 是 Reset（恢复默认体验），并在 Note 里逐字保证："Resetting Windows Search doesn't affect your files. However, it may temporarily affect the relevance of search results."，紧接一条 Important："You must have administrator permissions to run this script. If your organization has disabled the ability to run scripts, contact your administrator for help."。Solution 6 则更彻底——删掉 %USERPROFILE%\AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy 整个目录、删 HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search 这个键，再用 Add-AppxPackage -Path ... -DisableDevelopmentMode -Register 重新注册包，最后重启；官方在开头就提示要么用恢复环境、要么先登录另一个账户来操作，并要求"先确认新建成账户上搜索是正常的"。这些都不适合在标准用户下试。

装了的软件，为什么本来就不该出现在开始菜单里？

"开始菜单搜不到已装软件"这句话里有个隐含前提：装了就该能搜到。本机把注册表的卸载登记表和应用列表对了一遍，前提不成立。卸载表里 64 个不重复的 DisplayName 中，能和应用列表那 109 条对上的只有 15 个（例如 Beyond Compare、Google Chrome、Microsoft Edge、NoteEasy 1.0.1、Qoder 0.5.2、微信、腾讯QQ、火绒安全软件），34 个是运行库与组件（Microsoft Visual C++ 2005 到 2026 的各 Redistributable、x86 与 x64 的 Additional Runtime 和 Minimum Runtime、Visual Basic/C++ Runtime、Microsoft Update Health Tools、HEVC Video Extensions、VSTO Runtime、Python 3.12.10 Standard Library 等），剩下 15 个是其它形态（Python 3.12.10 的 9 个分包加 Python Launcher、一条 KB5001716 更新、WPS Office 2023 教育版、迅雷、以及一个名字里就写着"仅用做移除"的证书工具）。也就是说 64 条里近四分之三压根不打算给你一个开始菜单入口。

便携版更极端。本机以四个常用工具做探针——7-Zip、WinSCP、Notepad4、Snipaste，三条通道全 0：应用列表没有、索引里没有同名行、两个开始菜单目录下也没有 .lnk。这类"解压就能用"的软件不写注册表、不建快捷方式，搜索找不到它是设计如此，不是故障。反过来看几个"确实被索引"的样本更有指导性：NoteEasy 在索引里只有 1 行，位置是 C:\用户\HKC\桌面\NoteEasy.lnk，类型 link program；Google Chrome 2 行，一行在公用桌面、一行在机器级开始菜单；Qoder 这个词在索引里能命中 223 行，但取到的第一行是 .qoder\logs\runs\... 下的一个 .log 文件——命中数多不等于应用在里面，这也是前面强调"按路径判断而不是按命中数判断"的原因。

三个微软自己列出的已知问题也要各归各位，它们经常被当成"索引坏了"。Known issues for Windows Desktop Search and Cortana in Windows 10（ms.date 2026-02-12、更新于 2026-02-19，Original KB 3206883）的 Issue 1 逐字是："Desktop Search or Cortana can't find shortcut files (.lnk)"，并补了一句关键的范围说明："The issue occurs regardless of whether the shortcut files are in indexed locations."，状态栏写 "Microsoft is aware of this issue and is investigating it."。Issue 2 关于 .url 文件则是明确的"设计如此"："This is by design. The search filters the results to eliminate noise that's caused by non-app shortcuts."。Issue 3 是唯一"能修"的那种：当 Internet 选项里关掉"允许网站缓存和数据库"时，从开始菜单或 Cortana 搜索会一个结果都没有，官方给的注册表载体是 HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\BrowserStorage\AppCache 下的 AllowWebsiteCaches=0。本机连它的上一级 BrowserStorage 都不存在（Test-Path 两个路径都返回 False），也就是缓存与数据库没被禁用，Issue 3 可以当场排除——这一步值得记住，因为它是整篇里唯一一条"症状与本文无关"的官方疑难，一分钟就能排掉。

至于"服务起不来"那一类，微软给的成因很窄，别把它当万能答案。Cannot start Windows Search service（ms.date 2026-02-12、更新于 2026-02-19，KB 2484025）的症状原文是 "The Windows Search service on local computer started and then stopped. Some services stop automatically if they are not in use by other services or programs"，Cause 只有两条：HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex 的子键或项缺失，或者 C:\windows\system32\config\TxR 里的日志损坏；并特意加了一句 "The above regisrty key is unique to each machine, so should not be replaced manually."（原文就是这个拼写）。Resolution 是删掉 TxR 目录下所有 .BLF 和 .REGTRANS-MS 文件再重启，并预告后果："You may observe High CPU while the Search Index is being rebuilt."。本机前一条可以直接验伪——上一节刚说过这个键下面 SearchRoots、DefaultRules、WorkingSetRules 三个子键都在、规则数 5 与 21 与 21；后一条读不了，C:\Windows\System32\config\TxR 对标准用户既 Test-Path False、列目录又返回"拒绝访问"，这种"假阴加拒绝"的组合本身就该停下来，不要按网上教程去删系统配置目录里的文件。

常见问题 FAQ

我把软件装到 D 盘，是不是因此搜不到？

装在哪不是决定因素。本机索引里路径含 Program Files 的行数为 0，程序安装目录压根不进索引；能被搜到的是指向它的快捷方式和它注册出来的应用条目。真正影响结果的是快捷方式落在哪个开始菜单目录：机器级那个（C:\ProgramData\Microsoft\Windows\Start Menu\Programs）本机 72 个 .lnk 全在索引里，用户级那个（%AppData%\Microsoft\Windows\Start Menu\Programs）本机 20 个 .lnk 在索引里 0 行。

只装给当前用户的软件，怎么让它进索引？

先确认它有没有写快捷方式。本机实测用户级开始菜单不进索引，因此"只在当前用户下安装、只在用户级开始菜单建快捷方式"的程序，索引通道这一头是拿不到它的；能拿到它的是应用列表通道——用 Get-StartApps 查一下，在的话说明它靠 AppUserModelID 登记，搜索里"应用"分组能出结果。既不在应用列表、快捷方式又只放在用户级开始菜单的，才是真的两头都没有。

搜索框输入英文名搜不到，输入中文名就能搜到，正常吗？

在本机是可解释的。索引里存的是本地化显示名：磁盘上的 Notepad.lnk 在索引里是 记事本.lnk，Task Manager.lnk 是 任务管理器.lnk。所以按磁盘上看到的英文文件名去搜，命中的机会取决于程序有没有另写一份可搜索的属性。判断"是不是索引缺这行"，别用文件名比对，按路径去数：机器级开始菜单子树下本机是 108 行，其中 .lnk 72 行、文件夹 26 行、desktop.ini 10 行。

重建索引会不会删掉我的文件？

不会，但会让搜索一段时间不好用。官方对 Reset 的说明逐字是："Resetting Windows Search doesn't affect your files. However, it may temporarily affect the relevance of search results."；对重建的时间预期是 "Let the Indexer run for up to 24 hours to rebuild the index database."。真正要注意的反而是权限那一条：疑难解答里的 TS_CheckPermissions.ps1 要求索引数据目录的 Owner 是 NT AUTHORITY\SYSTEM、Users 组既读不到也写不到；如果你手动"优化"过这些目录的权限，检查会失败并触发它的修复动作。

怎么判断我的机器上有没有发生过"全部索引重置"？

看事件日志，来源 Microsoft-Windows-Search，事件 id 1004 的文本里直接写着原因。本机读到的是 2026-06-17 23:44:37 同秒三条——1008（警告级，"Windows Search 服务正在启动，并尝试删除旧搜索索引{原因: 全部索引重置}。"）、1004（"Windows 搜索服务正在创建新搜索索引{原因: 全部索引重置}。"）与 1010（已成功删除旧搜索索引），23:44:40 出现 1005（已成功创建新搜索索引）。之后到今天只有 1003（服务已启动）这一类，说明这四个半月里没再重建过。

这些脚本会不会改动我的系统？

本文列出的索引侧动作全部只读：Get-StartApps、ADODB 查询、Get-ChildItem、Get-WinEvent、reg query，以及读 C:\Windows\diagnostics\system\Search\ 下的 .ps1 文本。会写系统的是另外三类，都不建议在标准用户下试：设置页的 Rebuild、微软那个需要管理员的 ResetWindowsSearch 脚本、以及 Solution 6 里"删包目录加删 HKCU 的 Search 键加重新注册应用"。

写在最后

两条通道各管一半：应用列表管"装过什么应用"，本机 109 条，用 Get-StartApps 一条命令就能读全；文件索引管"哪些文件和快捷方式被爬到过"，本机 16,427 行，其中 15,938 行在用户目录下、程序安装目录贡献 0 行。所以判断"为什么搜不到"，顺序应当是：先用 Get-StartApps 看它在不在应用列表，再按路径（不是按名字）看索引里有没有那行快捷方式，最后才轮到服务与重建——本机这三层查下来，WSearch 是 Running 加自动（延迟启动）、搜索相关的四个进程（SearchApp、SearchIndexer、SearchProtocolHost、SearchFilterHost）各 1 个实例都在跑、爬取范围一条没改过、策略键一个都没有、索引最近一次重建停在 2026-06-17。至于网上最容易抄的那两个动作，"服务起不来就删 TxR 日志"和"搜不到就重置搜索"，官方文档里都各自有明确前提与权限要求，前者要求先确认是那个每机唯一的注册表键出了问题，后者要求管理员；先把两条通道读一遍，再决定要不要动它们。

本文所有命令、注册表读取与索引查询结果核验于 2026-11-02，以微软官方文档与后续系统版本为准。