Windows 7: l'indexation de la recherche est bloquée

Lorsque j'ouvre les options d'indexation, il dit:

4 317 éléments indexés Indexation en cours. Les résultats de la recherche peuvent ne pas être complets pendant cette période.

Il est cependant bloqué à 4 317; aucun autre élément n'a été indexé. Pire encore, SearchIndexer.exe utilise 100% de CPU (enfin, 50%, mais j'ai un CPU dual core; il utilise toute la puissance de traitement qu'il peut). Cependant, cela ne provoque pas d'activité sur le disque dur.

J'ai essayé de cliquer sur "Résoudre les problèmes de recherche et d'indexation" en bas de la fenêtre Options d'indexation, mais il n'a trouvé aucun problème.

J'ai également essayé la clé de registre de réparation suggérée par plusieurs sites Web; J'ai changé HKLM \ SOFTWARE \ Microsoft \ Windows Search SetupCompletedSuccessfully à 0 et redémarré l'ordinateur, et il a apparemment réparé car il est retourné à 1, mais le même problème continue de se produire.

Cela réduit la durée de vie de la batterie de mon ordinateur portable et le rend très chaud pour que mes fans fonctionnent tout le temps. J'ai dû désactiver le service de recherche Windows. Comment puis-je réparer cela? Dois-je simplement reformater mon ordinateur?

Mise à jour:
j'ai essayé de reconstruire plusieurs fois. Il n'y a rien d'inhabituel dans les emplacements que je dois indexer, et je n'ai aucun téléchargement en cours ou quelque chose comme ça. Je ne vois aucune raison pour laquelle cela s'est arrêté, et je l'ai remarqué beaucoup trop tard pour effectuer une restauration du système. À ce stade, j'espère que quelqu'un offrira une réponse secrète qui résoudra le problème, donc la prime.

Autre mise à jour:
j'ai essayé de redémarrer le service, juste pour le laisser essayer à nouveau. Cela semblait correct au début (les options d'indexation ont montré qu'il fonctionnait à une vitesse réduite en raison de l'activité de l'utilisateur et que le nombre de fichiers augmentait). Un peu plus tard, j'ai vérifié et le service s'était arrêté. L'observateur d'événements a révélé des erreurs comme celle-ci:

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>

Si vous rencontrez la même erreur et êtes arrivé ici à partir d'une recherche Google, veuillez commenter ou ajouter une réponse détaillant vos progrès à ce sujet, le cas échéant ...

Je pense que vous pourriez avoir raison lorsque vous dites qu'il y a un fichier corrompu qui le fait se bloquer. Une façon grossière d'essayer d'identifier le fichier est d'aller dans l'onglet fichiers et de désactiver l'indexation de la moitié des types de fichiers. Laissez-le courir. Soit il se termine, soit il s'arrête. S'il s'arrête, éteignez à nouveau la moitié. S'il se termine, vous savez que le mauvais type de fichier se trouve dans l'autre moitié. Cela devrait vous permettre d'identifier le mauvais type de fichier.

Consultez également la liste des fichiers indexés. Les types de fichiers ont différents fournisseurs de recherche, comme HTML, texte brut, etc. Y en a-t-il qui semblent hors de propos, qui pourraient avoir été installés par une application tierce?

Une autre idée est de laisser la recherche se bloquer sur le 4 317e fichier. Exécutez ensuite une invite de commande. Type

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

Cela va créer un fichier nommé newt.txt qui contiendra tous les fichiers et la dernière fois qu'ils ont été accédés. Consulté, c'est-à-dire lu, non modifié. Vous devrez rechercher dans le fichier avec un éditeur de fichiers, mais recherchez les derniers fichiers modifiés. Si nous avons de la chance, votre mauvais fichier sera là. Bonne chance!

J'ai trouvé ces informations sur les forums Technet

Il semble que ce soit un bug connu:

1. Le PC a deux (ou plusieurs) disques ou partitions

2. Les profils utilisateur et Windows se trouvent sur le premier lecteur ou la première partition (supposez que la lettre de lecteur C :)

3. Le deuxième lecteur ou partition a plus d'espace disque disponible que le premier (supposez que la lettre de lecteur D :)

4. Une séquence de tâches d'actualisation de l'OSD ConfigMgr 2007 qui utilise USMT 4 avec liaison fixe est exécutée sur le PC. "la tâche échouera.

Résolution

Pour résoudre le problème, la variable OSDStateStorePath doit être modifiée par rapport à sa valeur par défaut. Lorsque vous utilisez l'intégration MDT 2010 / MDT 2010 Update 1, la variable doit être redéfinie après avoir été définie par le script ztiuserstate.wsf dans la tâche "Déterminer l'état utilisateur local ou distant".

Pour garantir que le State Store est enregistré sur le même lecteur / partition sur lequel Windows est installé et que les profils utilisateur sont situés, la variable d'environnement SystemDrive peut être utilisée dans le cadre du chemin d'accès qui définit la variable OSDStateStorePath.

Si l'intégration de MDT 2010 / MDT 2010 Update 1 n'est pas utilisée , la tâche "Définir la variable de séquence de tâches" qui définit la variable OSDStateStorePath doit être modifiée:

