Битовая карта блока повреждена acronis
Обновлено: 07.07.2024
О системе: Ноутбук Sony VGN-AW1RXU/Q. На борту два SSD диска в Raid 0 (системный, может в нем проблема?). Операционка Vista ultimate sp1.
Подскажите пожалуйста, как лечиться от данной проблемы?
И что за том \Device\HarddiskVolumeShadowCopy1? Бывают ошибки и с томом 12,11 и т.д. Но их гораздо меньше. Больше всего 1.
Все ответы
Сейчас не у компьютера но помню номера событий:
У ошибки " Структура файловой системы на диск повреждена и не может использоваться. Запустите программу CHKDSK на томе \Device\HarddiskVolumeShadowCopy1 " - Код события: 55
У ошибки " Ошибка теневого копирования тома: Ошибка при вызове подпрограммы на поставщике теневого копирования. Данные подпрограммы PreFinalCommitSnapshots " Код события: 12293
И не подскажете что за том \Device\HarddiskVolumeShadowCopy1 или как определить где он находится?
Вы уже выполняли проверки, что видно из поста.
Я бы порекомендовал Вам воспользоваться программой mhdd для проверки целостности жёсткого диска. Возможно аппаратная неисправность.
Так же последняя ошибка
У ошибки " Ошибка теневого копирования тома: Ошибка при вызове подпрограммы на поставщике теневого копирования. Данные подпрограммы PreFinalCommitSnapshots " Код события: 12293
Да нет, дома проверил код события, именно 12293
Ошибка теневого копирования тома: Ошибка при вызове подпрограммы на поставщике теневого копирования . Данные подпрограммы PreFinalCommitSnapshots(, 1) [hr = 0x8000ffff].
Операция:
Выполнение асинхронной операции
Контекст:
Текущее состояние: DoSnapshotSet
А вот что ChkDsk выдает в режиме чтения, даже после того как прогнал с исправлением:
Метка тома: system.
Обработано записей файлов: 138240. Обработано больших записей файлов: 464. Обработано записей поврежденных файлов: 0. Обработано записей дополнительных атрибутов: 2. Обработано записей повторной обработки: 62. Обработано записей индекса: 179352. Обработано неиндексированных файлов: 0. Обработано дескрипторов безопасности: 138240. Очистка от неиспользуемых индексных записей 5 в индексе $SII файла 0x9.
Очистка от неиспользуемых индексных записей 5 в индексе $SDH файла 0x9.
Очистка 5 неиспользованных дескрипторов безопасности.
Обработано файлов данных: 20557.
CHKDSK проверяет журнал USN..
Оставшаяся страница USN по смещению 0x267dddd0 в файле 0xfb95 должна быть заполнена нулями.
Длина записи журнала USN 0x1000 по смещению 0x267de000 в файле 0xfb95 больше чем оставшаяся длина страницы 0x600.
Проверка сегмента записи файла журнала USN.
Обработано байт USN: 37611008. Завершена проверка журнала USN
Неверная битовая карта тома.
Windows найдены ошибки файловой системы.
Запустите CHKDSK с параметром /F (fix) для их исправления.
112301055 КБ всего на диске.
32315860 КБ в 115430 файлах.
66148 КБ в 20558 индексах.
247283 КБ используется системой.
65536 КБ занято под файл журнала.
79671764 КБ свободно на диске.
Размер кластера: 4096 байт.
Всего кластеров на диске: 28075263.
19917941 кластеров на диске.
В предыдущих статьях мы неоднократно затрагивали тему повреждений HDD. Но что случится, если эти повреждения приобретут массовый характер во всего лишь одном накопителе? Такое развитие событий приведет к неизбежному сбою главной таблицы файлов диска и ряду других неприятных последствий.
Что такое главная таблица файлов?
Главная или Общая таблица файлов диска (Master File Table, MFT) — документ, хранящийся исключительно в файловой системе NTFS. Он является важнейшим винтиком в механизме работы данной системы, поскольку хранит в себе такую информацию как размер, дату и время записи, содержимое файлов.
Любой документ, загружаемый в NTFS, будет записан и в MFT. В случае удаления, файловое пространство будет помечено как свободное и находящееся в ожидании дальнейшей перезаписи. Если же главная таблица файлов была повреждена, все документы в разделе NTFS станут недоступными.
Симптомы повреждения
Как и в случае с любой другой ошибкой, повреждения MFT также не проходят бесследно. Они проявляются следующим образом:
The type of the file system is NTFS.
Volume label Work Folder.
Corrupt master file table. Windows will attempt to recover master file table from disk.
Windows cannot recover master file table. CHKDSK aborted.
Примечание:
Volume label (метка тома) — это название диска, которое в вашем случае может отличаться.
Причины ошибки
В большинстве случаев, повреждение раздела NTFS смело свидетельствует о наличии сбоя главной таблицы файлов. Причин, способных спровоцировать возникновение неполадки, существует множество, но мы разберем самые основные:
- Сбой в работе операционной системы. Например, BSOD (синий экран смерти).
- Вирус, предназначенный для повреждения MFT.
- Неправильное извлечение диска (вы могли отключить его в момент неполного завершения работы компьютера).
- Сбой приложения.
- Наличие битых секторов.
Вне зависимости от причины возникновения неполадки, всегда есть шанс на восстановление диска и данных на нем. Каждая из приведенных ниже инструкций позволит своей простотой существенно сэкономить ваше личное время с большой долей вероятности вернуть HDD к жизни. Приступим!
Восстановление поврежденной таблицы файлов
Дефрагментация диска
В некоторых случаях причиной отказа работы MFT и, как следствие, всей системы NTFS является чрезмерное фрагментирование диска. Решить этот вопрос можно следующим образом:
1. Откройте Мой компьютер .
2. Щелкните правой кнопкой по логическому разделу или физическому диску, с которым предстоит работать, и перейдите в Свойства .
Задача поставлена такая, взять с диска E: 100 ГБ и присоединить к диску C:, чтобы он составлял примерно 200 ГБ.
В данной ситуации с помощью средств самой операционной системы такую операцию не провернёшь, поэтому я решил использовать программу Acronis Disk Director,
загрузившись с загрузочного диска программы я первым делом отщипнул от диска E: 100 ГБ. Щёлкаем правой мышью на диске E: и выбираем в меню "Изменить размер тома",
появится вот такое окно. Изменим размер выбранного тома (E:) в меньшую сторону так, чтобы незанятое пространство оказалось перед томом (E:) и после диска (C:), ставим 100 Гб, затем освободившийся объём прибавим к диску (C:) и он станет на 100ГБ больше.
Цепляем правой мышью за своеобразный разграничитель и ведём его вправо, уменьшая тем самым пространство диска E: на 100 ГБ и нажимаем ОК. Появляется нераспределённое пространство 100 ГБ.
Теперь уже щёлкаем правой мышью на диске C: и выбираем в меню "Изменить размер тома",
появится следующее окно. В нём ведём разграничитель вправо до конца, этим самым увеличивая диск C: на 100ГБ и ОК.
Наша программа работает в режиме отложенной операции и чтобы все наши действия заработали нужно нажать кнопку "Применить ожидающие операции" и "Продолжить".
Вот здесь внимание друзья, иногда может выйти ошибка "Файловая система повреждена. Используйте средство проверки для обнаружения и исправления ошибок файловой системы". Что делать? Рассказываю дальше.
Делаем выход из программы Acronis и перезагружаемся.
После перезагрузки сразу входим в "Управление дисками" и видим странную ситуацию. Диск C: какого был объёма такого и остался 97ГБ, а диск E: стал меньше 552, 13 ГБ.
В это время вы начинаете костерить меня и мою статью и ещё программу Acronis, а я тем временем начинаю соответственно икать.
Опять загружаемся с диска программы Acronis Disk Director. Проделаем вот что. Отщипнём от диска C: или D: небольшой кусочек пространства и оставим его нераспределённым, затем загрузимся в операционную систему и присоединим его обратно к диску С:, но уже с помощью служебной программы Windows "Управления дисками".
Щёлкаем правой мышью на диске C: и выбираем в меню "Изменить размер тома",
появится следующее окно. В нём ведём разграничитель влево на 10 ГБ, этим самым уменьшая диск C: на 10ГБ и ОК.
Наша программа работает в режиме отложенной операции и чтобы все наши действия заработали нужно нажать кнопку "Применить ожидающие операции" и "Продолжить". Выходим из программы и перезагружаемся.
Как видим, вместе с нашими десятью гигабайтами к диску C: вернулось всё пропавшее пространство. Цель достигнута, диск C: стал в объёме 197, 78 ГБ.
Либо не позорьтесь, либо приведите конкретно, что вы имеете в виду.
2Миша - вообще, размер раздела прописывается в двух местах. Это мбр - основная таблица разделов, и ещё в бут-рекорд (он у каждого раздела свой). Вот тут и могут быть те самые баги - в какое-то из мест забыли прописать.
Т.к. тема является архивной.
Т.к. тема является архивной.
Т.к. тема является архивной.
Т.к. тема является архивной.
Т.к. тема является архивной.
Я, конечно, многие тонкости за последние лет 15 мог подзабыть, т.к. последний раз в этом копался на предмет сертификации, но кое-что еще помню ;)
Т.к. тема является архивной.
Вы просто многое смешали в кучу. Я, в принципе, уже написал выше, в чём могла быть проблема.
Разметка GPT - это просто новый тип разметки, поддерживается начиная с Висты.
GUID тут ни при чём, это вы так просто разметку назвали. Хотя, может я неверно понял. Но винда берёт размер раздела, в первую очередь, не из МБР. А из поля big sectors total (вроде так) из бут-записи.
Правда, есть ещё какой-то внутренний GUID у разделов вроде, это именно идентификатор, к разметке не имеет отношения. К размерам - тоже.
Рэйд и динамические диски - это не некая база данных, а метаданные файловой системы, опять же. Допускаю, что это ещё и в реестре может жить параллельно, но сильно вряд ли это имеет отношение к Мишиному багу. У него же обычный раздел был, скорее всего. Если раздел превращается в динамический, это будет видно сразу, у него даже в МБР будет другой код.
Может быть что-то изменилось в 8. Но семёрку я как-то пробовал растягивать с помощью какого-то клонера, но он только файловую систему модифицировал и ни в какие файлы никуда не лез.
В 10 сделали что-то более навороченное, какие-то windows storage spaces. Эти ещё не попадались, но поддержку у себя мы сделали.
Т.к. тема является архивной.
Чисто для информации, GPT это GUID partition table.
И метаданными вы как раз и называете базу данных.
Параллельное представление в реестре или других служебных файлах началось еще с w2k, некоторые задатки были еще в NT , именно поэтому были забавные траблы, когда винду ставили на предварительно разбитый и отформатированный другой операционкой диск
Т.к. тема является архивной.
Про аббревиатуру GPT, это лишнее. К теме это отношения не имеет. Мы тут про MBR. Я же уже указал, что это просто другой формат разметки, так как МБР с ограничениями. Конечно, там используются GUID. Повторюсь, это только идентификатор. Достаточно универсальный, 128 бит. Много где используется. Но к вышеописанным траблам имеет косвенное отношение.
Про NT если это и было, то сейчас таких проблем точно давно не видел. С этим лучше к Мише, он расскажет, как он это успешно делает минимум раз в неделю. А я закругляюсь :) Но вопрос про конкретику остаётся в силе (где именно и какие значения и ветки реестра хранят размеры логических разделов, при условии, что никаких динамических дисков, рейдов и т.д. никто не делал) - мне это, по-прежнему, интересно.
Т.к. тема является архивной.
Т.к. тема является архивной.
Разделы точно были сделаны изначально Акронисом (систему я ставил).Т.к. тема является архивной.
Читайте также: