Загрузка Windows 7 завершается неудачно "autochk not found, пропуская autocheck"

Question

Я удалил старый раздел Windows XP и переместил раздел Windows 7 влево, используя gParted. Первая перезагрузка полностью завершилась с ошибкой "Операционная система не найдена".

Затем я использовал диск восстановления Windows 7, попал в командную строку и использовал различные команды bootrec:

bootrec /fixboot

bootrec /fixmbr

bootrec /rebuildbcd

Последняя команда все еще говорит

Total identified Windows installations: 0

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

autochk not found skipping autocheck

Запустив ремонт диска снова я получил следующие детали ремонта:

Session details
---------------
System Disk = \Device\Harddisk0
Windows directory = C:\Windows
AutoChk Run = 0
Number of root causes = 1

Root cause found:
Unspecified changes to system configuration might have caused the problem.

Repair action: System files integrity check and repair
Result: Failed. Error code = 0x57

Как я могу успешно загрузиться в Windows сейчас?

Answer 1

Нашел этот пост от "Yostage". это наверняка поможет

У меня была эта проблема, и ни одна из команд fixboot/fixmbr/bootrec не помогла. Вот что это исправило:

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

Загрузитесь в консоль восстановления и запустите regedit.

Используйте куст куста, чтобы смонтировать ваш c:\windows\system32\config\system hive (я называю его 'offline').

Теперь вы собираетесь сравнить HKLM\System\MountedDevices (который является списком устройств среды восстановления) с HKLM\System\Offline\MountedDevices (который используется для сбоя установки Windows). В моем случае я обнаружил, что среда восстановления правильно видела C: но в автономном кусте была неверная подпись диска для c: . (возможно, потому что я удалил раздел восстановления как часть миграции. Поэтому нам нужно поставить правильную подпись.

Посмотрите на двоичную запись для DosDevices\C: в реестре восстановления. Теперь перейдите в автономный реестр и исправьте DosDevices\C: так, чтобы он совпадал . В моем случае мне было проще всего переименовать плохие DosDevices\C: в Z: и затем просматривать записи \volume{guid} пока не нашел тот, который соответствует рабочему C: а затем переименовать его в DosDevices\C: Выгрузите улей в меню файлов, а затем перезагрузите компьютер. После того, как я это сделал, я смог загрузиться.

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

(Спасибо Yostage: superuser.com/a/547260)

Answer 2

За загрузкой Windows нет ракетостроения. Последовательность загрузки Windows Vista и более поздних версий на MBR-дисках:

1. Код MBR
2. Код PBR (код загрузочной записи раздела активного раздела)
3. bootmgr на активном разделе использует BCD (данные конфигурации загрузки)

Данные конфигурации загрузки (BCD) для Vista и более поздних версий хранятся в файле "\Boot\BCD" на активном разделе.

При перемещении разделов, которые имеют решающее значение для загрузки Vista (Win7, Win8), данные, хранящиеся в BCD, не синхронизируются с реальным адресом раздела (идентификатор диска + смещение раздела), поэтому загрузка не удалась.

Для устранения проблемы с BCD можно использовать утилиту bcdboot.exe:

bcdboot c:\windows

где c:\windows - это корень ОС (Vista, Win7, Win8), которая не загружается, при необходимости измените букву диска, чтобы отразить отображение дисков в вашей системе.

Чтобы исправить код загрузочного сектора командой -

bootsect /nt60 all /mbr

может быть использован.

Команды выше доступны в WindowsPE и WindowsRE и обычно не дают сбоя.

Возможно, что некоторые критические системные файлы также загружаются относительно адреса раздела, поэтому autochk.exe "\windows\system32\autochk.exe" невозможно найти при перемещении запуска раздела.

Адрес сопоставленного раздела хранится в реестре Windows (например, HKEY_LOCAL_MACHINE\SYSTEM\ MountingDevices \ DosDevices \ C:)

Answer 3

В моем случае C: не был автоматически назначен для тома, и, следовательно, загрузка Windows 7 завершилась неудачно с сообщением «autochk not found, пропуская autocheck». Чтобы это исправить, я загрузился в WinRE и сделал следующее:

diskpart
list vol

Определите номер тома, на котором присутствует Windows. Это вполне очевидно по размеру столбца. Давайте назовем номер тома X.

sel vol X
attributes vol clear nodefaultdriveletter
assign letter = C:
exit

Тогда перезагрузись! :)

Answer 4

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

• Partition Master Free
• PTEdit

Answer 5

У меня была похожая проблема после покупки ноутбука с SSD. Я хотел освободить немного ценного дискового пространства SSD для двойной загрузки Linux, поэтому я удалил раздел восстановления 20 ГБ (sda3) и системный раздел 8 ГБ (sda0) в начале диска.

Теперь я получил:

autochk not found skipping autocheck

Вслед за BSoD.

Так как я удалил разделы восстановления со многих ноутбуков, и это никогда не было проблемой, я почти уверен, что этот системный раздел содержал некоторые ключевые файлы.

Используя загрузочную флешку USB с живым Linux, я поставил резервный раздел SYSTEM_DRV перед всеми остальными разделами, но как 350 МБ вместо 8 ГБ, потому что остальное было просто ценным пустым пространством.

Как вы, вероятно, знаете, удаление и создание разделов часто портит записи в таблице разделов:

[1st partition] -> sda3  
[2nd partition] -> sda2  
[3nd partition] -> sda1  

Поэтому я исправил записи с помощью fdisk:

x // expert mode
f // fix count
w // write changes

Делайте это на свой страх и риск. Я настоятельно рекомендую раздражающее количество резервных копий!

Теперь снова было хорошо. Пометить первый как загрузочный:

[1st partition] -> sda1 * boot
[2nd partition] -> sda2
[3nd partition] -> sda3

И после перезагрузки началось восстановление системы. Автоматическая перезагрузка, и проверка диска началась. Автоматическая перезагрузка, и Windows запустилась!

Миссия выполнена.

Поскольку я предполагаю, что люди из Lenovo не полностью отсталые, я предполагаю, что удаление пустого пространства из системного раздела что-то испортит, но я не уверен, что это будет. По крайней мере, это не то, что вы заметите в повседневном использовании.

Кроме того, на протяжении многих лет я заметил, что становится все проще устанавливать и запускать Linux практически на всех, и в то же время становится все труднее поддерживать работу Windows после управления диском. Это почему? Вы платите за это, так что это должно раздражать? Притворяться, будто загрузка - это ракетостроение?

Answer 6

Пожалуйста, запустите SFC, чтобы узнать, не сломан ли autochk. Это также распространено на дисках, которые имеют полное шифрование диска, так как Windows не может получить доступ к диску, когда включен WDE.