1. Dans la console d'administration ConfigMgr 2007, accédez au nœud Computer Management-> Operating System Deployment-> Task Sequences.

2. Faites un clic droit sur la séquence de tâches affectée et choisissez "Modifier".

3. Cliquez sur la Set Local State Locationtâche. Assurez-vous que la tâche est une Set Task Sequence Variabletâche qui définit la variable OSDStateStorePath.

À côté du Value:champ de texte, changez-le de %_SMSTSUserStatePath% en%SystemDrive%\UserState

4. Cliquez sur le bouton "OK" ou "Appliquer" pour enregistrer la séquence de tâches. Si la tâche "Définir l'emplacement de l'état local" n'existe pas, recherchez une tâche "Définir la variable de séquence de tâches" qui définit la variable OSDStateStorePath, puis apportez les modifications ci-dessus. Si vous utilisez l'intégration MDT 2010 / MDT 2010 Update 1, une nouvelle tâche "Définir la variable de séquence de tâches" doit être ajoutée après la tâche "Déterminer l'état utilisateur local ou distant" qui redéfinit la variable OSDStateStorePath:

5. Dans la console d'administration ConfigMgr 2007, accédez au nœud Computer Management-> Operating System Deployment-> Task Sequences.

6. Faites un clic droit sur la séquence de tâches affectée et choisissez "Modifier".

7. Cliquez sur la tâche "Déterminer l'état utilisateur local ou distant" puis allez dans "Ajouter" -> "Général" -> "Définir la variable de séquence de tâches". Cela doit créer une tâche "Définir la variable de séquence de tâches" après la tâche "Déterminer l'état utilisateur local ou distant" mais avant la tâche "Demander un magasin d'état".

8. Dans la nouvelle tâche "Définir la tâche variable de séquence de tâches":

   • À côté de la zone de Name:texte, entrez:Set Local State Location
   • À côté de la zone de Task Sequence Variable:texte, entrez OSDStateStorePath
   • À côté de la zone de Value:texte, entrez:%SystemDrive%\StateStore

9. Cliquez sur le bouton "OK" ou "Appliquer" pour enregistrer la séquence de tâches.

Si, à l'étape 3, la tâche «Déterminer l'état utilisateur local ou distant» n'existe pas ou a été renommée, recherchez la tâche «Exécuter la ligne de commande» qui exécute le script ztiuserstate.wsf, puis suivez les étapes ci-dessus.

Tout d'abord, essayez de reconstruire votre index. En outre, excluez de l'indexation tous les dossiers contenant des téléchargements temporaires / incomplets. Les fichiers inachevés sont par définition corrompus et pourraient bloquer le processus. Les codecs vidéo / audio peuvent également se bloquer si l'indexation y recherche des métadonnées.

Ma recherche a été bloquée en raison d'un mauvais fichier Outlook.pst. J'ai exécuté l'utilitaire de réparation pst SCANPST.EXEtrouvé dans le même répertoire que l'exécutable Outlook 2007 ( C:\Program Files (x86)\Microsoft Office\Office12sur ma machine Windows 7 x64.)

Avez-vous vérifié que votre disque dur ne meurt pas?

Cliquez avec le bouton droit sur le lecteur, ouvrez la boîte de dialogue Propriétés, accédez à l'onglet Outils et effectuez une vérification d'erreur (avec une mauvaise numérisation de secteur).

L'une des questions posées ici portait sur la façon de voir si SearchIndexer.exe est bloqué, défectueux ou bloqué, ou s'il y a encore des progrès. Il serait également intéressant de voir quel fichier est actuellement indexé.

Voici un moyen de le découvrir.

Microsoft ne vous donne pas facilement des outils pour afficher cela, les fichiers journaux créés pendant la recherche, comme MSS.log (plus tard copiés et modifiés sous d'autres noms, puis supprimés) sont des fichiers binaires et ne peuvent être lus qu'avec des outils spéciaux.

Une autre alternative, j'ai essayé de savoir s'il était suspendu à un seul fichier ou non, c'était de contrôler le Process Monitor de SysInternal . J'ai réglé le filtre comme suit:

• inclure le processus SearchProtocolHost.exe(note: non SearchIndexer.exe ),
• inclure le type d'événement File System,
• exclure quoi que ce soit sur les répertoires C:\Windowset C:\ProgramData,
• et / ou inclure les répertoires que vous indexez réellement,
• définissez éventuellement Operation sur ReadFile.
• cliquez sur Appliquer ou OK, puis sur le bouton Capture en haut à gauche.

La vue des événements qui en résulte vous donne toutes les ReadFileopérations (et quelques autres) qui sont actuellement lues par le service d'index de recherche Microsoft.

Il doit s'agir d'une longue liste d' ReadFileopérations et les fichiers en cours d'indexation se trouvent dans la colonne Chemin. La colonne Résultat doit afficher SUCCESS(sinon, il y a votre problème) et la colonne Détail doit afficher en continu un décalage différent (sinon, il est en boucle, et c'est encore une indication possible de la cause de votre problème).