Windows 7: A indexação de pesquisa está presa

13

Quando abro Opções de indexação, diz:

4,317 items indexed Indexing in progress. Search results might not be complete during this time.

Está preso em 4.317 embora; nenhum outro item foi indexado. Pior de tudo, o SearchIndexer.exe está ocupando 100% da CPU (bem, 50%, mas eu tenho uma CPU dual core; ela ocupa todo o poder de processamento possível). Não está causando atividade no disco rígido.

Eu tentei clicar em "Solucionar problemas de pesquisa e indexação" na parte inferior da janela Opções de indexação, mas não encontrei nenhum problema.

Eu também tentei a chave de registro de reparo que vários sites sugerem; Eu mudei HKLM \ SOFTWARE \ Microsoft \ Windows Search SetupCompletedSuccessfully para 0 e reiniciei o computador e, aparentemente, reparado porque voltou para 1, mas o mesmo problema continua a ocorrer.

Está reduzindo a vida útil da bateria do meu laptop e tornando-o realmente quente para que meus fãs estejam sempre trabalhando. Eu tive que desativar o serviço Windows Search. Como posso consertar isso? Preciso apenas reformatar meu computador?

Atualização:
Eu tentei reconstruir algumas vezes. Não há nada incomum sobre os locais que eu tenho que indexar, e eu não tenho nenhum download em progresso ou algo assim. Não vejo nenhum motivo para parar e notei que é tarde demais para fazer uma restauração do sistema. Neste ponto, espero que alguém ofereça alguma resposta secreta que conserte o problema, assim a recompensa.

Outra atualização:
Eu tentei iniciar o serviço novamente, apenas para tentar novamente. Pareceu bem no início (Indexing Options mostrou que operava em velocidade reduzida devido à atividade do usuário, e o número de arquivos estava aumentando). Um tempo depois, verifiquei e o serviço tinha parado. O visualizador de eventos revelou alguns erros como este:

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>

Se você está com o mesmo erro e chegou aqui de uma pesquisa no Google, comente ou adicione uma resposta com detalhes sobre seu progresso, se houver ...

    
por Ricket 27.01.2010 / 22:58

6 respostas

8

Acho que você pode estar correto quando diz que há um arquivo corrompido que faz com que ele seja interrompido. Uma maneira grosseira de tentar identificar o arquivo é acessar a guia Arquivos e desativar metade dos tipos de arquivos que estão sendo indexados. Deixe correr. Ou conclui ou pára. Se parar, desligue a metade novamente. Se estiver concluído, você sabe que o tipo de arquivo incorreto está na outra metade. Isso deve permitir identificar o tipo de arquivo incorreto.

Além disso, examine a lista de arquivos indexada. Os tipos de arquivo têm diferentes provedores de pesquisa, como HTML, texto simples e assim por diante. Há algum que pareça fora do lugar, que possa ter sido instalado por algum aplicativo de terceiros?

Outra ideia é deixar a pesquisa pendurada no arquivo 4.317th. Em seguida, execute um prompt de comando. Digite

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

Isso criará um arquivo chamado newt.txt que conterá todos os arquivos e a última vez que eles foram acessados. Acessado, ou seja, lido, não modificado. Você terá que pesquisar o arquivo com um editor de arquivos, mas procure pelos últimos vários arquivos que foram modificados. Se estivermos com sorte, seu arquivo incorreto estará lá. Boa sorte!

    
por 02.02.2010 / 19:52
4

Eu encontrei esta informação em fóruns da Technet

It seems to be a known bug:

  1. PC has two (or multiple) drives or partitions

  2. User profiles and Windows are located on the first drive or partition (assume drive letter C:)

  3. Second drive or partition has more available free disk space than the first (assume drive letter D:)

  4. A ConfigMgr 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the PC Then the Capture User Files and Settings"/"Capture User State" task will succeed, but the "Restore User State"/"Restore User Files and Settings" task will fail.

Resolution

To resolve the problem, the variable OSDStateStorePath has to be changed from its default value. When using MDT 2010/MDT 2010 Update 1 integration, the variable has to be redefined after it has been set by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task.

To ensure that the State Store is saved to the same drive/partition where Windows is installed and the user profiles are located, the environment variable SystemDrive can be used as part of the path that defines the variable OSDStateStorePath.

