Windows 7:搜索索引卡住

Windows 7:搜索索引卡住

当我打开索引选项时,它显示:

4,317 个项目已编入索引 正在编入索引。在此期间搜索结果可能不完整。

但是它停留在 4,317 上;没有更多的项目被索引。最糟糕的是,SearchIndexer.exe 占用了 100% 的 CPU(好吧,50%,但我有一个双核 CPU;它占用了它能占用的所有处理能力)。但是它不会引起硬盘活动。

我尝试单击索引选项窗口底部的“搜索和索引疑难解答”,但没有发现任何问题。

我也尝试了几个网站建议的修复注册表项;我将 HKLM\SOFTWARE\Microsoft\Windows Search SetupCompletedSuccessfully 更改为 0 并重新启动计算机,并且它显然已修复,因为它翻转回 1,但同样的问题仍然存在。

它缩短了我笔记本电脑的电池寿命,并且使它变得非常热,以至于我的风扇一直在运转。我不得不禁用 Windows Search 服务。我该如何解决这个问题?我是否需要彻底重新格式化我的电脑?


更新:
我尝试重建了几次。索引的位置没有任何异常,我没有任何正在进行的下载或类似的东西。我看不出它停止的原因,而且我发现进行系统还原已经太晚了。此时,我希望有人能提供一些可以解决问题的秘密答案,因此悬赏。


另一个更新:
我尝试再次启动该服务,只是为了让它再试一次。一开始看起来还不错(索引选项显示由于用户活动,它的运行速度降低了,文件数量正在增加)。过了一会儿,我检查了一下,发现该服务已经停止了。事件查看器显示了如下错误:

Log Name:      Application
Source:        Application Error
Date:          2/1/2010 7:34:23 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ricky-win7
Description:
Faulting application name: SearchIndexer.exe, version: 7.0.7600.16385, time stamp: 0x4a5bcdd0
Faulting module name: NLSData0007.dll, version: 6.1.7600.16385, time stamp: 0x4a5bda88
Exception code: 0xc0000005
Fault offset: 0x002141ba
Faulting process id: 0x13a0
Faulting application start time: 0x01caa39f2a70ec02
Faulting application path: C:\Windows\system32\SearchIndexer.exe
Faulting module path: C:\Windows\System32\NLSData0007.dll
Report Id: b4f7a7ae-0f92-11df-87fc-e5d65d8794c2
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2010-02-02T00:34:23.000000000Z" />
    <EventRecordID>10689</EventRecordID>
    <Channel>Application</Channel>
    <Computer>ricky-win7</Computer>
    <Security />
  </System>
  <EventData>
    <Data>SearchIndexer.exe</Data>
    <Data>7.0.7600.16385</Data>
    <Data>4a5bcdd0</Data>
    <Data>NLSData0007.dll</Data>
    <Data>6.1.7600.16385</Data>
    <Data>4a5bda88</Data>
    <Data>c0000005</Data>
    <Data>002141ba</Data>
    <Data>13a0</Data>
    <Data>01caa39f2a70ec02</Data>
    <Data>C:\Windows\system32\SearchIndexer.exe</Data>
    <Data>C:\Windows\System32\NLSData0007.dll</Data>
    <Data>b4f7a7ae-0f92-11df-87fc-e5d65d8794c2</Data>
  </EventData>
</Event>

如果您遇到同样的错误并通过 Google 搜索来到这里,请发表评论或添加答案,详细说明您的进展(如果有)...

答案1

我认为你说的可能是因为有一个损坏的文件导致它挂起。尝试识别文件的一个粗略方法是转到文件选项卡并关闭一半文件类型的索引。让它运行。它要么完成,要么停止。如果它停止,再关闭一半。如果它完成,你就知道另一半是坏文件类型。这样做应该可以让你识别坏文件类型。

另外,查看已编入索引的文件列表。文件类型有不同的搜索提供程序,如 HTML、纯文本等。是否有任何看起来不合适的文件,可能是由某些第三方应用程序安装的?

另一个想法是让搜索停留在第 4,317 个文件上。然后运行命令提示符。输入

CD c:\
DIR /s /TA /O-D >c:\newt.txt

这将创建一个名为 newt.txt 的文件,其中包含所有文件及其上次访问时间。访问,即读取,而不是修改。您必须使用文件编辑器搜索文件,但要查找最后修改的几个文件。如果我们运气好的话,您的坏文件就在那里。祝你好运!

答案2

我在以下网址找到了此信息Technet 论坛

这似乎是一个已知的错误:

  1. PC 有两个(或多个)驱动器或分区

  2. 用户配置文件和 Windows 位于第一个驱动器或分区(假设驱动器号为 C:)

  3. 第二个驱动器或分区比第一个驱动器或分区具有更多的可用磁盘空间(假设驱动器号为 D:)

  4. 在 PC 上运行使用带硬链接的 USMT 4 的 ConfigMgr 2007 OSD 刷新任务序列,然后“捕获用户文件和设置”/“捕获用户状态”任务将会成功,但“还原用户状态”/“还原用户文件和设置”任务将会失败。

解决

要解决该问题,必须将变量 OSDStateStorePath 从其默认值更改。使用 MDT 2010/MDT 2010 Update 1 集成时,必须在“确定本地或远程用户状态”任务中通过 ztiuserstate.wsf 脚本设置该变量后重新定义该变量。

为了确保状态存储保存到安装 Windows 和用户配置文件所在的同一驱动器/分区,可以将环境变量 SystemDrive 用作定义变量 OSDStateStorePath 的路径的一部分。

如果 MDT 2010/MDT 2010 Update 1 集成未被使用,设置变量OSDStateStorePath的“设置任务序列变量”任务需要修改:

  1. 在 ConfigMgr 2007 管理控制台中,导航到Computer Management--> Operating System Deployment-->Task Sequences节点。

  2. 右键单击受影响的任务序列并选择“编辑”。

  3. 点击该Set Local State Location任务。确保该任务是Set Task Sequence Variable设置变量的任务 OSDStateStorePath

在文本字段旁边Value:,将其从 更改%_SMSTSUserStatePath%%SystemDrive%\UserState

  1. 单击“确定”或“应用”按钮保存任务序列。如果“设置本地状态位置”任务不存在,则查找设置变量 OSDStateStorePath 的“设置任务序列变量”任务,然后进行上述更改。如果使用 MDT 2010/MDT 2010 Update 1 集成,则需要在重新定义变量 OSDStateStorePath 的“确定本地或远程用户状态”任务后添加新的“设置任务序列变量”任务:

  2. 在 ConfigMgr 2007 管理控制台中,导航到Computer Management--> Operating System Deployment-->Task Sequences节点。

  3. 右键单击受影响的任务序列并选择“编辑”。

  4. 单击“确定本地或远程用户状态”任务,然后转到“添加”-->“常规”-->“设置任务序列变量”。这将在“确定本地或远程用户状态”任务之后但在“请求状态存储”任务之前创建一个“设置任务序列变量”任务。

  5. 在新创建的“设置任务序列变量任务”中:

    • 在文本框旁边Name:输入:Set Local State Location
    • 在文本框旁边Task Sequence Variable:输入 OSDStateStorePath
    • 在文本框旁边Value:输入:%SystemDrive%\StateStore
  6. 单击“确定”或“应用”按钮保存任务序列。

如果在步骤 3 中任务“确定本地或远程用户状态”不存在或已被重命名,请查找运行脚本 ztiuserstate.wsf 的“运行命令行”任务,然后按照上述步骤操作。

答案3

首先,尝试重建索引。此外,从索引中排除任何包含临时/未完成下载的文件夹。未完成的文件按定义已损坏,可能会挂起该过程。如果索引查找视频/音频编解码器中的元数据,也可能会挂起。

替代文本

答案4

这里提出的一个问题是如何查看 SearchIndexer.exe 是否被阻止、出现故障或挂起,或者是否仍有进展。此外,如果能看到当前正在索引哪些文件,那就太好了。

以下是一种查找方法。

微软并没有提供给你查看这些内容的工具,搜索过程中创建的日志文件,比如 MSS.log(后来被复制并更改为其他名称,然后被删除)是二进制文件,除非使用特殊工具,否则无法读取。

我尝试的另一种方法是查看它是否挂在单个文件上SysInternal 的进程监视器。我设置过滤器如下:

  • 包括流程SearchProtocolHost.exe(注意:不是 SearchIndexer.exe),
  • 包括事件类型File System
  • 排除C:\WindowsC:\ProgramData目录上的任何内容,
  • 和/或包括您实际索引的目录,
  • 可选择将操作设置为ReadFile
  • 单击“应用”或“确定”,然后单击左上角的“捕获”按钮。

生成的事件视图为您提供了ReadFileMicrosoft Search Index 服务当前正在读取的所有操作(以及一些其他操作)。

它应该是一个很长的操作列表ReadFile,当前正在索引的文件位于 Path 列中。Result 列应该显示SUCCESS(如果没有,那就是您的问题),Detail 列应该持续显示不同的偏移量(如果没有,那就是循环,这又可能是导致问题的原因)。

相关内容