Слетела файловая система диска
 

По непонятным причинам слетела файловая система диска системного диска С. Компьютер выдает синий экран с ошибкой 0x000000ED. Грузился с ERD Commander. Он операционную систему не находит. Диск С показывает размером 0kB без файловой системы.
Точно такая же проблема обсуждалась здесь http://forum.oszone.net/thread-211160.html . Там человеку посоветовали воспользоваться программой DMDE - DM Disk Editor and Data Recovery Software GUI для Windows 9x/ME/2K/XP/Vista/7. http://dmde.ru/download.html и как я понял она помогла. Вообщем загрузился я с DMDE . Диск С с файловой системой NTFS прога разглядела. А что делать дальше, как всё восстановить непонятно.

И мне непонятно. --- Где скрин окна Разделы диска...???...

И из Управления дисками тоже скрин экрана покажите...

Извиняюсь, с этого надо было начинать. [IMG][/IMG][IMG][/IMG]

Markus-x, посмотрел скрины...
Похоже дело не в ошибках разбиения и томов. --- Скорее битые файлы системы...

Покажите рапорт SMART вашего харда. Только не на сотовый телефон скрины делайте (смотреть тяжело, и всякое желание возиться с Вами пропадает...), а как положено...

Markus-x, MHDD блоки UNC поищите. Их должно быть.

Здравствуйте Markus-x,

Как уже намекнули, возможно, проблема в самом накопителе. Скажите, пожалуйста, если на него имеется важная информация. Если да, то, перед каких либо тестов рекомендую восстановить файлов так, как если диск на самом деле приказывает долго жить, нагрузка тестов может привести к неприятности с восстановлением.
После диагностического теста, выложите скрин СМАРТ статуса здесь так, чтобы все строки и значения в колонках были видны и удалив серийного номера диска.
Не помешало бы проверить состояние гарантию на сайт производителя.

Держите нас в курсе,
Frost_WD

Заранее извиняюсь за скриншоты. Не получается их создать нормальным способом. MHDD должна их сохранять в файл SCRSHOT.LOG, только нет такого... Так что опять телефон в помощь.
Вообщем вот что получилось: [IMG][/IMG]
Есть 3 блока UNC. Думается что не много. Мне хотя бы программу минимум выполнить- скопировать с диска С фотографии и документы :)

Велико значение атрибута SMART ID = C7 (199), показывающее число интерфейсных ошибок. Основные причины, --- гнилые контакты (поменять data-кабели), переразгон по шине, драйверы.

А так, ничего сложного нет…
Пендинги можете легко затереть/переназначить и нужные файлы тоже просто вытянуть…

ЗЫ Можете интереса для узнать имена битых файлов (если таковые есть) с помощью NFI.EXE. LBA сбойных блоков секторов (255 секторов в блоке) у Вас есть. А конкретный сектор можно найти, если просканировать блок по одному сектору утилитой HDDScan или Victoria 4.46b/4.47 for Windows.

См. Утилиты Sysinternals Suite

Markus-x, 3 UNC элементарно правятся HDDRegenerator"ом (сейчас в меня полетит куча кирпичей), после чего обязателен Scandisk, и примерно в 95% случаев этого достаточно для восстановления работоспособности ОС. И крайне желательно затем склонировать диск на новый, а этот для файлопомойки использовать.

Ловите первый кирпич (остальные может и не брошу, потому, как лениво...), что это за чудо такое (Scandisk)... И как оно работоспособность OS восстановит...???...

Markus-x,

Как уже предложили у вас есть очень много ошибки по Ultra DMA CRC. Замените САТА кабеля и подключите диск к другой шлейф. Имейте в виду, что это накопительный показатель, количество ошибки останется такое же, надо просто следить, если он растет.

Иначе, ничего пугающего нет. Как было предложено, сделайте ремап.
А по поводу фоток, рекомендую всегда иметь резервное копии подобных файлов ;).

Удачи,
Frost_WD

Хм, это девичья фамилия команды Chkdsk конечно же ))). Можно, ясен день, не запускать эту программу, и ОС сама исправит ошибки, ежели выставлена необходимость проверки.

Эта утилита проверяет целостность/корректность тома (как правило NTFS), но она никак не исправит неверные/битые файлы...

ЗЫ Порой наоборот надо запретить автозапуск чекдиска, чтобы утилита не натворила ещё больших бед...

