Windows 7: Die Indizierung der Suche bleibt hängen

Wenn ich die Indizierungsoptionen öffne, heißt es:

4.317 indizierte Artikel Indizierung in Bearbeitung. Die Suchergebnisse sind in dieser Zeit möglicherweise nicht vollständig.

Es steckt jedoch bei 4.317 fest; Es wurden keine weiteren Elemente indiziert. Am schlimmsten ist, dass SearchIndexer.exe 100% der CPU beansprucht (naja, 50%, aber ich habe eine Dual-Core-CPU; es beansprucht die gesamte Rechenleistung, die es kann). Es verursacht jedoch keine Festplattenaktivität.

Ich habe versucht, im unteren Bereich des Fensters "Indizierungsoptionen" auf "Fehlerbehebung bei Suche und Indizierung" zu klicken, konnte jedoch kein Problem feststellen.

Ich habe auch den Reparatur-Registrierungsschlüssel ausprobiert, den mehrere Websites vorschlagen. Ich ändere HKLM \ SOFTWARE \ Microsoft \ Windows Search SetupCompletedSuccessfully auf 0 und starte den Computer neu, und es wurde anscheinend repariert, weil es wieder auf 1 zurückgesetzt wurde, aber das gleiche Problem tritt weiterhin auf.

Dadurch wird die Akkulaufzeit meines Laptops verkürzt und es wird sehr heiß, sodass meine Fans die ganze Zeit laufen. Ich musste den Windows-Suchdienst deaktivieren. Wie kann ich das beheben? Muss ich meinen Computer nur komplett neu formatieren?

Update:
Ich habe ein paar Mal versucht, neu zu erstellen. Es gibt nichts Ungewöhnliches an den Orten, die ich indizieren muss, und ich habe noch keine Downloads im Gange oder ähnliches. Ich sehe keinen Grund, warum es aufgehört hat, und ich habe bemerkt, dass es viel zu spät ist, um eine Systemwiederherstellung durchzuführen. An diesem Punkt hoffe ich, dass jemand eine geheime Antwort anbietet, die das Problem und damit das Kopfgeld behebt.

Noch ein Update:
Ich habe versucht, den Dienst erneut zu starten, nur um es noch einmal versuchen zu lassen. Anfangs schien es in Ordnung zu sein (Indizierungsoptionen zeigten, dass es aufgrund der Benutzeraktivität mit reduzierter Geschwindigkeit lief und die Anzahl der Dateien stieg). Eine Weile später überprüfte ich, und der Dienst hatte aufgehört. Die Ereignisanzeige hat einige Fehler wie diesen aufgedeckt:

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>

Wenn Sie den gleichen Fehler haben und von einer Google-Suche hierher gekommen sind, kommentieren Sie oder fügen Sie eine Antwort hinzu, in der Ihr Fortschritt dazu aufgeführt ist, falls vorhanden ...

Ich denke, Sie könnten richtig liegen, wenn Sie sagen, dass eine beschädigte Datei dazu führt, dass sie hängt. Eine einfache Möglichkeit, die Datei zu identifizieren, besteht darin, die Registerkarte "Dateien" zu öffnen und die Indizierung der Hälfte der Dateitypen zu deaktivieren. Lass es laufen. Entweder wird es beendet oder es wird gestoppt. Wenn es aufhört, schalten Sie die Hälfte wieder aus. Wenn es abgeschlossen ist, wissen Sie, dass sich der fehlerhafte Dateityp in der anderen Hälfte befindet. Auf diese Weise können Sie den fehlerhaften Dateityp identifizieren.

Sehen Sie sich auch die indizierte Dateiliste an. Dateitypen haben unterschiedliche Suchanbieter wie HTML, Nur-Text und so weiter. Gibt es welche, die nicht am richtigen Ort sind, die möglicherweise von einer Drittanbieteranwendung installiert wurden?

Eine andere Idee ist, die Suche an der 4.317. Datei hängen zu lassen. Führen Sie dann eine Eingabeaufforderung aus. Art

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

