Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.
Checking file system on C: The type of the file system is NTFS.
A disk check has been scheduled. Windows will now check the disk.
51199999 KB total disk space. 20071296 KB in 119720 files. 79484 KB in 21186 indexes. 1024 KB in bad sectors. 256567 KB in use by the system. 65536 KB occupied by the log file. 30791628 KB available on disk.
4096 bytes in each allocation unit. 12799999 total allocation units on disk. 7697907 allocation units available on disk.
Намертво подвисает компьютер, с определенной периодичностью
Компьютер подвисает на доли секунды с постоянной периодичностью Собственно где-то раз в час или в два комп подвисает, как при обращении к датчикам (как например в.
С высокой периодичностью подвисает система Такая вот возникла мерзость: примерно раз в минуту-две система подвисает на долю (от меньше чем.
Подвисает компьютер В совершенно произвольные моменты компьютер подвисает на некоторое время. А именно: все открытые.
Подвисает компьютер Добрый вечер уважаемые форумчане, прошу вас помочь мне решить проблему с подвисанием компьютера.
Нет, зависает полностью комп, видео, диспетчер не запускается, иногда, если видео работало то глючит звук( повторяется последнее мгновение очень быстро), зависают и программы вне браузера, т.е. полностью. кроме того если бы проблема была только в мышке то я не думаю что компьютер бы перезагружался. Хотя иногда мышь сильно глючит, указатель становится не черный, а почти белый, в светло розовую и желтую полоски если форма курсора, а если форма руки то она увеличивается раз в пять и тоже в полоску становится, как будто артефачит.
немедленно
Checking file system on C: The type of the file system is NTFS.
One of your disks needs to be checked for co may cancel the disk check, but it is strongl that you continue. Windows will now check the disk.
CHKDSK is verifying files (stage 1 of 3). 308736 file records processed. File verification completed. 943 large file records processed. 0 bad file records processed. 2 EA records processed. 97 reparse records processed.
Я вот думаю, возможно глюки начались после того как я винду обновил? кажется в то же время, сложно сказать. может попробовать откатить обновление?
немедленно
дык ошибок на диске куча была. успеете удалить, остальные почекайте хард по смарту как бык здоров
Добавлено через 1 минуту
пять стадий, странно что показывает 3, прошло все пять.(весь лог не влез, но имеет вот такой вид) One of your disks needs to be checked for consistency. You may cancel the disk check, but it is strongly recommended that you continue. Windows will now check the disk.
так, это просто был старый лог. PowerShell выдал логи старые=( Checking file system on C: The type of the file system is NTFS.
A disk check has been scheduled. Windows will now check the disk.
103259135 KB total disk space. 58221556 KB in 190537 files. 112988 KB in 36180 indexes. 0 KB in bad sectors. 415159 KB in use by the system. 65536 KB occupied by the log file. 44509432 KB available on disk.
4096 bytes in each allocation unit. 25814783 total allocation units on disk. 11127358 allocation units available on disk.
Windows has finished checking your disk. Please wait while your computer restarts.
Немного о восстановлении данных нестандартным способом
Прочитал интересную статью про то, как с флешки был восстановлен крипто-контейнер, поврежденный chkdsk’ом. Для восстановления были использованы весьма оригинальные идеи. Был проделан огромный объем работы. Это было реально сложно. С разрешения Andrey Sporaw публикую статью здесь, выражаю автору свое уважение и снимаю шляпу 🙂
Стоит начать с того, что эти четыре месяца выдались «жаркими» на события:
Как раз в эту субботу собирался делать бэкап. Ну это как обычно, в лучших традициях. Если умирать — так в день бэкапа. Для запускания chkdsk пришлось контейнер размонтировать. Итог…
Забегая вперед — статистика.
Использованные приложения: Disk Tools: WinHEX, R-Studio, Runtime DiskExplorer Compilers: Microsoft Visual Studio v2003, Virtual Pascal (к сожалению, этот продукт уже «мертв») Editors: HIEW, FAR
Это было реально сложно. Затраченное время:
Итого: 44.5 часов, или 1.85 суток, или 5.6 рабочих дней по 8 часов (реально в днях: вечер субботы — начало среды)
Возвращаясь к произошедшему.
Срочным образом запускаю WinHEX и делаю полный образ всей флэшки (как PhysicalDisk, не только Volume).
Все, на этом флэшку можно вытаскивать, в текущем виде она больше не понадобиться. Есть образ, с которым можно работать.
Предыдущий бэкап контейнера был, конечно же, достаточно давним. Месяц назад (вот сейчас ровно месяц). За это время было проделано достаточно много изменений данных, хранящихся в этом контейнере и нигде более. Терять эти данные не было возможности просто никакой. Многие вещи были бы безвозвратно утеряны, многие требовалось бы писать или делать с нуля, что с учетом затраченного времени, сильно откидывало «назад», и создавало нереальные проблемы.
Нужно было восстанавливать. Срочно. Время шло на часы.
Первое, что я решил попробовать, найти начало контейнера и тупо скопировать все данные от его начала и до конца volume. Надежды на то, что контейнер не будет фрагментирован вообще-то не было (я сразу же понимал, что это не решение вопроса). Но была надежда таким образом получить хоть какие-то данные.
Благо у контейнера есть специфический заголовок, который я знаю наизусть. Начало контейнера быстро было найдено. Скопировал данные в файл, подмонтировал. Файловая система обычным способом (через FAR) не прочиталась. Пришлось обратиться опять к R-Studio. Увидел все свои каталоги и проч. Однако, содержимое файлов, конечно же, оставляло желать лучшего. Практически все новые и измененные за последнее время файлы содержали мусор. Либо полностью состояли из мусора, либо были частично мусорными. Толку от этого для решения общей задачи было практически мало.
И вот тут-то и пришла в голову мне дельная мысль — воспользоваться резервной копией контейнера! Нет-нет. Не так, как вы подумали. Не забить на все и не банально восстановить все, просто взяв забэкапленный файл контейнера. Речь о другом.
Идея заключается в следующем. Файл-контейнера именно как файл (целое) постоянен. Если не запускать дефрагментацию внутри самого контейнера, неизменяемые мною или самой файловой системой участки контейнера остаются постоянными. Соответственно, если диск 2gb, и там никто особенно не «шуровал», не перемещал файлы туда-сюда, а просто работал — то есть вносил изменения в существующие файлы, добавлял новые, что-то изредка удалял и т.п., файл контейнера сильно не изменялся! Понятие «сильно не изменился», конечно, условное. Чем меньше было изменений фактических (то, что делали вы), чем меньше срок между текущим состоянием и последней резервной копией — тем, очевидно, лучше.
Забегая вперед скажу, что в моем случае неизмененными осталось 78.5% секторов.
Проблема с фрагментами заключается не только в их поиске по всему физическому диску (а это огромный объем для анализа — 4gb; чтобы понять это — попробуйте вручную хотя бы 20mb пролистать клавишей PageDown), но и в том, что фрагменты могут быть записаны в любом порядке! То есть совершенно не обязательно, что файл выглядит на диске так: FRAGMENT1, FRAGMENT2, FRAGMENT3 и т.д. Он выглядит как угодно, легко порядок может оказаться таким — FRAGMENT8, FRAGMENT1, FRAGMENT6, FRAGMENT5, FRAGMENT2, FRAGMENT3 и т.д.
Моя идея позволяет сразу же «убить двух зайцев». Во-первых, мы сразу же находим все (или почти все) фрагменты на диске. Во-вторых, мы определяем корректный порядок их следования!
Теперь уже, наконец, сама суть идеи.
Теперь у нас имелось два множества с MD5 секторов. Одно — от старого бэкапа, другое — от «свободного места» на текущем диске, в котором содержался текущий контейнер. Нужно было найти пересечение этих множеств!
Результат пересечения множеств — 78.5%. Остальные 21.5% — это измененные сектора диска.
Мое предположение заключалось в следующем (и полностью оправдало себя на практике) — изменения секторов более менее распределены по диску «локализованно». Соответственно, скорее всего, неизменные сектора окажутся в огромных количествах в каждом из имеющихся фрагментов диска. Что я имею в виду? То, что границы фрагментов будет определить легко. Либо граничные сектора не будут изменены, либо прилегающие к граничным секторам не будут изменены. Так и оказалось, у 5-и или 6-и из 10 (но можно считать, и 9-и) фрагментов, границы были определены очень четко, причем обе (как начало, так и конец).
У оставшей части границы пришлось поискать вручную. Но опять же, в виду того, что это шифро-данные, найти их границы не так сложно: эти данные выглядят как крайне случайный мусор. Как только этот мусор заканчивается — скорее всего, вы на границе.
Мешали этому только различные архивы (zip/rar), а так же инсталляторы (msi — считай, те же архивы). Если на стыке границы находился архив, было проблематично понять, имеют отношение эти сектора еще к фрагменту контейнера или это уже кусок архива.
Для решения этой проблемы была придумана еще одна идея: почистить сохраненный образ физического диска от… блоков, занятых файлами. То есть своеобразный жесткий wipe. Занулить все, что не относится к free space. (Это та самая утилита UsedBlocksEraser, которую пришлось написать для обработки bitmap).
Только благодаря этой утилите был найден один большой блок примерно на 50mb, в котором не было ни одного совпадения по MD5! (Вот вам и разрушение теории про «точно в каждлом блоке, найдется хотя бы несколько…»). Реально — ни одного. То есть все данные в этом фрагменте были либо изменены, либо были новыми.
Кстати, забыл рассказать о «втором зайце». Порядок следования. По вот этому логу он определяется элементарно. Лог имеет формат: смещение начала отрезка одинаковых секторов, смещение конца отрезка одинаковых секторов, их количество, размер в байтах. Смещения указаны в двух «системах счисления». Первая часть — это смещение внутри образа физического диска. Вторая часть — это смещение внутри резервной копии файла-контейнера. Теперь догадываетесь как «убить второго зайца»? Нужно просто отсортировать этот лог по вторым смещениям. Чтобы они следовали от нулевого (начала контейнера) до конца, по возрастанию.
После того, как я нашел (в своем представлении) все блоки, и в своем представлении определил их границы, я написал утилиту, вытаскивающие нужные блоки из созданного образа физического диска.
Кстати, вспомнил момент. Был реальный epic fail на полпути (из-за которого, кстати, было потеряно определенное время, потому что из-за него не нашлось часть пересечения и пришлось блоки искать вручную). Я, зная о том, что это большие диски (больше 2GB), почему-то все равно использовал обычные функции seek. Как итог — неправильно построенное множество MD5 для диска с физическим образом. Более того, еще хуже ситуация была на Virtual Pascal (одна из утилит была написана на нем) с типом Longint (не DWORD), который, естественно, умеет быть отрицательным. В общем, не забывайте, что нужно использовать 64-битные смещения и 64-битный seek! Не тупите. Особенно, если знаете об этом изначально.
В общем, диск был подключен. Файловая система прекрасно читалась через FAR. Файлы были доступны и все было отлично. Стал крайне внимательно (имеют опыт) сравнивать диски/файлы: восстановленную копию, копию в своей голове и резервную копию. Не сразу же, но нашел, что часть файлов (очень малая, но они есть) — битые. В них содержалась информация от других секторов. То есть где-то произошло смещение границ блоков! Мне очень повезло, что на этом контейнере у меня было
100 файлов, на которые было заранее рассчитано MD5. Я мог проверить их целостность и понять — битые они или нет. Так же, мне повезло, что это был не XTS-режим. В противном случае я не знал бы, что это смещены границы блоков. Точнее, я не смог бы понять: расшифрован полный мусор или это «правильные данные», но просто не на том месте. (В данном случае, мусорными были первые 16 байт сектора, остальное было нормально расшифрованным, но «не отсюда» — это особенность реализации алгоритма; кстати, если не было бы такого подмешивания — была бы нереальная проблема с коллизиями при рассчете MD5 — см. выше).
Символ «*» тут — это просто пропущены ненужные всякие названия.
Слева указывались смещения внутри файла контейнера, дальше количество секторов, размер, потом — смещение начала блока данных внутри файла, и смещение его конца, далее — полный путь к файлу.
Такой лог позволил мне увидеть, что все битые файлы находятся в пределах одного найденного мною блока. Более того, я понял, что битых файлов значительно больше, чем я предполагал (я нашел 10, а их было 55). Причем большинство из них, к сожалению, выпадали на бинарные файлы (по ним сложно понять — битый он или нет), и более того — на куски репозитория SVN!
Используя FO-смещения (информация о блоке внутри файла), я проанализировал несколько файлов. Тут как раз помогло то, что несколько файлов было текстовых, плюс файлы были разных форматов. По ним я понял, что произошло смещение на 32-сектора (4000h байт). То есть нужно восстанавливаемый блок просто сдвинуть «вниз» на 4000h байт. А как раз за этим «плохим» блоком шел ненайденный блок в 4000h-байт. Как оказалось, нужно было просто поменять местами эти два блока! Ненайденный блок шел до найденного.
Эти 4000h байт я не стал искать, посмотрев куда они попадают в контейнере: они попадают на область free space. То есть просто пустое место. Там может быть любой мусор и мне он неважен. Искать смысла нет никакого.
Результаты проделанной за 44.5 часов работы:
Все! Контейнер полностью восстановлен!
Надеюсь, эта статья и идеи кому-нибудь когда-нибудь помогут/пригодяться при восстановлении данных в схожей или иной ситуации.
Собственно, сабж. После проверки пропало около 80gb. Лог:
Checking file system on C: The type of the file system is NTFS.
A disk check has been scheduled. Windows will now check the disk.
CHKDSK is verifying files (stage 1 of 5). 149760 file records processed.
File verification completed. 683 large file records processed.
0 bad file records processed.
0 EA records processed.
80 reparse records processed.
CHKDSK is verifying indexes (stage 2 of 5). 193806 index entries processed.
Index verification completed. 0 unindexed files scanned.
0 unindexed files recovered.
CHKDSK is verifying security descriptors (stage 3 of 5). 149760 file SDs/SIDs processed.
CHKDSK is verifying Usn Journal. 33560352 USN bytes processed.
Usn Journal verification completed. CHKDSK is verifying file data (stage 4 of 5). Read failure with status 0xc00000b5 at offset 0x56e406a000 for 0x10000 bytes. Read failure with status 0xc00000b5 at offset 0x56e4079000 for 0x1000 bytes. Windows replaced bad clusters in file 116737 of name \Users\Dan\DOWNLO
1\BDMV\STREAM\00000.m2ts. 149744 files processed.
File data verification completed. CHKDSK is verifying free space (stage 5 of 5). 300509 free clusters processed.
Free space verification is complete. Adding 1 bad clusters to the Bad Clusters File. CHKDSK discovered free space marked as allocated in the master file table (MFT) bitmap. CHKDSK discovered free space marked as allocated in the volume bitmap. Windows has made corrections to the file system.
717441751 KB total disk space. 624425352 KB in 99244 files. 68572 KB in 22025 indexes. 4 KB in bad sectors. 91745783 KB in use by the system. 65536 KB occupied by the log file. 1202040 KB available on disk.
4096 bytes in each allocation unit. 179360437 total allocation units on disk. 300510 allocation units available on disk.
Windows has finished checking your disk. Please wait while your computer restarts. » Можно ли что-нибудь сделать без возврата к заводским настройкам?
В очередной раз телепатов поминать уже не хочется.
По сути, что за винда, что за диск, что за файловая система, «пропал» какой объем диска общий или свободный, почему пришлось делать чекдиск, сколько сейчас занимают место на диске все директории и файлы и т.п.
1\BDMV\STREAM\00000.m2ts Какого размера?
Добавлено через 1 минуту
Можно ли что-нибудь сделать без возврата к заводским настройкам? по той минимальной предоставленной вами информации можно только гадать об этом =)
И судя по этой строчке
91745783 KB in use by the system
эти 80gb система «забрала» себе.
эти 80gb система «забрала» себе. А до проверки какие были циферки и в какой программе смотрел.
Adding 1 bad clusters to the Bad Clusters File. И вот это место мне очень не нравится: по-правильному процик HDD обязан ремапить плохие сектора самостоятельно, а если дело дошло уже до BAD-кластеров. Не означает ли это, что твой HDD до такой степени «загибается», что весь резерв секторов для переназначения уже исчерпан?
Добавлено через 1 минуту
Короче: надо бы состояние регистров S.M.A.R.T посмотреть.
200КБ. Самолично пробовал накактать на дискету NTFS по инструкциям от Sysinternals. 😉 Только вот страдают этим единицы, ибо дискеты то из моды вышли, когда вошла в моду NTFS.
