Windows 7: індексація пошуку застрягла


13

Коли я відкриваю опції індексування, у ньому йдеться:

Індексовано 4,317 елементів   Триває індексація. Результати пошуку можуть бути не завершені протягом цього часу.

Це приклеєне у 4.317 хоч; більше не було індексовано. Найгірше те, що SearchIndexer.exe займає 100% процесора (ну, 50%, але у мене є двоядерний процесор; він бере на себе всю обробну потужність). Хоча це не викликає активності жорсткого диска.

Я спробував натиснути "Виправлення неполадок пошуку та індексування" внизу вікна "Параметри індексування", але не вдалося знайти жодної проблеми.

Я також спробував ключ реєстру ремонту, який пропонують кілька веб-сайтів; Я змінюю HKLM ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ Microsoft Search SetupCompletedУспішно до 0 і перезавантажив комп'ютер, і він, мабуть, відремонтований, тому що він перевернувся назад до 1, але та ж проблема продовжує відбуватися.

Це скорочує час автономної роботи мого ноутбука і робить його дуже гарячим, щоб мої вболівальники працювали весь час. Мені довелося вимкнути службу пошуку Windows. Як це можна виправити? Чи потрібно мені просто переформатувати комп'ютер?


Оновити:
Я спробував відновити пару разів. Немає нічого незвичайного в місцях, які я повинен індексувати, і у мене немає жодних завантажень або щось подібне. Я не бачу ніякої причини, чому він зупинився, і я помітив, що занадто пізно зробити відновлення системи. На даний момент, я сподіваюся, що хтось запропонує якийсь секретний відповідь, який вирішить проблему, таким чином, щедрість.


Інше оновлення:
Я спробував запустити службу ще раз, щоб просто спробувати ще раз. Спочатку здавалося, що це нормально (параметри індексування показали, що він працює на зниженій швидкості через активність користувача, і кількість файлів зростала). Через деякий час я перевірив, і служба зупинилася. Програма перегляду подій виявила такі помилки:

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
До речі ... Хто-небудь знає спосіб розібратися, що це за магічний пункт? Мені дуже хотілося б знати, чи є один файл з пошкодженою системою.
Ricket

Ви можете відкрити файл Windows.edb, використовуючи дещо назву ESEDatabaseView тут: nirsoft.net/utils/ese_database_view.html
user2924019

Відповіді:


8

Я думаю, ви можете бути вірні, коли ви говорите, що є пошкоджений файл, який викликає його зависання. Суворим способом виявлення файлу є вкладка файлів і вимкнення половини типів файлів з індексування. Нехай вона запускається. Або він закінчується, або він зупиняється. Якщо він зупиниться, знову вимкніть половину. Якщо це завершиться, ви знаєте, що поганий тип файлу знаходиться в іншій половині. Це дозволить визначити поганий тип файлу.

Крім того, перегляньте список індексованих файлів. Типи файлів мають різні пошукові служби, такі як HTML, звичайний текст тощо. Чи є такі, що виглядають недоречними, які могли бути встановлені програмою третьої сторони?

Ще однією ідеєю є те, щоб пошук завис на 4,317-му файлі. Потім запустіть командний рядок. Тип

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

Це створить файл з ім'ям newt.txt, який буде зберігати всі файли, і останній раз вони були доступні. Доступ, тобто прочитаний, не змінений. Вам доведеться шукати файл у редакторі файлів, але шукати останні декілька файлів, які були змінені. Якщо нам пощастить, ваш поганий файл буде там. Удачі!


Приємний відгук (друга ідея). Чи не індексатор зберігає якийсь журнал індексованих файлів? Це може дозволити нам побачити останній файл успішно індексований, і, можливо, отримати ключ таким чином.
mtone

@mtone - Чи можна індексувати одну папку за раз? Це обмежило б пошук.
Nifle