Dadurch wird eine Datei mit dem Namen newt.txt erstellt, die alle Dateien und den letzten Zugriff enthält. Zugriff, dh gelesen, nicht geändert. Sie müssen die Datei mit einem Datei-Editor durchsuchen, aber nach den letzten Dateien suchen, die geändert wurden. Wenn wir Glück haben, ist Ihre schlechte Akte da. Viel Glück!

Ich habe diese Informationen in Technet-Foren gefunden

Es scheint ein bekannter Fehler zu sein:

1. Der PC verfügt über zwei (oder mehrere) Laufwerke oder Partitionen

2. Benutzerprofile und Windows befinden sich auf dem ersten Laufwerk oder der ersten Partition (Laufwerksbuchstabe C vorausgesetzt :)

3. Das zweite Laufwerk oder die zweite Partition verfügt über mehr freien Speicherplatz als das erste (Laufwerksbuchstabe D vorausgesetzt :)

4. Auf dem PC wird eine ConfigMgr 2007-Tasksequenz zur OSD-Aktualisierung ausgeführt, die USMT 4 mit fester Verknüpfung verwendet. Anschließend wird die Task "Benutzerdateien und -einstellungen erfassen" / "Benutzerstatus erfassen" erfolgreich ausgeführt, die Task "Benutzerstatus wiederherstellen" / "Benutzerdateien und -einstellungen wiederherstellen" "Aufgabe wird fehlschlagen.

Auflösung

Um das Problem zu beheben, muss die Variable OSDStateStorePath von ihrem Standardwert geändert werden. Bei Verwendung der MDT 2010 / MDT 2010 Update 1-Integration muss die Variable neu definiert werden, nachdem sie vom Skript ztiuserstate.wsf in der Task "Ermitteln des lokalen oder Remote-Benutzerzustands" festgelegt wurde.

Um sicherzustellen, dass der Zustandsspeicher auf demselben Laufwerk / derselben Partition gespeichert wird, auf dem Windows installiert ist und auf der sich die Benutzerprofile befinden, kann die Umgebungsvariable SystemDrive als Teil des Pfads verwendet werden, der die Variable OSDStateStorePath definiert.

Wenn die MDT 2010 / MDT 2010 Update 1-Integration nicht verwendet wird , muss die Task "Tasksequenzvariable festlegen", mit der die Variable OSDStateStorePath festgelegt wird, geändert werden:

1. Navigieren Sie in der ConfigMgr 2007-Verwaltungskonsole zum Knoten Computer Management-> Operating System Deployment-> Task Sequences.

2. Klicken Sie mit der rechten Maustaste auf die betroffene Tasksequenz und wählen Sie "Bearbeiten".

3. Klicken Sie auf die Set Local State LocationAufgabe. Stellen Sie sicher, dass die Aufgabe eine Set Task Sequence VariableAufgabe ist, die die Variable festlegt OSDStateStorePath.

Value:Ändern Sie es neben dem Textfeld von %_SMSTSUserStatePath% in%SystemDrive%\UserState

4. Klicken Sie auf die Schaltfläche "OK" oder "Übernehmen", um die Tasksequenz zu speichern. Wenn der Task "Set Local State Location" nicht vorhanden ist, suchen Sie nach einem Task "Set Task Sequence Variable", der die Variable OSDStateStorePath festlegt, und nehmen Sie die obigen Änderungen vor. Wenn Sie die MDT 2010 / MDT 2010 Update 1-Integration verwenden, muss nach der Task "Lokaler oder Remote-UserState ermitteln", mit der die Variable OSDStateStorePath neu definiert wird, eine neue Task "Tasksequenzvariable festlegen" hinzugefügt werden:

5. Navigieren Sie in der ConfigMgr 2007-Verwaltungskonsole zum Knoten Computer Management-> Operating System Deployment-> Task Sequences.

6. Klicken Sie mit der rechten Maustaste auf die betroffene Tasksequenz und wählen Sie "Bearbeiten".

7. Klicken Sie auf die Aufgabe "Lokaler oder entfernter UserState ermitteln" und gehen Sie dann zu "Hinzufügen" -> "Allgemein" -> "Tasksequenzvariable festlegen". Dies sollte eine Task "Set Task Sequence Variable" nach der Task "Determine Local oder Remote UserState", aber vor der Task "Request State Store" erstellen.

