Windows 7:検索インデックス作成がスタックしている


13

インデックス作成オプションを開くと、次のように表示されます。

4,317項目のインデックス作成中インデックス作成中。この間、検索結果が完全でない場合があります。

ただし、4,317のままです。これ以上アイテムがインデックス付けされていません。最悪なことに、SearchIndexer.exeは100%のCPUを使用しています(まあ、50%ですが、デュアルコアCPUがあり、処理能力をすべて使用しています)。ただし、ハードドライブアクティビティは発生しません。

[インデックスオプション]ウィンドウの下部にある[検索とインデックス作成のトラブルシューティング]をクリックしてみましたが、問題が見つかりませんでした。

また、いくつかのWebサイトが示唆する修復レジストリキーも試しました。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検索からここに到着した場合は、コメントするか、これに関する進捗状況の詳細を回答を追加してください。


4
ところで...この魔法の4,317番目のアイテムが何であるかを理解する方法を知っている人はいますか?システム全体を妨害する不正なファイルが1つだけあるかどうかを知りたいです。
リケット

ESEDatabaseViewと呼ばれる場所を使用してWindows.edbファイルを開くことができます:nirsoft.net/utils/ese_database_view.html
user2924019

回答:


8

ハングする原因となる破損したファイルがあると言うとき、あなたは正しいかもしれないと思います。ファイルを識別するための大まかな方法​​は、[ファイル]タブに移動し、ファイルタイプの半分をインデックスに登録しないようにすることです。実行させてください。完了するか、停止します。停止した場合は、再び半分をオフにします。完了したら、不良ファイルの種類が残りの半分にあることがわかります。これにより、不良ファイルの種類を特定できるはずです。

また、インデックスが作成されているファイルリストを調べます。ファイルタイプには、HTML、プレーンテキストなどのさまざまな検索プロバイダーがあります。サードパーティのアプリケーションによってインストールされた可能性のある、見栄えの悪いものはありますか?

別のアイデアは、検索を4,317番目のファイルで停止させることです。次に、コマンドプロンプトを実行します。タイプ

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

これにより、newt.txtという名前のファイルが作成されます。このファイルには、すべてのファイルと最後にアクセスされた時刻が保持されます。アクセス済み、読み取りを意味し、変更されていません。ファイルエディタでファイルを検索する必要がありますが、最後に変更されたいくつかのファイルを探します。運が良ければ、あなたの悪いファイルはそこにあります。幸運を!


良いヒント(2番目のアイデア)。インデクサーはどこかのファイルのログをどこかにインデックス付けしませんか?最後のファイルが正常にインデックス付けされたことを確認でき、この方法で手がかりを得られるかもしれません。
mtone

@mtone-一度に1つのフォルダーにインデックスを付けることは可能ですか?それは検索を絞り込むでしょう。
ニフレ

@Nifle-はい、それはまた、インデックス付けされたフォルダの数を減らすための合理的な調査になるでしょう。[スタート]メニューで、「インデックス作成」と入力し、インデックス作成オプションをクリックします。このパネルには、インデックスを作成する場所が一覧表示されます。
ノックス

@Knox +1、最初のアイデア。除去[バイナリ]検索を提案しています。そして、欠陥の可能性を理解してそれを修正し、最初にそれらにインデックス付けを制限すると、O(log2 N)の高速化よりもはるかに良くなります。
ElderDelp

4

この情報はTechnetフォーラムで見つけました

それは既知のバグのようです:

  1. PCに2つ(または複数)のドライブまたはパーティションがある

  2. ユーザープロファイルとWindowsは最初のドライブまたはパーティションにあります(ドライブ文字Cを想定しています)。

  3. 2番目のドライブまたはパーティションには、1番目よりも多くの空きディスク容量があります(ドライブ文字Dを想定:)

  4. USMT 4とハードリンクを使用するConfigMgr 2007 OSD更新タスクシーケンスがPCで実行されると、ユーザーファイルと設定のキャプチャ "/"ユーザー状態のキャプチャ "タスクは成功しますが、"ユーザー状態の復元 "/"ユーザーファイルと設定の復元「タスクは失敗します。

解決