@Nifle - так, це також було б розумним дослідженням для зменшення кількості індексованих папок. У меню "Пуск" введіть "індексація" та натисніть на параметри індексування. На цій панелі перелічено розташування, які ви індексуєте.
Knox

@ Knox +1 для першої ідеї. Ви пропонуєте виключення [двійкова] пошук. І якщо ви зміните його з розумінням ймовірності дефекту, і обмежите індексацію першими, то ви можете отримати багато краще ніж O (log2 N) прискорювати.
ElderDelp

4

Я знайшов цю інформацію на Технічні форуми

Здається, це відома помилка:

  1. ПК має два (або кілька) дисків або розділів

  2. Профілі користувачів і Windows знаходяться на першому диску або   розділ (припустимо літеру диска C :)

  3. Другий диск або розділ мають більше вільного дискового простору, ніж   спочатку (припустимо букву диска D :)

  4. Послідовність оновлення OSD ConfigMgr 2007, яка використовує USMT 4 з   hardlinking виконується на ПК Потім   Захоплення файлів користувача та   Завдання "Налаштування" / "Захоплення стану користувача"   буде успішним, але "Відновити користувача"   State "/" Відновлення файлів користувача та   "Налаштування" завдання не вдасться.

Роздільна здатність

Щоб вирішити проблему, змінна   OSDStateStorePath має бути змінено   від значення за замовчуванням. При використанні MDT   2010 / MDT 2010 Оновлення 1 інтеграція,   змінна має бути перевизначена після   вона була встановлена   сценарій ztiuserstate.wsf у вікні   "Визначення локального або віддаленого користувача"   завдання.

Для того, щоб державний магазин був   збережено на одному диску / розділі   де встановлено Windows і   профілі користувачів знаходяться,   змінна середовища SystemDrive може   використовувати як частину шляху   визначає змінну   OSDStateStorePath.

Якщо оновлення MDT 2010 / MDT 2010 1   інтеграції не використовується ,   "Встановити задачу послідовності завдань"   встановлює змінну OSDStateStorePath   потрібно змінити:

  1. У консолі адміністратора ConfigMgr 2007 перейдіть до розділу Computer Management - & gt; Operating System Deployment - & gt; Task Sequences вузол.

  2. Клацніть правою кнопкою миші на відповідній послідовності завдань і виберіть "Редагувати".

  3. Натисніть на Set Local State Location завдання. Переконайтеся, що завдання   є Set Task Sequence Variable завдання   що встановлює змінну OSDStateStorePath.

Поруч з Value: текстове поле,   змінити його з %_SMSTSUserStatePath% до %SystemDrive%\UserState

  1. Натисніть кнопку "OK" або "Застосувати", щоб зберегти послідовність завдань. Якщо   завдання "Встановити місцеве місцеположення"   не існує, тоді шукайте "Set"   Змінна послідовності завдань - завдання, що задається   змінної OSDStateStorePath, і   потім внесіть зміни вище. Якщо   використовуючи оновлення MDT 2010 / MDT 2010 1   інтеграція, потім нова "Set Task"   Послідовність змінної "завдання повинна бути   додано після "Визначення локального або   Завдання Remote UserState, що перевизначає   змінна OSDStateStorePath:

  2. У консолі адміністратора ConfigMgr 2007 перейдіть до розділу Computer Management - & gt; Operating System Deployment - & gt; Task Sequences вузол.

  3. Клацніть правою кнопкою миші на відповідній послідовності завдань і виберіть "Редагувати".

  4. Натисніть на "Визначення локального або віддаленого UserState" завдання, а потім перейдіть до   "Додати" - & gt; "Загальні" - & gt; "Встановити завдання. \ T   Послідовність змінної   завдання "Встановити змінну послідовності завдань"   після "Визначення локального або віддаленого"   Завдання UserState, але перед   Завдання "Запит державного запиту".

  5. У нещодавно створеному завданні "Встановити змінну послідовності завдань":

    • Поруч з Name: текстове поле, введіть: Set Local State Location
    • Поруч з Task Sequence Variable: текстове поле, введіть OSDStateStorePath
    • Поруч з Value: текстове поле, введіть: %SystemDrive%\StateStore
  6. Натисніть кнопку "OK" або "Застосувати", щоб зберегти послідовність завдань.