8. In der neu erstellten "Set Task Sequence Variable Task":

   • Geben Sie neben dem Name:Textfeld Folgendes ein:Set Local State Location
   • Geben Sie neben dem Task Sequence Variable:Textfeld in ein OSDStateStorePath
   • Geben Sie neben dem Value:Textfeld Folgendes ein:%SystemDrive%\StateStore

9. Klicken Sie auf die Schaltfläche "OK" oder "Übernehmen", um die Tasksequenz zu speichern.

Wenn in Schritt 3 die Aufgabe "Bestimmen des lokalen oder Remote-Benutzerzustands" nicht vorhanden ist oder umbenannt wurde, suchen Sie nach der Aufgabe "Befehlszeile ausführen", in der das Skript ztiuserstate.wsf ausgeführt wird, und führen Sie dann die obigen Schritte aus.

Versuchen Sie zuerst, Ihren Index neu zu erstellen. Schließen Sie außerdem alle Ordner mit temporären / nicht abgeschlossenen Downloads von der Indizierung aus. Unvollendete Dateien sind per Definition beschädigt und können den Prozess zum Erliegen bringen. Video- / Audio-Codecs können auch hängen bleiben, wenn bei der Indizierung Metadaten in ihnen gesucht werden.

Meine Suche blieb aufgrund einer fehlerhaften Outlook.pst-Datei hängen. Ich habe das Dienstprogramm pst repair ausgeführt, das SCANPST.EXEsich im selben Verzeichnis wie die ausführbare Datei von Outlook 2007 befindet ( C:\Program Files (x86)\Microsoft Office\Office12auf meinem Windows 7 x64-Computer).

Haben Sie überprüft, dass Ihre Festplatte nicht stirbt?

Klicken Sie mit der rechten Maustaste auf das Laufwerk, öffnen Sie das Dialogfeld "Eigenschaften", wechseln Sie zur Registerkarte "Extras" und führen Sie eine Fehlerprüfung durch (bei fehlerhaftem Sektor-Scan).

Eine der hier gestellten Fragen betraf die Frage, wie festgestellt werden kann, ob die SearchIndexer.exe blockiert ist, einen Fehler aufweist oder hängt oder ob noch ein Fortschritt vorliegt. Außerdem wäre es schön zu sehen, welche Datei gerade indiziert wird.

Hier ist eine Möglichkeit, dies herauszufinden.

Microsoft stellt Ihnen keine Tools zum Anzeigen dieser Informationen zur Verfügung. Die während der Suche erstellten Protokolldateien wie MSS.log (die später kopiert und in anderen Namen geändert und dann gelöscht werden) sind Binärdateien und können nur mit speziellen Tools gelesen werden.

Eine andere Alternative, die ich versuchte herauszufinden, ob es an einer einzelnen Datei hing oder nicht, war SysInternals Prozessmonitor aufzurufen . Ich habe den Filter wie folgt eingestellt:

• Include-Prozess SearchProtocolHost.exe(Anmerkung: nicht SearchIndexer.exe ),
• Ereignistyp einschließen File System,
• schließe irgendetwas in den Verzeichnissen C:\Windowsund aus C:\ProgramData,
• und / oder die Verzeichnisse enthalten, die Sie tatsächlich indizieren,
• optional setzen Sie Operation auf ReadFile.
• Klicken Sie auf Übernehmen oder OK und dann oben links auf die Schaltfläche Aufzeichnen.

Die resultierende Ereignisansicht enthält alle ReadFileVorgänge (und einige andere), die derzeit vom Microsoft Search-Indexdienst gelesen werden.

Es sollte sich um eine lange Liste von ReadFileVorgängen handeln, und die aktuell indizierten Dateien befinden sich in der Spalte Pfad. In der Ergebnisspalte sollte angezeigt werden SUCCESS(wenn nicht, liegt Ihr Problem vor) und in der Detailspalte sollte ständig ein anderer Versatz angezeigt werden (wenn nicht, wird eine Schleife ausgeführt, und dies ist wiederum ein möglicher Hinweis auf die Ursache Ihres Problems).