на Windows 7 программы стали открываться по 5 минут

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Microsoft Windows 7 (http://forum.oszone.net/forumdisplay.php?f=95)

на Windows 7 программы стали открываться по 5 минут

Доброго времени суток.

Система: ноутбук Samsung RV511, проц Core i3, память 8ГБ, HDD HGST HTS721010A9E630 Advanced format 1ТБ, Windows 7 x64 Ult

Пару дней назад во время игры, все повисло намертво. После ребута: вижу рабочий стол, мышка бегает. Но программы запускаются оооочень медленно или не запускаются, ошибок нет. Контекстное меню по ПКМ появляется через минуту. Диспетчер задач через минуты 3-4, но потом работает и показывает что проц свободен и памяти навалом. Браузер совсем не запускается.
После перезагрузки иногда минуту-две работает как обычно, потом снова.
Раньше такого не было.

В журнале Систем подозрительные события:
1. от источника Atapi, номер 11 The driver detected a controller error on\Device\Ide\IdePort0.
2. от источника Disk, номер 11 The driver detected a controller error on \Device\Harddisk1\DR1
3. от источника Disk, номер 7 The divice \Device\Harddisk2\DK3 has a bad block
В журнале и ранее, и полгода-год назад видно такие события. От источника Disk меняются номера после Harddisk и DR.
Полный журнал Систем https://yadi.sk/d/dzT1UwWq3EFCNT

На смарт видно 8 пендингов (параметр С5). Пару месяцев назад был сбой, винда ругалась на ЖД, смарт показывал фейл из-за параметра 01 Read Error Rate, прошло само, после пары перезагрузок. Тогда я стал периодически вручную мониторить смарт. После прошлого сбоя и до текущих тормозов было 7 пендингов.

Прошелся сканом на чтение HD Tune. На скрине видно, что один сбойный сектор. Причем если проводить проверку несколько раз то номер блока может незначительно измениться на +-50. Я сделал 10-12 проверок(ну не всего диска, а области в несколько ГБ) всего было 4 разных сбойных сектора. Но при одной проверке сбойный сектор всегда был один.

На винте в другом разделе есть еще одна установка Windows 7, ставил давно для теста, при включении выбор ОС. Так вот она работает как обычно. Сбойные по данным HD Tune сектора попадают на раздел с тормозящей на данный момент виндой.

Также винт напомню 1ТБ, занят на ~70%, куча программ и данных.
[b]

Вопросы:
1. Как сделать, чтобы винда не тормозила?
2. Почему она сейчас тормозит?
3. Почему в моем случае HD Tune может показывать разные сбойные сектора при повторных проверках?
4. Имеет ли смысл пройтись по разделам Chkdsk?

Цитата:

Цитата kubinec12

Почему она сейчас тормозит? »

При обращении к нестабильному сектору и диск в течение нескольких секунд пытается его вычитатать, и только после этого сообщает, что "не шмогла"; ну а Windows затем начинает по своим алгоритмам разбираться, что делать в данном конкретном случае, в т.ч. может повторно обратиться к его чтению с последующей новой задержкой.

Цитата:

Цитата kubinec12

Почему в моем случае HD Tune может показывать разные сбойные сектора при повторных проверках? »

Если номера секторов лежат в пределах 8 последовательных LBA, то потому, что это диск с AF, и восемь последовательных внешних секторов по 512 [эмулированных] байт относятся к внутреннему единому сбойному сектору в 4К.

Цитата:

Цитата kubinec12

Имеет ли смысл пройтись по разделам Chkdsk? »

Нет!!

Первым делом надо лечить нестабильные сектора.

Цитата:

Если номера секторов лежат в пределах 8 последовательных LBA

нет. как я написал LBA различаются примерно +-50

Цитата:

Первым делом надо лечить нестабильные сектора.

Так а как их лечить? Сбойные сектора - это типичная вещь для ЖД. В ЖД уже лет 20 производителем заложен алгоритм для их обработки, упрощенно: переназначение на сбойных на запасную область. И этот алгоритм реализует прошивка ЖД.
Как я, обычный пользователь, который работает в Эксель, может там что-то лечить?

Цитата:

Цитата kubinec12

И этот алгоритм реализует прошивка ЖД »

Меньше недели назад в очередной раз разъяснял эту весьма поверхностную (вам ведь, как пользователю Эксель, и вообще 99.9% пользователям более подробные сведения по тому, как винчестеры реализует свои задачи, ни к чему, не так ли?) информацию: в http://forum.oszone.net/post-2711682.html#post2711682 и кое-что давалось в соседней с ней аналогичной теме, шедшей в то же время.

PS

Цитата:

Цитата kubinec12

как я написал LBA различаются примерно +-50 »

Возможно в этой небольшой зоне произошла локальная деградация поверхности блина, и те несколько нестабильных секторов, что лежат в этом месте, находятся на грани: то могут быть прочитаны — то нет.

Мне кажется, о функционировании винтов я знаю больше чем 99,9% пользователей ПК. Думаю это понятно из шапки темы.
В смысле поверхностная тема? Тема наоборот, крайне углубленная, техническая и специфичная.
Да, спасибо за ссылки, я ранее просмотрел эти темы. И из них непонятно, почему типичный вопрос ЖД - бэды - которые по идее (по дизайну) должна решать прошивка, ну или ОС, или они совместно - пытается решить пользователь сторонними программами, помогая алгоритму сообразить куда-что-когда переназначить?
1. Как-то это странно, вы не находите?

2. Откуда вообще идея, что нужно как-то лечить пендинги? В какой-то документации так написано? Производитель рекомендует их лечить?
3. Что говорит в пользу того, что значение параметра С5 в моем случае как-то влияет на тормоза системы? Ведь как я написал в шапке, они были и задолго до текущего сбоя. А может какая микросхемка или кондер на матплате или на плате ЖД вышла из строя и тормоза из-за этого.

Цитата:

Цитата kubinec12

пытается решить пользователь сторонними программами, помогая алгоритму сообразить куда-что-когда переназначить? »

Нет. Он создаёт лишь условия, чтобы микропрограмма или всё же переназначила эти сектора, или вернула их в строй здесь и сейчас, а не откладывала (pending — отложенная обработка; на мысли не наводит?) в долгий ящик.

Поскольку я не считаю, что знаю о винчестерах всё, то более рекомендаций земского врача, помогающих в аналогичных случаях (и как минимум — не приносящих вреда), давать не буду. Ждём спецов.

Цитата:

Цитата kubinec12

В смысле поверхностная тема? »

В смысле — поверхностное объяснение:

Цитата:

Цитата kubinec12

Сбойные сектора - это типичная вещь для ЖД. В ЖД уже лет 20 производителем заложен алгоритм для их обработки, упрощенно: переназначение на сбойных на запасную область. И этот алгоритм реализует прошивка ЖД. »

Да, реализует. Но не обязательно переназначением на запасную область. И может откладывать проверку до греческих календ — но это я уже сказал чуть выше.

Бывают нестабильные сектора, не связанные с состоянием диска (мигнул свет когда шла запись на диск — и контрольная сумма сектора из-за оборвавшейся записи перестала соответствовать правильной) — и тогда при перетестировании такого сектора в него просто прописывается хоть и фиктивная, но правильная с точки зрения структуры сектора информация. При этом сектор переводится из нестабильных (счётчик C5 уменьшается) в рабочие не пополняя количества переназначенных (счётчик 05 не увеличивается).

Собственно, и на этот, и на все остальные вопросы я уже дал ответы выше — хоть и вкратце. И почему не странно, и откуда идея лечить пендинги ("лечить" — это чисто упрощённо, поскольку здесь не академическое исследование; реально это означает: заставить диск их наконец-то обработать), и почему возникают тормоза при наличии нестабильных секторов.

mwz, я понял про земского врача.
Тем не менее, на вопросы 1-3 ответов нет.
Ну да ладно, все равно большое спасибо.

Надеюсь народ еще поучаствует в дискуссии. А я в свою очередь как(если) разберусь выложу в тему результаты.

kubinec12, по размышлении: можете запустить chkdsk, но пока без разрешения правки.

Запустите с правами администратора командный процессор cmd.exe и выполните в нём команду:

Код:

chkdsk C:

(при необходимости поменяйте букву диска на ту, которую хотите проверить) безо всяких ключей после буквы диска. Результат, если будут обнаружены ошибки, приложите сюда.

Возможно что там действительно найдётся что-то дополнительно к уже сказанному. Хотя это "дополнительное" (т.е. некоторые ошибки) может быть связано и с теми самыми нестабильными секторами, однако утверждать это до устранения самих нестабильных секторов будет тяжеловато, если вообще возможно.

mwz, на диске 4 раздела, по порядку расположения на диске:
- 100 МБ загрузочный винды;
- ~850 ГБ раздел с виндой, которая на данный момент тормозит;
- 40 ГБ раздел с виндой, которая была установлена давно для теста. Работает нормально;
- 40 ГБ бэкап раздел производителя ноута, скрыт.

Сканировал с рабочей винды, на этом же ЖД.
Бэкап раздел не проверял, думаю он ок.
Первый и третий разделы chkdsk говорит ок.
Второй раздел около часа зависает на проверке индексов NTFS, а потом выдает: Errors found. CHKDSK cannot continue in read-only mode.
Во время стадии проверки индексов в журнале систем появляются 2-3 события от Atapi, номер 11, The driver detected a controller error on\Device\Ide\IdePort0
Также тот сектор(сектора), которые HD Tune при сканировании определяет как "damaged" приходятся на этот раздел.

kubinec12, итак, Ваша проблема решается единственным способом - замена жесткого диска на новый. Согласно таблицы S.M.A.R.T. Ваш жесткий диск неисправен. Ремонту не поддается.

Цитата:

Цитата kubinec12

Вопросы:
1. Как сделать, чтобы винда не тормозила?
2. Почему она сейчас тормозит?
3. Почему в моем случае HD Tune может показывать разные сбойные сектора при повторных проверках?
4. Имеет ли смысл пройтись по разделам Chkdsk? »

1. Замена HDD
2. HDD неисправен.
3. HDD неисправен.
4. Нет. Кроме замены диска ничего не поможет. Зря потратите время.

kubinec12

The index buffer at VCN 0x0 of index $I30 in file 0xbf7 cannot be read.
Error detected in index $I30 for file 3063.
The index bitmap $I30 in file 0xbf7 is incorrect.

Судя по этой части, нестабильный сектор попал на MFT. Видимо с тех пор и начались основные подвисания: к MFT обращения идут в каждом сеансе работы с компьютером.

В отличие от тех вариантов, когда появившийся нестабильный сектор приходится на файл, к которому обращения происходят очень редко, а тем более если этот сектор свободен: в последнем случае задержки будут только при попытках записи в такой сектор, ну а операционка после нескольких неудачных попыток должна предложить для записи другой сектор (точнее, кластер, в который он входит), т.е. сектор так и останется свободным.

Ettercap, основания для такого вывода?

В SMART ни один атрибут даже близко не подходит к порогу, при котором винчестер признаётся безусловно неисправным. Ну а про нестабильные сектора уже много тут сказано.

Цитата:

Цитата mwz

основания для такого вывода? »

Основания? Итог будет один - замена. Как ни крути. Нестабильных секторов быть не должно. И точка. Если считаете по другому, флаг вам в руки. Порог не важен. 1 сектор - замена диска. Только так. Все остальное брехня. Опыт говорит об одном - смарт должен быть полностью чистым! Хоть одна маленькая проблема в одном из критических параметров - срочно искать замену и избавляться от диска.
У автора не выйдет ничего сделать. А если и выйдет, то на короткое время. Дальше будет полное неизбежное разрушение диска.

Цитата:

Цитата Ettercap

Нестабильных секторов быть не должно. И точка. Если считаете по другому »

И где я говорил, что должны быть??
Я как раз и говорил, что не должно — и надо от них избавиться.

В общем прошелся чекдиском /f /r. Он поправил ошибки и написал в отчете, что внес один плохой кластер в список неиспользуемых, в смысле 4 КБ в поврежденных секторах. После этого виндоус работает нормально. Повторная проверка чекдиском ошибок не находит. Если чекдиск /b, то также перенаходит один плохой кластер. Ошибок от atapi в журнале нет. Есть ошибки от Disk на тему неверного блока на устройстве. Проверка программами аля HD Tune также показывает один плохой сектор. Смарт без изменений.
До этого проверка оффлайн антивирусом показала, что чисто.

Теперь попробую занулить диск, потом посмотреть на смарт и пройтись HD Tune. А потом при необходимости пройтись фирменной утилой с целью переназначения.

Прошу подсказать, а где-нибудь можно найти подробное описание работы чекдиска поэтапно. Я искал на течнете в Library, но там только справка по опциям командной строки. Может если MS не сделала описание, то энтузиасты разобрались.

Лог проверки чекдиска, после которого винда заработала нормально, FYI.

Скрытый текст

Программа Chkdsk была запущена в режиме чтения и записи.

Проверка файловой системы на H:
Тип файловой системы: NTFS.

Проверка файлов (этап 1 из 5)...
Обработано файловых записей: 517632. Проверка файлов завершена.
Обработано больших файловых записей: 1741. Обработано поврежденных файловых записей: 0. Обработано записей дополнительных атрибутов: 2. Обработано записей повторного анализа: 64. Проверка индексов (этап 2 из 5)...
Ошибка чтения с кодом состояния 0xc0000185 в смещении данных 0x1c23ba8000 для 0x1000 Байт.
Ошибка чтения с кодом состояния 0xc0000185 в смещении данных 0x1c23ba8000 для 0x1000 Байт.
Ошибка чтения с кодом состояния 0xc0000185 в смещении данных 0x1c23ba8000 для 0x1000 Байт.
Не удается прочесть буфер индексов для VCN 0x0
индекса $I30 в файле 0xbf7.

Исправление ошибки в индексе $I30 файла 3063.
Рисунок файла $I30 в файле 0xbf7 неверен.
Исправление ошибки в индексе $I30 файла 3063.
Недопустимый указатель на дочерний элемент индекса в текущем элементе индекса
длины 0x18.
00 00 00 00 00 00 00 00 18 00 00 00 03 00 00 00 ................
ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 yyyyyyyy........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Сортировка индекса $I30 файла 3063.
Обработано записей индекса: 662832. Проверка индексов завершена.
Программа CHKDSK осуществляет поиск неиндексированных файлов и их повторное сопоставление с исходным каталогом.
Восстановление потерянного файла Low (69284) в файле каталога 3063.
Восстановление потерянного файла MPCMDR~1.LOC (83201) в файле каталога 3063.
Восстановление потерянного файла MpCmdRun-6-421CFC91-A93E-42AB-A35C-F06F127FCC44.lock (83201) в файле каталога 3063.
Восстановление потерянного файла MpCmdRun.log (96578) в файле каталога 3063.

Восстановление потерянного файла T30DEB~1.TXT (360730) в файле каталога 3063.
Восстановление потерянного файла T30DebugLogFile.txt (360730) в файле каталога 3063.
Восстановление потерянного файла FXSTIF~1.TXT (360748) в файле каталога 3063.
Восстановление потерянного файла FXSTIFFDebugLogFile.txt (360748) в файле каталога 3063.
Проверено неиндексированных файлов: 6. Восстановление потерянного файла FXSSVC~1.TXT (360749) в файле каталога 3063.
Восстановление потерянного файла FXSSVCDebugLogFile.txt (360749) в файле каталога 3063.
Восстановлено неиндексированных файлов: 0. Проверка дескрипторов безопасности (этап 3 из 5)...
Обработано файловых SD/SID: 517632. Очистка от неиспользуемых индексных записей 266 в индексе $SII файла 0x9.
Очистка от неиспользуемых индексных записей 266 в индексе $SDH файла 0x9.
Очистка 266 неиспользованных дескрипторов безопасности.
Проверка дескрипторов безопасности завершена.
Обработано файлов данных: 72601. CHKDSK проверяет журнал USN..
Обработано байтов USN: 34579176. Завершена проверка журнала USN
Проверка содержимого файла (этап 4 из 5)...
Обработано файлов: 517616. Проверка содержимого файла завершена.
CHKDSK проверяет свободное пространство на диске (этап 5 из 5)...
Обработано незанятых кластеров: 77755444. Проверка свободного места на диске завершена.
Добавление 1 поврежденных кластеров в файл поврежденных кластеров.
Исправление ошибок в битовой карте тома.
Windows сделала изменения в файловой системе.

921131007 КБ всего на диске.
609288124 КБ в 306533 файлах.
170848 КБ в 72602 индексах.
4 КБ в поврежденных секторах.
650255 КБ используется системой.
65536 КБ занято под файл журнала.
311021776 КБ свободно на диске.

Размер кластера: 4096 байт.
Всего кластеров на диске: 230282751.
77755444 кластеров на диске.

Цитата:

Цитата kubinec12

описание работы чекдиска поэтапно »

Даже если найдёте... Сhkdsk не пытается поправить нестабильные секторы, а лишь прячет их с глаз операционки долой, помещая адреса кластеров с такими секторами в метафайл $BadClus с тем, чтобы Windows не пыталась к ним обратиться.