Якщо в кроці 3 поставлено завдання "Визначити локально"   або Віддалений UserState "не існує або   було перейменовано, шукайте "Виконати"   Командний рядок "завдання, яке виконує   сценарій ztiuserstate.wsf, а потім   виконайте описані вище дії.


4

По-перше, спробуйте відновити індекс. Також виключіть індексацію папок із тимчасовими / незавершеними завантаженнями. Незакінчені файли за визначенням пошкоджені і можуть зависати процес. Відео / аудіокодеки також можуть зависати, якщо індексація шукає метадані в них.

alt text


Чи можете ви детально зупинитися на коментарі метаданих? Якщо щось, десь заклинює цю річ, можливо, це допоможе мені подумати про це.
Ricket

Індексація намагається отримати метадані, переглянувши файли. Деякі типи файлів, наприклад, файли відеофайлів AVI, вимагають кодеків (або завантажувачів контейнерів, які часто називаються також кодеками), щоб відкрити ці файли та отримати дозвіл, довжину і т.д. Тим не менш, я не зіткнувся з проблемою до цих пір в Windows 7, але в XP це було звичайною проблемою.
mtone

4

Мій пошук застряг через поганий файл Outlook.pst. Я запустив утиліту для ремонту pst SCANPST.EXE знаходяться в тому ж каталозі, що й виконуваний файл Outlook 2007 ( C:\Program Files (x86)\Microsoft Office\Office12 на моєму комп'ютері Windows 7 x64.)

enter image description here


1
Файл називається SCANPST.EXE
M. Dudley

2

Ви переконалися, що ваш жорсткий диск не вмирає?

Клацніть правою кнопкою миші на диску, відкрийте діалогове вікно Властивості, перейдіть на вкладку Інструменти та виконайте перевірку помилок (з поганим скануванням сектору).


так, дуже гарна ідея, щоб основи працювали правильно. Також перевірте журнал подій на системні помилки.
Knox

2

Одним з питань, поставлених тут, було те, як переконатися, чи блокований SearchIndexer.exe, чи він не виправданий або висить, чи є ще прогрес. Також було б приємно бачити, який файл зараз індексується.

Ось спосіб дізнатися.

Корпорація Майкрософт не надає вам інструментів для перегляду, файли журналів, створені під час пошуку, наприклад MSS.log (пізніше скопійовані та змінені в інших назвах, а потім видалені), є двійковими файлами і не можуть бути прочитані за допомогою спеціальних інструментів.

Інша альтернатива, яку я спробував з'ясувати, чи він висів на одному файлі, чи ні Монітор процесу SysInternals . Я встановлюю фільтр таким чином:

  • включати процес SearchProtocolHost.exe (Примітка: ні SearchIndexer.exe ),
  • включати тип події File System,
  • виключити що - небудь на C:\Windows і C:\ProgramData каталоги,
  • та / або включати каталоги, які ви фактично індексуєте,
  • опціонально встановіть операцію на ReadFile.
  • натисніть кнопку Застосувати або ОК, а потім натисніть кнопку Захоплення зверху ліворуч.

Отриманий вигляд події дає вам усі ReadFile операції (і деякі інші), які зараз читаються службою Microsoft Search Index.

Це має бути довгий список ReadFile Операції та файли, які зараз індексуються, знаходяться в стовпці Шлях. У стовпці Результат має відображатися SUCCESS (якщо ні, є ваш випадок), а стовпець "Докладно" має постійно показувати інше зміщення (якщо ні, то це циклічно, і це знову можливий натяк на причину вашої проблеми).


1
+1 @Able Посилання на Sys | nternals все ще працює! Це ще один, який надасть повний набір SysInternals
ElderDelp
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.