Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.
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.
Имеем следующее железо: RAID контроллер Intel 82801 GR/GH, 4 SATA канала на которых висит: два винта по 320Гб в RAID1 назовем его DATA0, и два винта по 400Гб в RAID1 назовем его DATA1. ОС: Win 2003 Server + SP2
Периодически на томе DATA1 появляются ошибки, вот запись из логов: Сначала появляется вот это:
————— Event Type: Error Event Source: Ntfs Event Category: Disk Event ID: 55 Date: 22.10.2007 Time: 10:52:55 User: N/A Computer: SERVER Description: The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume DATA1. —————
Потом начинают сыпаться вот такие, с каждым файлом, к которому попытались сделать обращение на чтение-запись:
Запуск chkdsk выдает следующее:
————— chkdsk /f /x The type of the file system is NTFS. Cannot lock current drive. Volume dismounted. All opened handles to this volume are now invalid. Volume label is OFFICE.
268430052 KB total disk space. 108550092 KB in 163118 files. 56092 KB in 11040 indexes. 0 KB in bad sectors. 626636 KB in use by the system. 65536 KB occupied by the log file. 159197232 KB available on disk.
4096 bytes in each allocation unit. 67107513 total allocation units on disk. 39799308 allocation units available on disk.
После этого удаляются все эти файлы, которые chkdsk нашел. Это, как правило, те файлы, которые пользователи открывали на чтение-запись после первой ошибки. Если это была папка, то она не удаляется, а попадает в found.000
ДЕЙСТВИЯ ПО ДИАГНОСТИКЕ И УСТРАНЕНИЮ.
1. Заменены SATA кабели у обоих винчестеров массива DATA1. Проблема осталась. Не глюк кабеля.
4. Оба диска, составляющие массив DATA1 проверены на другой машине с помощью MHDD и Victoria. На винтах проблем не выявлено, SMART впорядке. Глюк не в винтах.
5. Содержимое массива проверено на вирусы. Не обнаружено. Проблема не в вирусах.
7. Установлено дополнительно охлаждение винчестеров, RAID-контроллера, процессора. Проблема не решилась. Причина не в перегреве.
8. Был установлен SP2. Проблема осталась. Причина не в обновлениях.
Родилось предположение, что контроллер хреново работает с большими дисками (диски в DATA1 больше чем в DATA0)
10. Установлен еще один RAID контроллер Tekram TR-824, DATA1 перевешен на него. Проблема не решилась. Глюк не в RAID контроллере.
Похоже проблема не аппаратная, а програмная (логическая). Смотрим что на диске записано. Всего около 500 тыс. файлов объемом
150Гб Из них встречаются файлы с длиной пути больше 255 символов (как они их делают, если винда даже зайти в такую папку не может?)
12. Все(?) длинные пути укорочены (папки заархивированы). Проблема стала появлятья реже(?), но не устранена.
Вроде бы все описал.
На support.microsoft.com нашел только вот это:
————— Аннотация В данной статье рассматривается процесс проверки выделения дискового пространства в файловой системе NTFS для определения вызывающих неполадки файлов и папок или обнаружения повреждений тома на компьютерах с Windows Server 2003.
Файловая система NTFS поддерживает ряд функций уровня дисков и файлов, которые могут стать причиной потерь и неправильного определения свободного пространства на диске. Например, том NTFS может неожиданно переполняться без видимой причины, а администратору при этом может быть сложно обнаружить причину или найти вызывающие неполадки файлы и папки. Эта проблема может возникнуть, если произошло злонамеренное или несанкционированное вторжение в том NTFS, на который тайно копируются несколько очень больших или очень много маленьких файлов. После этого разрешения NTFS этих файлов были удалены или ограничены. Эта неполадка также может возникнуть в случае повреждения тома в результате неполадок в компьютере или отключения питания.
Ошибки в данных о распределении дискового пространства тома NTFS могут возникать по указанным ниже причинам. • Размер кластера тома NTFS слишком велик для среднего размера хранящихся на нем файлов. • Атрибуты файлов или разрешения NTFS не позволяют отобразить файлы и папки или получить к ним доступ через Проводник или командную строку Windows. • Длина пути к папке превышает 255 знаков. • Папки или файлы имеют неправильные или зарезервированные имена. • Метафайлы NTFS (такие как основная таблица файлов [MFT]) увеличились в объеме и не могут быть освобождены. • Файлы или папки содержат альтернативные потоки данных. • Повреждение NTFS является причиной определения свободного пространства как используемого. • Другие особенности NTFS могут стать причиной неправильного выделения пространства под файлы. —————
Однако тут проблема не с неправильным распределением свободного места, а вообще глюки ntfs, в результате которых теряется информация
Что это такое? Какие будут идеи? Что еще можно попробовать? Уменьшить размер кластера (сейчас 4Кб)? А что такое «Папки или файлы имеют неправильные имена»?
Немного о восстановлении данных нестандартным способом
Прочитал интересную статью про то, как с флешки был восстановлен крипто-контейнер, поврежденный 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 часов работы:
Все! Контейнер полностью восстановлен!
Надеюсь, эта статья и идеи кому-нибудь когда-нибудь помогут/пригодяться при восстановлении данных в схожей или иной ситуации.
Имеем следующее железо: RAID контроллер Intel 82801 GR/GH, 4 SATA канала на которых висит: два винта по 320Гб в RAID1 назовем его DATA0, и два винта по 400Гб в RAID1 назовем его DATA1. ОС: Win 2003 Server + SP2
Периодически на томе DATA1 появляются ошибки, вот запись из логов: Сначала появляется вот это:
————— Event Type: Error Event Source: Ntfs Event Category: Disk Event ID: 55 Date: 22.10.2007 Time: 10:52:55 User: N/A Computer: SERVER Description: The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume DATA1. —————
Потом начинают сыпаться вот такие, с каждым файлом, к которому попытались сделать обращение на чтение-запись:
Запуск chkdsk выдает следующее:
————— chkdsk /f /x The type of the file system is NTFS. Cannot lock current drive. Volume dismounted. All opened handles to this volume are now invalid. Volume label is OFFICE.
268430052 KB total disk space. 108550092 KB in 163118 files. 56092 KB in 11040 indexes. 0 KB in bad sectors. 626636 KB in use by the system. 65536 KB occupied by the log file. 159197232 KB available on disk.
4096 bytes in each allocation unit. 67107513 total allocation units on disk. 39799308 allocation units available on disk.
После этого удаляются все эти файлы, которые chkdsk нашел. Это, как правило, те файлы, которые пользователи открывали на чтение-запись после первой ошибки. Если это была папка, то она не удаляется, а попадает в found.000
ДЕЙСТВИЯ ПО ДИАГНОСТИКЕ И УСТРАНЕНИЮ.
1. Заменены SATA кабели у обоих винчестеров массива DATA1. Проблема осталась. Не глюк кабеля.
4. Оба диска, составляющие массив DATA1 проверены на другой машине с помощью MHDD и Victoria. На винтах проблем не выявлено, SMART впорядке. Глюк не в винтах.
5. Содержимое массива проверено на вирусы. Не обнаружено. Проблема не в вирусах.
7. Установлено дополнительно охлаждение винчестеров, RAID-контроллера, процессора. Проблема не решилась. Причина не в перегреве.
8. Был установлен SP2. Проблема осталась. Причина не в обновлениях.
Родилось предположение, что контроллер хреново работает с большими дисками (диски в DATA1 больше чем в DATA0)
10. Установлен еще один RAID контроллер Tekram TR-824, DATA1 перевешен на него. Проблема не решилась. Глюк не в RAID контроллере.
Похоже проблема не аппаратная, а програмная (логическая). Смотрим что на диске записано. Всего около 500 тыс. файлов объемом
150Гб Из них встречаются файлы с длиной пути больше 255 символов (как они их делают, если винда даже зайти в такую папку не может?)
12. Все(?) длинные пути укорочены (папки заархивированы). Проблема стала появлятья реже(?), но не устранена.
Вроде бы все описал.
На support.microsoft.com нашел только вот это:
————— Аннотация В данной статье рассматривается процесс проверки выделения дискового пространства в файловой системе NTFS для определения вызывающих неполадки файлов и папок или обнаружения повреждений тома на компьютерах с Windows Server 2003.
Файловая система NTFS поддерживает ряд функций уровня дисков и файлов, которые могут стать причиной потерь и неправильного определения свободного пространства на диске. Например, том NTFS может неожиданно переполняться без видимой причины, а администратору при этом может быть сложно обнаружить причину или найти вызывающие неполадки файлы и папки. Эта проблема может возникнуть, если произошло злонамеренное или несанкционированное вторжение в том NTFS, на который тайно копируются несколько очень больших или очень много маленьких файлов. После этого разрешения NTFS этих файлов были удалены или ограничены. Эта неполадка также может возникнуть в случае повреждения тома в результате неполадок в компьютере или отключения питания.
Ошибки в данных о распределении дискового пространства тома NTFS могут возникать по указанным ниже причинам. • Размер кластера тома NTFS слишком велик для среднего размера хранящихся на нем файлов. • Атрибуты файлов или разрешения NTFS не позволяют отобразить файлы и папки или получить к ним доступ через Проводник или командную строку Windows. • Длина пути к папке превышает 255 знаков. • Папки или файлы имеют неправильные или зарезервированные имена. • Метафайлы NTFS (такие как основная таблица файлов [MFT]) увеличились в объеме и не могут быть освобождены. • Файлы или папки содержат альтернативные потоки данных. • Повреждение NTFS является причиной определения свободного пространства как используемого. • Другие особенности NTFS могут стать причиной неправильного выделения пространства под файлы. —————
Однако тут проблема не с неправильным распределением свободного места, а вообще глюки ntfs, в результате которых теряется информация
Что это такое? Какие будут идеи? Что еще можно попробовать? Уменьшить размер кластера (сейчас 4Кб)? А что такое «Папки или файлы имеют неправильные имена»?