この問題を解決するには、変数OSDStateStorePathをデフォルト値から変更する必要があります。MDT 2010 / MDT 2010 Update 1統合を使用する場合、「ローカルまたはリモートUserStateの決定」タスクの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. [OK]または[適用]ボタンをクリックして、タスクシーケンスを保存します。「ローカル状態の場所の設定」タスクが存在しない場合は、変数OSDStateStorePathを設定する「タスクシーケンス変数の設定」タスクを探し、上記の変更を行います。MDT 2010 / MDT 2010 Update 1統合を使用している場合、変数OSDStateStorePathを再定義する「ローカルまたはリモートUserStateの決定」タスクの後に、新しい「タスクシーケンス変数の設定」タスクを追加する必要があります。

  2. ConfigMgr 2007管理コンソールで、Computer Management-> Operating System Deployment-> Task Sequencesノードに移動します。

  3. 影響を受けるタスクシーケンスを右クリックし、[編集]を選択します。

  4. [ローカルまたはリモートUserStateの決定]タスクをクリックして、[追加]-> [全般]-> [タスクシーケンス変数の設定]に移動します。これにより、「ローカルまたはリモートUserStateの決定」タスクの後、「状態ストアの要求」タスクの前に「タスクシーケンス変数の設定」タスクが作成されます。

  5. 新しく作成された「タスクシーケンス変数タスクの設定」で:

    • Name:テキストボックスの横に入力します。Set Local State Location
    • Task Sequence Variable:テキストボックスの横に入力します OSDStateStorePath
    • Value:テキストボックスの横に入力します。%SystemDrive%\StateStore
  6. [OK]または[適用]ボタンをクリックして、タスクシーケンスを保存します。

手順3で「ローカルまたはリモートUserStateの決定」タスクが存在しないか、名前が変更されている場合は、スクリプトztiuserstate.wsfを実行する「コマンドラインの実行」タスクを探し、上記の手順に従います。


4

まず最初に、インデックスを再構築してください。また、一時的/未完了のダウンロードがあるフォルダーのインデックス作成から除外します。未完成のファイルは定義上破損しており、プロセスをハングさせる可能性があります。ビデオ/オーディオコーデックも、インデックス作成でメタデータを検索するとハングする可能性があります。

代替テキスト


メタデータコメントについて詳しく説明してください。何か、どこかでこのことを妨害している場合、それは私がそれを考えるのに役立つかもしれません。
リケット

インデックス作成では、ファイルを調べてメタデータを取得しようとします。AVIムービーファイルなどの一部の種類のファイルでは、これらのファイルを開いて解像度や長さなどを取得するためにコーデック(またはコーデックと呼ばれることも多いコンテナーローダー)が必要です。ファイルが破損すると、そのコーデックがハングする可能性があります。とは言っても、Windows 7ではこれまでこの問題に遭遇していませんが、XPでは一般的な問題でした。
mtone

4

Outlook.pstファイルが正しくないため、検索が停止しました。SCANPST.EXEOutlook 2007実行可能ファイル(C:\Program Files (x86)\Microsoft Office\Office12Windows 7 x64マシン上)と同じディレクトリにあるpst修復ユーティリティを実行しました。

ここに画像の説明を入力してください


1
ファイルの名前はSCANPST.EXE
M.ダドリー

2

ハードドライブが死んでいないことを確認しましたか?

ドライブを右クリックして[プロパティ]ダイアログを開き、[ツール]タブに移動して、エラーチェックを実行します(不良セクタスキャンを使用)。


はい、基本が正しく機能していることを確認することをお勧めします。また、イベントログでシステムエラーを確認します。
ノックス

2

ここで尋ねられた質問の1つは、SearchIndexer.exeがブロックされているか、障害が発生しているか、ハングしているか、またはまだ進行中かどうかを確認する方法についてでした。また、現在どのファイルがインデックス付けされているかを確認するのもいいでしょう。

これを調べる方法を次に示します。

マイクロソフトはこれを表示するためのツールを簡単に提供しません。MSS.logなどの検索中に作成されたログファイル(後でコピーされ、他の名前で変更され、削除されます)はバイナリファイルであり、特別なツールを使用しない限り読み取ることができません。

単一のファイルにハングしているかどうかを確認しようとした別の方法は、SysInternalのProcess Monitorを確認することでした。次のようにフィルターを設定します。

  • インクルードプロセスSearchProtocolHost.exe(注:not SearchIndexer.exe)、
  • イベントタイプを含めるFile System
  • C:\WindowsおよびC:\ProgramDataディレクトリのすべてを除外し、
  • および/または実際にインデックスを作成するディレクトリを含めます。
  • オプションで、Operationをに設定しReadFileます。
  • [適用]または[OK]をクリックしてから、左上の[キャプチャ]ボタンをクリックします。

結果のイベントビューにはReadFile、Microsoft Search Indexサービスによって現在読み取られているすべての操作(およびその他の操作)が表示されます。

ReadFile操作の長いリストである必要があり、現在インデックス付けされているファイルは[パス]列にあります。[結果]列にSUCCESS(ない場合は問題があります)、[詳細]列には別のオフセットが連続して表示されます(ない場合はループしています。これは、問題の原因の可能性のあるヒントです)。


1
+1 @Able Sys | nternalsのリンクは引き続き機能します! これは、フルのSysinternals Suiteのを提供します別のものである
ElderDelp
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.