А разве речь идёт об исправлении файлов?

Я такую речь заводил.... --- Внимательно посмотрите...

ЗЫ А чекдиск, если он будет нужен..., будет запущен из командной строки и без ключей...
Но об этом потом, после ответа Markus-x...

Tau_0
Да посмотрел, причём ещё раньше.
И давно уже заметил Опустим момент что знающий понимает о чём речь идёт когда пишут о проверке диска.
Но знающий должен понимать что при повреждении файловой системы (а не файлов) без чекдиска не обойтись.

Я понимаю, о чём идёт речь...

Но мне уже порядком поднадоело (паразитизм некоторых...), когда TS's сначала в личку со своей проблемой ломятся..., а потом надолго исчезают... А я забываю о чём конкретно речь шла (порою много чего посмотреть и впустую просчитать с арифметикой приходится)... Бывает, что и путаю их, когда спустя неделю они всплывают... А очень часто просто тихо по английски исчезают...

Поэтому впредь только по тактам/шагам (вопрос - ответ) свои действия и намерения излагать буду...

Доктор, меня никто не замечает и не слышит... (Анекдот старый)

Дык, я уже примерно в сотый раз пытаюсь объяснить, что в моей обширной практике ошибки UNC моментально исправляются некошерным регенератором. А Chkdsk только лишь подправить ошибки логические (именно неверные и битые файлы), буде таковые присутствуют.

Ещё проще (и правильнее) они лечаться той же MHDD.
Это точно, чего нелзя сказать о - ну разве только если под таковыми подразумевать метафайлы, про которые обычные пользователи не в курсе.

Tau_0
Кстати, MHDD сразу выдаёт точный номер LBA, поэтому лишнее гоняние не нужно.
И не понял зачем делать пустые расчёты, как и таковые действия?

Не надо нас дурить... --- Плавали --- знаем :gigi::gigi::gigi:
--- MHDD тестирует блоки секторов BlockSize = 255 секторов (хард блочное устройство) и Выводится LBA Блока UNCR. А сбойных секторов в блоке может быть от одного до 255.
А у Victoria for DOS BlockSize = 256. Разница в размере блока всего на единичку… Поэтому часто задают вопрос, как так получается, что утилиты показывают разные LBA UNCR…???... Вот из-за этой единички и получается…

Можете проверить --- создайте в MHDD сбойный UNCR сектор, LBA которого Вы будете знать. И протестируйте (для скорости узкий диапазон) с этим UNCR обеими утилитами. --- Получите разные LBA’s для блока, содержащего UNCR сектор. Причём LBA этих блоков не совпадут с тем точным значением, которое Вам известно. Поэтому и приходится для нахождения точного адреса бэда (-ов) повторно сканировать блок, но уже по одному сектору…
===========

А насчёт пустых прикидок, так это не этого случая. Но бывает, что внимательно перелопатишь в MFT кучу файловых записей (а это время…), а TS пропал…

Это из области фантастики... Если хард не может выбрать бэд, то дегенератор его тоже не выберет... Он может только записать в этот бэд какой-то мусор, но это не есть восстановление сектора...

Зачем, если я это делал не раз и крайний раз буквально с неделю назад?

Тогда почему пишете ахунею...???... ===>
ЗЫ Если создать бэд в LBA = 255, то Victoria выдаст адрес UNCR = 0, а MHDD UNCR = 255.
ЗЗЫ Вы далеко не первый, кто на это не обратил внимание. --- Для особо упёртых я даже на кибере скрины выкладывап...

Докладываю о проделанной работе. Заменил SATA кабель, сбросил BIOS, стер бед блоки в MHDD через команду erase. При повторном сканировании они больше не появляются. Только вот по сути ни чего не изменилось диск С по прежнему размером 0kB без файловой системы. Чувствую что упустил что то важное. Диск D свободно читается. Вообщем скопировал все полезное с диска D. Хотелось бы сделать подобное с диском С и переустановить ОС. Только наверное придется проститься со старыми фотками. Впрочем вперёд наука как хранить важные файлы на системном диске... :flag:

Попробуем их достать..., а может и раздел удастся восстановить...???...
1. Скачайте DMDE 3.0.6

Распакуйте и запишите на любой носитель. Достаточно на флешку записать, редактор прост в использовании и не требует установки.
Запустите DMDE и покажите картинку с разделами диска. Должно быть примерно как на второй картинке из DMDE GUI для Windows

