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

Question

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

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

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

Теперь что случилось:

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Но сейчас я скажу так: по-видимому, в этой точной конфигурации (Dell M4600), с GRUB на IRRT с Linux на "реальном" жестком диске и окнами на мини-PCI-Express SSD с активированным спящим режимом, кажется, небезопасно, потому что BSOD по-прежнему происходят даже при отключенном GRUB (что означает, что весь процесс загрузки теперь контролируется окнами, и даже при этом могут возникнуть проблемы с выходом из спящего режима - возможно, размер ОЗУ 12 ГБ, и, следовательно, 9 ГБ Hyberfil Файл .sys, сыграть здесь свою роль), и, поскольку один из этих BSOD может убить мой раздел NTFS в моей предыдущей конфигурации, без каких-либо аппаратных сбоев (потому что мой SSD по-прежнему работает очень хорошо - я не проверял его работоспособность в глубоких деталях, хотя) я не понимаю, почему это не могло повториться.

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