Ошибка Chkdsk Stage 3, но «Chkdsk /f» не может выполнить восстановление при перезагрузке Windows
Краткое описание:
У меня поврежден том: в частности, это ошибка 3-й стадии. На этапе 3 проверяет дескрипторы безопасности и журналы USN. Однако восстановление не запускается при перезагрузке Windows.
Подробности:
Я побежал. Он не сообщает о проблемах. Однако, когда я бегуchkdsk /scan, который выполняет дальнейшие проверки файловой системы NTFS, я получаю сообщение об ошибке на этапе 3. Этап 3 процесса chkdsk проверяет дескрипторы безопасности и журналы USN (USN = уникальный порядковый номер).Chkdskсообщает следующее сообщение:
«Windows обнаружила проблемы, которые необходимо устранить в автономном режиме. Пожалуйста, запустите «chkdsk /f», чтобы устранить проблему.'
Когда я выполняю команду в командной строке, я получаю результат:"
Том C: грязный
Это означает, что для тома установлен грязный бит, обозначающий диск как поврежденный и нуждающийся в восстановлении.chkdskремонт.
Однако, когда я пытаюсь запуститьchkdsk /fпри следующей перезагрузке Windows я получаю сообщение «Сканирование и восстановление», но не вижу никаких процентов прогресса, указывающих на то, что идет восстановление. Windows успешно загружается и делает это быстро, что указывает на то, что восстановление не было выполнено. Когда я бегуfsutil dirty queryИ снова я обнаружил, что грязный бит остается установленным, и запуск chkdsk /scan продолжает сообщать об ошибке этапа 3.
Я вижу сообщение «Сканирование и восстановление диска (c:)» при каждом запуске Windows. Windows обнаруживает грязный бит и пытается запустить восстановление при каждом запуске, но не может даже начать восстановление (поскольку я не вижу любые индикаторы прогресса).
Одним из симптомов является то, что я не могу создавать резервные копии (в частности, я использую устаревшую систему резервного копирования Windows 7, которая не работает), поскольку Windows сообщает, что резервное копирование не удалось, поскольку мой диск поврежден. Я полагаю, что если резервное копирование завершается неудачно из-за повреждения тома, это может указывать на проблему с журналами USN NTFS (я только предполагаю).
Я читал, что chkdsk /f и дефрагментация могут не запуститься при повреждении журнала NTFS и что сброс журнала может решить проблему. Это можно сделать, выполнив командуfsutil usn deletejournalв командной строке с правами администратора. Возможно, потребуется применить переключатели /d /n, а также заново создать журнал, выполнив после этого команду. Однако я не знаю, насколько безопасно удалять журнал. Более того, я не уверен насчет переключателей: кажется, /d отключает ведение журнала. Это навсегда? Я даже не знаю, что это значит.
Для воссоздания журнала необходимо указать различные параметры.fsutil usn createjournalи я не знаю, какими они должны быть и как правильно запустить эту команду.
ТАКЖЕ ОБРАТИТЕ ВНИМАНИЕ: ЗДЕСЬ Я РАССМАТРИВАЮ возможность удаления и воссоздания журнала NTFS в качестве возможного решения.
Кто-нибудь может предложить какие-либо решения моей проблемы. Спасибо.
2 ответа
Хорошо, ради блага других я предоставлю вам все полученные мной знания, которые помогли мне решить эту проблему.
В моем случае chkdsk не мог выполнить восстановление на моем компьютере при каждом запуске Windows. С установленным грязным битом Windows пыталась выполняться при каждой загрузке, но выполнение восстановления не удавалось. Я подозреваю, что причина этого может заключаться в том, что мой компьютер достаточно современный и на диске активировано шифрование BitLocker. Следовательно, когда я перезапускаю свой компьютер, chkdsk выходит из строя, поскольку диск остается в RAW и зашифрованном состоянии во время запуска chkdsk. Если я прав, то это может оказаться все более распространенной проблемой, поскольку продажа компьютеров с зашифрованными дисками становится нормой. Microsoft также необходимо вернуться к этому вопросу. Необходимо пересмотреть структуру работы chkdsk при запуске на основном диске, поскольку шифрование не позволяет запускать chkdsk при запуске Windows.
Я последовал совету @tsc_chazz tsc_chazz загрузился в командную строку, а затем запустил оттуда. Бам! задача решена! Я не мог в это поверить, это сработало! Конечно, поскольку диск был зашифрован, мне пришлось предоставить 48-значный ключ шифрования (о котором я ничего не знал и который мне пришлось получить от Microsoft через aka.ms/myrecoverykey ). В своей первой попытке я пропустил страницу с запросом ключа восстановления (т. е. ключа шифрования битлокера) и получал сообщения об ошибках, когда пытался запустить из среды загрузки в командную строку. Chkdsk не смог указать тип тома — RAW и что chkdsk не работает на томах RAW.
Все это также говорит о том, что любая попытка запустить chkdsk на диске, когда он смонтирован извне, также может оказаться неудачной. Например, если бы я загрузился с USB-диска восстановления и запустил chkdsk на своем основном разделе из этой среды восстановления, это тоже не удалось бы, поскольку диск остается зашифрованным. Чтобы обойти эту проблему, можно заранее отключить BitLocker на диске через панель управления. См. руководство здесь . Процесс расшифровки диска может занять очень много времени. Однако в этом шаге нет необходимости, поскольку загрузка в командной строке приведет вас на другой диск (в моем случае X:), что позволит вам работать на основном разделе ( обычно диск c:) .
Итак, вкратце: загрузка командной строки и ввод ключа восстановления в процессе расшифровки диска, а затем запуск
Однако если бы это не сработало, я бы воссоздал журналы USN файловой системы NTFS. Это связано с тем, что повреждение chkdsk Stage 3 связано с повреждением этих журналов. Я предполагаю, что сбой с USN (порядковые номера обновления). Было отмечено, что такое повреждение само по себе может быть причиной сбоя запуска chkdsk. Повреждение здесь также может привести к сбою резервного копирования и дефрагментации. При запуске резервного копирования, например резервного копирования Windows 7, вы можете увидеть сообщение об ошибке, говорящее что-то вроде...
Не удалось выполнить резервное копирование следующих файлов, поскольку они находятся на поврежденном диске c:
Чтобы воссоздать журналы USN NTFS, сначала удалите, а затем заново создайте журнал.
Удаление журнала
Вы можете удалить журнал NTFS USN с помощью...
fsutil usn deletejournal /d /n c:
Это может занять несколько часов и «заблокирует ваш компьютер» до завершения, если вы используете ключ /n. В качестве альтернативы вы можете оставить ключ /n, и он удалит журнал в фоновом режиме и при перезагрузке, если это необходимо.
Переключатели /d и /n плохо документированы. Документация Microsoft здесь противоречит информации, представленной при запросе использования команды в командной строке:
Оба неточны! Документация командной строки неверна, поскольку ОБА переключателя удаляют журнал, а не только /d. Документация на веб-странице Microsoft вводит в заблуждение, поскольку журнал фактически удаляется, а не отключается. Переключатели определяют, как он будет удален.
Поскольку удаление журнала может занять очень много времени, переключатели позволяют вам контролировать, будет ли он выполняться внутри процесса или вне процесса. Переключатель /n выполняет удаление журнала в процессе, блокируя его дескриптор (считайте это «блокировкой компьютера»). Это заставляет вас ждать, пока оно завершится. Переключатель /d выполняется вне процесса и позволяет вам продолжить работу. Удаление журнала может занять несколько часов и будет продолжаться при последующих перезагрузках, пока не будет завершено. Я видел, как люди применяли оба переключателя вместе, когда они взаимоисключающие.
Удаление журнала почти всегда безопасно, но иногда оно может иметь последствия для процессов резервного копирования. Приложения, использующие журнал, не будут видеть изменения файлов между последним запуском приложения и моментом удаления журнала. Хорошо запрограммированные приложения определят, что журнал был удален, и вернутся к альтернативному методу поиска измененных файлов или создадут его заново. Я бы посоветовал удалять безопасно, несмотря на последствия, потому что в худшем случае вы только поставите под угрозу возможность инкрементального резервного копирования. Вы все равно можете сделать ПОЛНУЮ резервную копию и начать все заново; по крайней мере, ваши данные не потеряются!
Воссоздание журнала
Как мне сообщили, нет необходимости воссоздавать журнал вручную, так как запуск программы резервного копирования, такой как опция резервного копирования Windows-7, через панель управления (несмотря на название, эта опция также доступна в Windows 8/8.1 и 10) автоматически воссоздать журнал NTFS.
Если вы хотите вручную воссоздать журнал, в командной строке выполните одно из следующих действий:
fsutil usn createjournal m=536870912 a=67108864 C:
... если у вас очень большой диск (более 4 ТБ и более 400000 файлов);
Или для дисков меньшего размера с меньшим количеством файлов запустите:
fsutil usn createjournal m=67108864 a=8388608 C:
Если вам интересно, откуда взялись эти цифры, то это количество битовых состояний, возведенных в достаточную степень, которая обеспечивает размер журнала журнала в байтах. IE: Эти цифры имеют размер 2^x, что дает точный размер в байтах вокруг желаемого размера. Размер журналов обычно составляет от 30 до 40 МБ. Таким образом, я перешел к следующему максимальному доступному размеру (67 МБ) для параметра maxSize (m):
2^25 байт x 2 = 33 МБ x 2 = 67 МБ
Параметр AllocationDelta (a) должен составлять около 1/8 m, что составляет около 8 МБ. Этого объяснения вы не найдете больше нигде в Интернете!!! В частности, Microsoft позорно не смогла адекватно задокументировать использование этих двух команд журнала.
К вашему сведению: вы можете запросить текущий размер ваших журналов, введя следующую команду в командной строке с повышенными привилегиями:
C:\Windows\system32> fsutil usn queryjournal C:
Вы получите вывод, подобный этому:
The
m = 33554432 байт = 33 МБ
а = 8 388 608 байт = 8 МБ
Вы можете запросить количество файлов в вашей системе, выполнив следующую команду в командной строке с повышенными привилегиями:
C:\Windows\system32> dir C:\ /s /a /w
Вы увидите такой результат...
Сложите количество файлов и каталогов, чтобы получить общую сумму; В этом примере 1616718.
Затем вы можете использовать следующую таблицу (воспроизведенную на ) в качестве альтернативного руководства для поиска подходящих значений максимального размера и дельты распределения.
См. руководство по созданию журналов этой страницездесь: См. также несколько полезных советов здесь:
Я думаю, что в этом случае вам, возможно, придется серьезно подойти к делу. Если бы это была моя система, первое, что я бы сделал, это попытался вернуться в командную строку: на экране входа в систему удерживайте Shift, выбирая перезагрузку; загрузитесь для восстановления вашего компьютера, перейдите на дополнительные страницы и запустите командную строку — подтвердите букву диска, на котором находится ваша активная установка Windows, иchkdsk /fоттуда. В качестве альтернативы можно было бы вытащить диск и использовать адаптер USB/SATA, чтобы подключить его как внешний к какой-либо другой машине, которая затем могла бы выполнитьchkdsk. Я не хочу предлагать загружать дистрибутив Linux и запускать Linux.fsck, потому что, хотя их реализация NTFS очень хороша, в ней могут отсутствовать некоторые мелкие детали.