Rubicon2014
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору IAMLegenda Моя эпопея походу закончилась.кто следил тот знает-вернее в курсе.Больше месяца прошло и удалось победить. восстановленный образ был битый поэтому надо было восстанавливать транслятор. Без Кикмана ваще ничего бы не было. сначала он мне С восстановил.Потом убил)) Потом аж 8ч. чегото делал и вуаля-винда запустилась но без Д. Вебмани и т.д. заработало. потом опять хххх часов и диск Д появился!! Все расшифровал скопировал куда надо..Ща убираем бэды-делаем образ винды и чистим марвелом ди ск.Вроде так. Короче-если у вас проблемы- и нужна помощь,обращайтесь к Кикману. Спс тебе большое! упд.БЕСПЛАТНО-парень ничего не просил,в отличии от некоторых упд.не реклама,просто спс и восхищение Kickman Я дополню. Транслятор восстанавливал на основе P-list, восстановленного из лога селф-скана. Нашлось всего 2 сдвига на весь диск, оба в системном разделе. +несколько областей с BAD~ами. +конец диска вообще обнулён, а как раз там и лежал архив системного раздела, конкретно файл ".002". Он и погиб, этот .002. Не удалось найти его начало никак. Что-то с транслятором конца диска случилось . Ну да ладно, автору проблемы этот конец и не нужен оказался. Первый сдвиг, 250 секторов, попал внутрь файла System.ServiceModel.dll - файл оказался не критичным, лежал в winsxs. Второй сдвиг попал на program files\freetime\formatfactory\ffmodules\encoder\codecs\quicktime.qts - файл тоже убит, но не критичен. Сдвиги вычислял с помощью DMDE и инструмента "Карта кластеров". Было бы удобнее, если бы иметь возможность искать секторы, содержащие все нули, или наоборот, такие, где НЕ ВСЕ НУЛИ. Искал по заголовкам файлов. EXE, DLL, AVI, PNG и т.п., начала которых легко распознавать. Оба сдвига оказались в районах с BAD-секторами. Поступал так: очистил списки G+Relo, P. Восстановил P из лога селф-скана. Пересчёт транслятора с учётом P. Снова очистил G+Relo, чтобы избежать Pending~ов и прочей мути. Диск начал удовлетворительно работать в DMDE, отобразил первый раздел. Второй поискал поиском загрузочного сектора, нашёл сдвиг в 274 сектора. Стал искать сдвиг по заголовкам файлов раздела с помощью карты кластеров, от половины, потом снова делил пополам, и так далее. Когда нашёл, на каком файле сдвиг, то с помощью WDmarvel сделал "Добавить дефект в G-list по LBA" - увидел его адрес в G-list в виде дорожки, головки, сектора. Дальше - внёс нужный диапазон секторов от этого адреса в P-list, пересчитал транслятор с учётом P-list. Всё. Сдвиги пропали. Данные на месте. Винда запустилась. Потом долго проверял второй раздел, там сдвигов НЕТ!!! Но конец обнулён, данных не видно, около 2 Гб, наверное. Точно не помню уже. Чекдиск, вроде, даже не ругался на разделы. Или чуть-чуть на системный. То есть, все служебные структуры уцелели. Потом, для первоначального оживления, чтобы без BAD~ов прочитать системный раздел, выполнил в Виктории в режиме PIO: Verify+REMAP. В режиме API - не работал REMAP! По номерам REMAP~нутых секторов (оказались софт-бэды) в DMDE проверял в карте кластеров принадлежность этих "битых" секторов файлам. Критичных файлов на системном разделе не пострадало. Можно архивировать системный раздел на другой носитель, диск довести до ума в WDmarvel, накатить из сохранённого архива систему на освежённый диск и радоваться . Возможно, даже второй раздел не пострадает при ремонте . Добавлено: Ещё была трудность в том, что сначала не хотели дефекты добавляться по LBA. И транслятор пересчитывался больше 3 минут без видимых признаков работы. Минут за 5 в итоге стал пересчитываться. Всё это выяснил и устранил, когда несколько часов провёл, ковыряясь в служебке и её разных копиях, очищая модули и комбинируя их... это была подготовка. А потом дня 3 работы... По первости. Теперь-то опыт появился кое-какой. Увлекательное было мероприятие . Добавлено: Можно назвать "Восстановление транслятора по-живому" на диске с данными. n_so Цитата: Дальше - внёс нужный диапазон секторов от этого адреса в P-list | Равный сдвигу? По вашему тексту - 274. А как вы точный адрес нашли? Или удовлетворились произвольным в пределах битого файла? Kickman Именно так. Посмотрел, где в битом файле начинаются нули, и этот сектор внёс как дефект по LBA в G-list. И адрес +250 для первого сдвига или +24 для второго сдвига. Повезло, что сдвиги вместились в одну дорожку по одной головке, иначе пришлось бы повозиться чуть дольше. Самое длительное было - это подготовка служебки (чистка списков дефектов и пересчёт транслятора) и поиск мест сдвигов. Однако, нулей там было явно больше, чем сдвинутых секторов. Но файлы не критичные, вот список: Кластер 5464790 в начале смещение 0 System.ServiceModel.dll – а в конце смещён. Будет битый. 43925907 – пошли нули в секторах 43937122-43936872=250 Кластер 5846885 секторы 46982178-1928=250 Смещён между ними файл codecs \ quicktime.qts – он будет битый. Кластер 5847995 46991082-990808=274 Ну, и ещё по поводу БЭДов (сканил Викторией перед работой в WDmarvel): Нули в секторах 9375888-9375903, из них #9375893=BAD – REMAP, файлов нет 14211072 Error: ABRT prog_f\Intel\IRST\es-ES\IaStorHelp.Resources.dll Driverstore\filerepository\cw122944.inf_x86_neutral_4cb34b2046e37038\B123158\atieclxx.exe 15028224 Error: ABRT не подтвердились или перезаписаны 15157248 Error: ABRT не подтвердились или перезаписаны 15204352 Error: ABRT не подтвердились или перезаписаны 15237120 Error: ABRT не подтвердились или перезаписаны 43925504 Error: ABRT windows\winsxs\...\System.ServiceModel.dll 46987264 program files\freetime\formatfactory\ffmodules\encoder\codecs\quicktime.qts 48867328 Error: ABRT windows\winsxs\...\ntkrnlpa.exe 75917312 Error: ABRT windows\Installer\13ecaac2.msp 90075136 Error: ABRT 90076016 - пусто 90814464 Error: ABRT пусто 96264192 Error: ABRT ничего существенного 96327680 Error: ABRT ничего существенного szlodey Можно немного подробнее как вы искали "сдвиг", как вообще понять что это оно? Kickman в DMDE открываем файловую систему тома(раздела), берём карту кластеров, смотрим файл с характерным началом из последних кластеров на разделе (в районе 7 млн или 8 млн для 64Гб-ного раздела). Например, EXE/DLL начинается с "MZ". А мы видим там в соответствующем секторе чушь. Запускаем "поиск": сектор, содержащий "MZ" в позиции 0 от начала, вперёд. Находит невдалеке. Считаем разницу секторов, у меня получилось 274. Сокращаем наполовину, смотрим в районе кластера № 3-4 млн. В итоге, находим конкретное место, где данные на месте - а сразу в следующем файле уже не на месте. Между ними могут быть (на месте сдвига) нули или BADы. Затем эти секторы диска (строго по сдвигу) исключаем из транслятора. Если "нулёвых" или "BAD"овых секторов было больше, чем исключили, то файл пострадал (у меня получилось именно так, благо, файлы были не критичные). Как-то так. Это надо пробовать. Если есть подопытный, могу показать на нём. Учтите, это долго. Добавлено: Дополню, как я решился на это дело: Ссылка Ссылка szlodey Спасибо доступно объяснили. Если у нас разрыв попадет между известными файлами на большой кусок неиспользованного пространства, то как я думаю нужно с битого файла (который следующий за нормальным) посекторно читать назад и как только нарвемся на первый бэд - это и должен быть софтбэд вызванный разъездом и с этого адреса и вносим в плист? Хотя если битый файл некритичен как я понял вы заносили прямо с него? Kickman Куча вопросов... Попробую ответить пошагово. Задача стояла восстановить транслятор, чтобы восстановить данные. Поэтому я не очень-то обращал внимание на содержимое секторов и BADы. Получилось так, что начало файла на месте, а конец сдвинут вперёд на 250 секторов. Поэтому я стал искать в пострадавшем файле сектор, заполненный нулями - и внёс его как первый исключаемый. Пролистал файл вперёд - в секторах нули или BADы. До конца файла было далеко, я добавил 249 к номеру первого внесённого сектора, внёс сектор с полученным номером как последний исключаемый. Итого исключив 250 секторов. В списке G-list (изначально пустом) стало видно, что эти дефекты находились на одной дорожке&головке. Я внёс эту группу секторов ОТ первого и ДО последнего в P-list, и удалил 2 дефекта из G-list, перезапуск F/W, запустил пересчёт транслятора с учётом P-list. Сдвиг убрался. Однако, в пострадавшем файле было "нулёвых" секторов больше, чем я исключил, так что файл погиб. Но он не нужен. Второй сдвиг был на 24 сектора, а ситуация полностью аналогична. Файл тоже пострадал. Начало на месте, конец съехал, в середине нули и BADы. После исключения - нули и BADы остались, хотя и в меньшем количестве, чем ДО исключения. Поскольку диапазон секторов исключался скорее по принципу "от балды", чем по принципу выбора реально битых секторов, то на диске со временем могут вылезти BADы. Перезапись их вылечила, но надолго ли (?)... Реверсом читать не пробовал, ибо без нужды. Задачи восстановить ВСЁ не стояло, а ко всему нужному доступ получен |