If MDT 2010/MDT 2010 Update 1 integration is not being used, the "Set Task Sequence Variable" task that sets the variable OSDStateStorePath needs to be modified:

  1. In the ConfigMgr 2007 Admin console, navigate to the Computer Management --> Operating System Deployment --> Task Sequences node.

  2. Right click on the affected Task Sequence and choose "Edit".

  3. Click on the Set Local State Location task. Ensure that the task is a Set Task Sequence Variable task that sets the variable OSDStateStorePath.

Next to the Value: text field, change it from %_SMSTSUserStatePath% to %SystemDrive%\UserState

  1. Click on the "OK" or "Apply" button to save the task sequence. If the "Set Local State Location" task does not exist, then look for a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath, and then make the changes above. If using MDT 2010/MDT 2010 Update 1 integration, then a new "Set Task Sequence Variable" task needs to be added after the "Determine Local or Remote UserState" task that redefines the variable OSDStateStorePath:

  2. In the ConfigMgr 2007 Admin console, navigate to the Computer Management --> Operating System Deployment --> Task Sequences node.

  3. Right click on the affected Task Sequence and choose "Edit".

  4. Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task.

  5. In the newly created "Set Task Sequence Variable Task":

    • Next to the Name: text box, enter in: Set Local State Location
    • Next to the Task Sequence Variable: text box, enter in OSDStateStorePath
    • Next to the Value: text box, enter in: %SystemDrive%\StateStore
  6. Click on the "OK" or "Apply" button to save the task sequence.

If in Step 3 the task "Determine Local or Remote UserState" does not exist or has been renamed, look for the "Run Command Line" task that runs the script ztiuserstate.wsf, and then follow the above steps.

    
por 14.05.2011 / 06:03
4

Primeiramente, tente reconstruir seu índice. Além disso, exclua da indexação de pastas com downloads temporários / não concluídos. Arquivos inacabados são, por definição, corrompidos e podem interromper o processo. Codecs de vídeo / áudio também podem ser interrompidos se a indexação procurar metadados neles.

    
por 28.01.2010 / 01:42
4

Minha pesquisa foi interrompida devido a um arquivo Outlook.pst incorreto. Eu executei o utilitário de reparo pst SCANPST.EXE encontrado no mesmo diretório que o executável do Outlook 2007 ( C:\Program Files (x86)\Microsoft Office\Office12 na minha máquina Windows 7 x64).

    
por 15.03.2010 / 17:24
2

Você verificou que o seu disco rígido não está morrendo?

Clique com o botão direito do mouse na unidade, abra a caixa de diálogo Propriedades, vá para a guia Ferramentas e execute uma verificação de erro (com verificação de setor incorreto).

    
por 04.02.2010 / 00:18
2

Uma das perguntas feitas aqui foi sobre como ver se o SearchIndexer.exe está bloqueado, com falha ou interrompido ou se ainda há progresso. Além disso, seria bom ver qual arquivo está sendo indexado no momento.

Aqui está uma maneira de descobrir.

A Microsoft não oferece ferramentas prontas para isso, os arquivos de log criados durante a pesquisa, como MSS.log (mais tarde copiados e alterados em outros nomes e excluídos), são arquivos binários e não podem ser lidos a menos que com ferramentas especiais.

Outra alternativa que tentei descobrir se estava pendurada em um único arquivo ou não era criar SysInternal's Process Monitor . Eu configurei o filtro da seguinte forma:

  • inclua o processo SearchProtocolHost.exe (nota: não SearchIndexer.exe ),
  • inclua o tipo de evento File System ,
  • exclua qualquer coisa nos diretórios C:\Windows e C:\ProgramData ,
  • e / ou incluir os diretórios que você está realmente indexando,
  • Opcionalmente, defina a operação como ReadFile .
  • clique em Aplicar ou em OK e, em seguida, clique no botão Capturar no canto superior esquerdo.

A exibição de evento resultante fornece todas as operações ReadFile (e algumas outras) que estão sendo lidas atualmente pelo serviço de Indexação de Pesquisa da Microsoft.

Deve haver uma longa lista de ReadFile de operações e os arquivos atualmente indexados estão na coluna Caminho. A coluna Resultado deve mostrar SUCCESS (se não, existe o seu problema) e a coluna Detalhe deve mostrar continuamente um deslocamento diferente (se não, ele está em loop e isso é novamente uma possível dica para a causa do seu problema). / p>     

por 17.07.2014 / 01:07