Инструмент для восстановления журнала MFT или NTFS на диске, который подвергся неудачному переходу в спящий режим

Инструмент для восстановления журнала MFT или NTFS на диске, который подвергся неудачному переходу в спящий режим

Я прочитал некоторые посты, связанные с поврежденными или неработающими разделами NTFS, но так и не нашел подходящего решения для моего случая. Вот оно: моя система

  • SSD на миниPCI-экспресс(PCIe), на нем установлена ​​Windows 7. Два раздела: один с утилитами Dell (40 МБ), остальное — сама установка Windows (119 ГБ).
  • Жесткий диск с 450 ГБ файлов NTFS и 30 ГБ всех разделов, необходимых для работы установки Ubuntu (раздел подкачки, система и т. д.)

Загрузочное устройство — внутренний жесткий диск (ИРРТ), единственно возможный; это включает IRRT и запускаетGRUB, который, указав на определенный сектор на жестком диске, может запустить Windows 7 на SSD.

А теперь что произошло:

Я перевел компьютер в спящий режим, а затем он перешел в спящий режим через несколько часов. Беспроводная карта была физически отключена (Делл М4600). Затем я запустил ноутбук, и прежде чем GRUB был завершен, я снова включил беспроводную карту. Затем нажал "windows" на GRUB. ЗатемBSOD, перезагрузка, и Windows не может найти загрузочный раздел: «необходимое устройство отсутствует».

Я попробовал диск восстановления Windows 7: может восстановить только крошечную часть установки Windows, которая находится на HDD, не видит SSD. "Восстановление" ничего не дает. Извлечение жесткого диска для принудительного обхода GRUB не заставило Windows DVD увидеть загрузочный сектор SSD. Этого было недостаточно для "установки Windows".

Теперь, если я начну действовать так, как будто собираюсь установить Windows снова, Windows увидит два раздела на диске C, они все еще здесь, в NTFS.

Затем я перешел на Linux и попробовалfdisk: разделы все еще здесь, снова. Но они не появляются вНаутилус, и я не могу их смонтировать. Однако,ддможно восстановить данные: если я попробую прочитать данные с каким-то случайным большим смещением (например, смещение 20 ГБ и прочитаю 10 блоков), блоки действительно будут «данными», нет проблем с физическим доступом к диску, по крайней мере, он, похоже, не вышел из строя полностью. Завтра я сделаю резервную копию.

Я пыталсяТестДиск: загрузочные секторы идентичны и кажутся исправными, но обаМФТпоказывать как "плохой", ничего больше. Невозможно получить доступ к файлам внутри файловой системы.

На этом сайте я увидел что-то о неправильной записиЖурналирование NTFS,Необходимо восстановить поврежденный раздел NTFS.

Почти последний пост. В интернете об этом ничего нет, насколько я искал.

И я подозреваю, что что-то в процессе гибернации не отменяется, поскольку я помню, что процесс гибернации сильно меняет последовательность загрузки (иначе вы могли бы переместиться hiberfil.sysбез проблем, но это невозможно. Он должен быть в корневом каталоге, потому что в загрузчике нет места для размещения папки или даже другого диска!).

Так что, возможно, оба загрузочных сектора были затронуты гибернацией, и когда он не смог завершить процесс возврата к нормальной загрузке, он остался таким, Windows смотрит туда, куда указывает указатель загрузки, и не распознает обычную установку Windows и отказывается ее восстанавливать, и поскольку Linux не может найти MFT, он не может ее смонтировать... или, может быть, что-то другое, влияющее на саму MFT. Я не знаю... Я попробуюЧКДСКи, после резервного копирования,исправитьmbr, с DVD-диска Windows 7.

ОБНОВЛЕНИЕ: fixmbr и fixboot, похоже, работают только из консоли восстановления, и я не смог получить к ней доступ. С DVD Windows 7 я смог выполнить CHKDSK: он только сказал, что том был NTFS, прежде чем произошел сбой, потому что "MFT поврежден. Попробую восстановить. MFT не удалось восстановить. Выйдите из chkdsk".

При попытке diskpart он увидел мой раздел на SSD как... Raw. Так что это не соответствует тому, что увидел CHKDSK.

Что-то во всем этом странное: все это время Windows не видела первые 40 МБ моего SSD, которые содержали утилиты Dell. В проводнике Windows 7 основной раздел SSD всегда был C:\, а раздел HDD был D:\: этот раздел 40 МБ на SSD никогда нигде не появлялся. Но теперь Windows видит этот раздел 40 МБ и присваивает ему букву C:\. При этом D:\буква соответствует разделу 119 ГБ, формат "Raw", не поддается чтению. Я ничего не понимаю...

решение1

Загрузочное устройство — внутренний жесткий диск (IRRT), единственное возможное; это включает IRRT и запускает GRUB, которыйуказывая на какой-то секторна HDD можно запустить Windows 7 на SSD. Я думаю, вам нужно, чтобы указатель был таким же, как этот.^

Я предполагаю { Затем нажал "windows" в GRUB. Затем BSOD, перезагрузка, и Windows не может найти загрузочный раздел: "необходимое устройство отсутствует". }

не использует тот же указатель, особенно если он переходит в режим гибернации. Загрузка grub должна указывать на загрузочный сектор Windows или hiberfil.sys. Была похожая проблема, когда я пытался отредактировать winresume.exe, чтобы попытаться указать на D:, когда Windows находится на C:, он не выводил Windows из режима гибернации, когда я использовал копию оригинала, это исправилось.

надеюсь это поможет

решение2

Наконец, я переустановил Windows на диск C (SSD), и когда это было завершено, система снова заработала, но последовательность загрузки закоротила GRUB. Так что теперь установка Linux невозможна.

Он все еще находится на моем диске D, и я знаю, что мне придется просто вставить Live CD и восстановить GRUB, чтобы он заработал, но я еще этого не сделал по другим причинам.

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

Полагаю, что изучение всего, что касается загрузки, в каком-то смысле верно. Весь процесс «загрузка с жесткого диска (IRRT) -> GRUB -> Правильный указатель на загрузчик Windows -> Расположение последовательности инициализации «выхода из спящего режима»» должен был где-то дать сбой, причем такой, что ни один обычный инструмент восстановления не смог бы его исправить.

В конце концов, я не смог понять проблему, и теперь моя система переустановлена, так что у меня, вероятно, никогда не будет дополнительных подсказок о том, что произошло. Если однажды у меня будет достаточно знаний о процессе загрузки, IRRT, Windows, GRUB и специальной конфигурации моего диска, я, возможно, придумаю лучшее объяснение.

Но сейчас я скажу следующее: судя по всему, на этой конкретной конфигурации (Dell M4600) наличие GRUB на IRRT с Linux на «реальном» жестком диске и Windows на mini-PCI-express SSD с активированным режимом гибернации кажется небезопасным, поскольку BSOD все еще случаются даже при отключенном GRUB (что означает, что теперь весь процесс загрузки контролируется Windows, и даже при этом могут возникнуть проблемы с выходом из режима гибернации — возможно, здесь играет роль размер 12 ГБ оперативной памяти и, следовательно, 9 ГБ файла hyberfil.sys), и поскольку один из этих BSOD мог убить мой раздел NTFS в моей предыдущей конфигурации без какой-либо аппаратной неисправности (потому что мой SSD все еще работает очень хорошо — хотя я не проверял его состояние подробно), я не вижу причин, по которым это не может произойти снова.

Итак, решение существует, и оно не очень приятное, но местонахождение этой конкретной проблемы пока не ясно. Если у кого-то есть более подробная информация, я был бы очень рад ее услышать.

Связанный контент