2. Покажите картинку из Управления дисками
Пуск ===> Выполнить ===> diskmgmt.msc

После просмотра картинок продолжим...

Всё делал в среде ERD Commander. DMDE 3.0.6
Управление дисками из ERD Commander (другое не запускается) (вообщем то что и было в начале)

Markus-x, нет у меня такого мелкоскопа, чтобы Ваши иконки рассмотреть...:(
Выложите снимки с нормальным разрешением...

Скачайте LiveCD_Seven+LEX --- в сети полно. Запишите на CD/DVD и загружайтесь с него...
А ERD Commander вместе со средой фффтопку...

Добавлено
==========
Перечитал Ваши посты...

И чем Вы думали...???... Вы читать умеете, --- я ведь для Вас здесь писал...

Из-за одного паршивого сектора Вы затёрли целый блок из 255 секторов.
Сталинский подход, --- Лес рубят --- щепки летят...
Вам прямая дорога в НКВД

У меня вроде крупно открываются. Щелкаю по ним почти листок А4 получается. Правда я их сильно сжал, в оригинале фотки по 5 Гб были.

Скачивайте Live CD, --- придётся учить Вас нормальные скрины делать...
Картинки с фотокамеры рассматривать не буду...

У меня тоже, и всё прекрасно видно.
Хотелось бы увидеть дампы секторов 63, 61432559, 312576704 - в крайнем случае скриншоты.

А вы что - истина в последней инстанции?
Я не конспектирую свои действия, но сколько помню - в MHDD номер проблемного сектора соответствует действительному.
И когда я узнавал в ней этот номер, просматривал этот сектор - и он не читался.
Диск является блочным устройством? Хотите сказать что при тестировании тестируется не каждый сектор а только блок, причём только первый сектор? Или как?

Хард, --- по своей природе блочное устройство. Читать по одному сектору для него проблема... и слишком долго тест всего харда будет идти... И виктория и MHDD и все остальные утилиты, что я знаю читают блоками. Весть тест основан на временных задержках чтения блока...

Фиксируются именно блоки... Но, в Victoria For Windows или в HDDScan, размером блока можно управлять и для ювелирного нахождения бэда можно протестировать узкий диапазон секторов с BlockSize=1.

Мамой клянусь и зуб даю...:gigi::gigi::gigi:

А харды AF ни Виктория, ни MHDD не знают. Как-то, что-то при линейном чтении показывают. И пока нет бэдов, то оно нормально... --- Эмуляция 512 секторов срабатывает.

Но если есть бэды, то концы с концами не срастаются (4096 байтов, это не 512). И эти утилиты, хотя и не вылетают, но и не работают так, как нам бы хотелось...

Всё сделал! Вот настоящие скриншоты с LiveCD_Seven+LEX: [IMG][/IMG] [IMG][/IMG]
Эт я не подумал :not-me:
Не додумался как их добыть, подскажите и я всё выложу.

Запускаете DMDE в меню Сервис ===> Копировать секторы
Выбираете Источник -- у меня это Physical*Drive*0 [1.00*TB*WDC WD1002FBYS-02A6B0 : 03.00C06 : WD-WMATV8288537], а у Вас Ваш проблемный хард…

И приёмник (у меня это файл E:\Ответ\OSZone\Markus-x\dev0_lba312576704_1.bin), а Вы копируете куда хотите…

ЗЫ только имя файла не меняйте, -- оно мнемонично…
См. картинку

Tau_0
Зубов у тебя уже точно нет, надеюсь что хоть мама жива.
И нет ответа на вопрос оглашённый ранее. Зато много пустословия.
Понимаю что ответа не будет поэтому обьясняю - считывание может характеризоваться и блочно, но только читаются все сектора. Если этого не делать невозможно определить сбойный.
А вот дальше уже зависит от того как предусмотрел разработчик.
Можно сделать просто и быстро - показать номер начального сектора блока и пусть потом пользователь дотумкает что и как. А можно вывести и реальный (реальные) - для этого достаточно вспомнить на каком больше всего задержка или повторить исследование блока, но уже "с точностью до 1 сектора" причём безо всякого вмешательства пользователя.

Достал дампы секторов 63, 61432559, 312576704
Посмотрите пожалуйста если возможность что то сделать.

Мой ответ прост ===>

Я домыслами не занимаюсь... --- Я конкретно о MHDD и Victoria for DOS писал, а также о других утилитах, что я знаю...

Коли Вы не знаете/умеете, как просто проверить мои утверждения, это сделаю я.

Называйте LBA адрес сектора в диапазоне 1-2047. Я создам на на своей машине soft-bad и выложу скрины в подтверждение своей правоты...

Это не бла-бла-бла...
А там посмотрим кому зуб и язык (за пустой трёп...) и упёртость надо рвать...:gigi::gigi::gigi:

Markus-x
Возможность есть, но смотря о чём речь.
У тебя была повреждена 24-я запись и если бы сделал просто ремап секторов, то всё было бы нормально.
Сейчас у тебя затёрт какой то блок, а это уже больше 100 ни записей.
Чтобы узнать точно - нужен или дамп секторов 6291500+260 или лог поиска NTFS. А лучше и то, и другое.
И да, дамп 30716311+7

Tau_0
Конкретно, покажи где в MHDD изменить размер блока.
И что, не мог сам себе назвать LBA секторов - тех трёх что есть на скриншоте.
Вот по этим цифрам покажи как распределены блоки.
Там даже разница ни разу не кратна 255 (256).

Мне хотя бы фотки вытащить.

Мдя...???... А мне кажется, что с программулиной типа акрониса побаловались...

Посмотрел я разные цифири в блоках и получается, что в PT (таблице разделов) подрезан раздел System. По файловой системе он просится быть диском C:, а вместо него обрубок...

А подрезали, когда создали логический диск D: в расширенном разделе. Не сразу, но со временем логический стал затаптывать System, пока не затоптал до нехорошего...

См. картинки во вложении

Поведайте нам, как дело было...???... --- А у меня вот такие домыслы...

Мда. Я то точно с акрониксом не химичил. Однако в доме есть интернет и есть почти юные энтузиасты. А вот был ли изначально на этом компе диск D или его создали после, не уверен. Одно скажу точно файлы пользователя фото и т.д. в начале кидали на диск С. Однако следствие покажет :dwarf:

Дополнительная информация для следствия...

Для базовых томов есть 2 места, где хранится информации о размере:
1. Это таблица разделов в MBR в LBA=0.
2. Это boot-sector тома.
Тут есть маленькая тонкость и часто некая путаница возникает.
Раздел это просто экстент (некоторое число последовательных секторов). Указатель на экстент хранится в таблице разделов. На разделе создаётся том с ФС. В Вашем случае это том NTFS. Информация о размере тома хранится в boot секторе тома. Это самый первый сектор уже на томе.

В идеале размер раздела в PT и размер тома в бут секторе совпадают (размер тома на единичку меньше…) Но могут быть и отклонения. Нестрашно если размер раздела больше раздела тома. Но плохо когда наоборот…
У Вас, согласно PT, первый раздел (диск C: ) начинается в LBA = 63
Number of Sectors = 61 432 497 ~ 31 GiB
См. Картинку 1.

Теперь смотрим на бут NTFS (См. картинку 2) и видим---
Hidden Sectos = 63
Total NTFS Sectors = 312 576 641 ~ 150 GiB
Последний сектор раздела должен быть = 63 + 312 576 641 = 312576704
Это по файловой системе…

Видно, что этот гадёныш D: слишком много перекрыл…
Поэтому не думаю, что получится восстановит in-place.
Такие вот дела…

А я пока подумаю, как проще и лучше информацию вытягивать..

Tau_0
:clapping: И где ответы?
Создавалка сломалась? Или сам себе язык вырвал за пустобрех? :lol:

yab, а как насчёт более конструктивных соображений?

mwz
Что подразумевается под конструктивом?
Я уже давно написал про то, чем пользуюсь и вполне хорошо знаю возможности используемого.
Мне пытаются доказать обратное - я и хочу убедиться в правильности преложенного.
Что в этом не конструктивного?
Или что считается конструктивным? Предложение использовать дегенератор? Непонимание что (изначально было видно) есть несоответствия в бутсекторах, и начинать надо было с этого. Как и разобраться с тем что (судя по всему) на диске реально было два раздела и ничто не на что не налегло. Впрочем "налегания" что то слишком часто стали мерещиться Tau_0. :) Достаточно взлянуть ещё одну тему рядом.