Assembler
.NET
Delphi
Windows
Reversing&Cracking
Шаолинь
Other
Форум Monah'а

Письма читателей #1

Автор: Adrax

Здравствуйте, уважаемые читатели! Знаю, что многие из вас злы на нашу команду по той причине, что мы не отвечаем на ваши письма. В который раз прошу прощения за это!
Жизнь отнюдь не балует нас, а уж свободное время - это для нас вообще роскошь. Потому и остаётся читательская корреспонденция неотвеченной, а, зачастую, даже и непрочтённой. Тем более, что письма к нам приходят, как правило, с серьёзными вопросами, требующими усиленной мозговой деятельности, а бывает, что и нам приходится признаваться в своей некомпетентности. Особенно обидно, когда помощи просит старый друг, а тебе нечего ему ответить...

Кроме нехватки свободного времени иногда возникают и другие проблемы. Помните, как мне нахаляву достался винчестер с повреждённой MFT? Так вот, работал он у меня вполне стабильно, почти не вызывая нареканий (ну, исчезла вдруг папка - запустил chkdsk - она вернулась), тем более, что мой компьютер подбрасывает и гораздо большие проблемы. Материнская плата Asus K8N не имеет разделения чипсета на северный и южный мосты - там конструктивно один "средний мост". И, хотя и оснащён он ребристым радиатором, греется довольно ощутимо. Видимо, данную модель материнских плат хреново тестировали в условиях повышенных нагрузок - а в моём компе при аптаймах в 10-14 суток минимум нагрев "среднего моста" даже при открытой крышке корпуса становится таким, что начинает бажить PATA-контроллер, делая невозможным запись CD/DVD-болванок. Смешно иногда получается: комп тарабанит две недели без передышки, а пришли друзья с просьбой болванку запалить - приходится ребутаться, чтобы "средний мост" слегка остыл:)

И вот, не было меня как-то дома двое суток (это было вызвано проблемами моего друга на личном фронте, и я его выручал) - компьютер я на это время оставил выключенным. Вернувшись, включил и попытался загрузиться - создалось такое ощущение, что я стартую Windows Vista на P-II. Я уже решил, что всё - спёкся PATA-контроллер окончательно
Минут через 10 после запуска экран озарился светло-голубым сиянием, и autochk принялась жаловаться на диск L: - мол, не читаются некоторые фаловые записи, а дескрипторы безопасности - вообще не видны. Целиком же запуск Windows занял не менее получаса

Надо заметить, что к этому времени раздел L:, физически расположенный на винчестере Karglak'а, представлял собой настоящую файловую помойку - наверное, не менее миллиона файлов. Разумеется, это вызвало дикую фрагментацию MFT

Лирическое отступление
Я уже писал об организации файловой системы NTFS (New Technology File System) от MicroSoft. Вкратце напомню основные моменты:
  • КАЖДЫЙ элемент NTFS представляет собой файл
  • Данные обо всех файлах на диске сосредоточены в MFT (MFT - тоже файл)
  • Под MFT резервируется 12% ёмкости раздела (впрочем, эти можно управлять, варьируя значение DWORD-параметра NtfsMftZoneReservation в HKLM\System\CurrentControlSet\Control\FileSystem от 1 до 4), под остальные файлы - соответственно, 88%
  • NTFS - журналируемая ФС с поддержкой транзакций
  • MFT состоит из файловых записей
  • Имя (имена) файла, его содержимое, дополнительные потоки данных, служебная информация и др. являются атрибутами файла и могут быть резидентными (располагаться прямо в файловых записях MFT) или нерезидентными (располагаться в кластерах на диске)
Если общий размер файлов на NTFS-разделе вырастает более 88% ёмкости диска, то NTFS отдаёт неиспользованное зарезервированное пространство (половину от тех 12%). Соответственно, расширяясь, MFT, лишившись этого зарезервированного пространсва, будет довольствоваться промежутками между файлами - так возникает фрагментация MFT

Так как MFT - это файл, его можно дефрагментировать. Множество утилит-дефрагментаторов похваляются этим умением, но десятки независимых авторов (в том числе и Мыщъх) утверждают, что это лишь маркетинговый ход. Доподлинно известно лишь одно - штатный дефрагментатор WinXP (Diskeeper Lite) не справляется с этим, да и вообще - ни с чем он не справляется. Ограничения штатного дефрагментатора таковы: за один раз можно перемещать не менее 16 кластеров, причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. К чему это приводит? Зацитирую Д. Михайлова:
"Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов"

Использование штатного дефрагментатора WinXP усиливает фрагментацию! Парадокс - но так оно и есть. Потому и качают люди Norton SpeedDisk, O&O Defrag, Diskeeper Pro - от них хоть какой-то эффект есть

А я свой диск L: не фрагментировал: не мог. Куча мелких файлов быстро заставила MFT занять все 12%, а крупные медиафайлы быстро съели остальные 88%. Нет, процентов пять оставалось, но дефрагментатору этого для манёвра не хватало - а я умудрялся добавлять ещё файлы, заставляя и без того фрагментированную MFT расползаться по "дыркам". Вот и дождался того момента, когда разрозненные куски перестали читаться...

Если винчестер Karglak'а был физически отключен (отсоединён от шлейфа) - система просто летала. Если же подключен - Windows дико тормозила. Тормозила при старте Explorer'а, при запуске ряда системных служб. Я так понял, что они при старте пытаются получить древо каталогов на жёстких дисках, а тормоза были вызваны невозможностью чтения с L: (когда я из diskmgmt.msc отнимал букву у диска L:, ситуация исправлялась; кстати, autochk видит и отмонтированные таким образом диски)
Когда L: находился в системе, Explorer видел его, но без метки. Попытка просмотреть свойства диска Проводником приводила к бесонечному ожиданию, dir L: в консоли - "параметр задан неверно". Зайти на L: не удавалось ни одним файл-менеджером, ни консолью - выдавалось сообщение об ошибке. diskmgmt.msc видела раздел L: (иногда со второй попытки), определяла его полный размер, но не видела метки. chkdsk, запущенная из консоли, могла даже прочесть метку диска, но потом сообщала о всё тех же ошибках: не читаются все дескрипторы безопасности, и ряд файловых записей читается с ошибками

Среди всего хлама, что лежал на диске L:, были и очень нужные мне файлы. Поэтому пришлось срочно искать утилиту для вытаскивания файлов с повреждённых разделов

Вообще, в настоящее время, восстановление файлов - не такое уж сложное занятие. Контроллеры жёстких дисков отучены реагировать на ATA-команду 50h (format track), поэтому при форматировании данные с диска не удаляются. Да что там форматирование - даже переразбиение на разделы оставляет огромный процент файлов нетронутым!
Чтобы не лазать по диску с hex-редактором, были написаны специальные утилиты для автоматического восстановления данных. Ведущие лидеры - R-Studio и Disk Explorer. Лично я использовал R-Studio 4.2

При форматировании/переразбиении есть хоть какой-то риск для данных. В моём же случае была повреждена лишь сама MFT, а, значит, файловые потоки крупных файлов лежали на диске в абсолютно нетронутом виде. Потому R-Studio вытянула всё, что мне было нужно, после чего я отформатировал диск L: и начал снова набивать его хламом:)

Вот такие весёлые приключения происходили со мной на днях. Сейчас всё работает хорошо, и я наконец-то урвал время, чтобы ответить на вопросы наших читателей

Дамп Маркелла

Давным-давно я предложил читателям скидывать мне на почту крэшдампы их систем, записанные при падении ОС в "синий экран смерти". По сей день мне приходит множество писем с минидампами. Иногда это полновесные дампы по 64-96 Кб, сопровождающиеся детальным описанием проблемы, а иногда - жалкие обрывки файлов, "недодампы", да ещё и без малейшего указания на то, после каких действий произошла ошибка. Вытащить из таких обрывков указание на причину сбоя очень сложно. Зачастую это за пределами моих возможностей. Но тем не менее, получив новую порцию дампов, я с проклятиями запускаю WinDbg, завариваю крепкого чая и принимаюсь за анализ
За этот год, что существует наш сайт, мне пришлось перелопатить немало дампов (сложно назвать общее количество - я удаляю их после анализа). И среди наших читателей есть и те, кому я смог помочь в решении их проблемы, и те, кто так и не дождался от меня ответа. Я рад за первых и прошу прощения у вторых, но у меня всего две руки, один мозг и только 24 часа в сутках - не успеваю...

Мой друг Маркелл прислал мне очередной крэшдамп. Хотя Маркелл не до конца разделяет мою точку зрения на некоторые вопросы, но он любит хардкорно поэкспериментировать со своей системой, зачастую доводя дело до переустановки Windows. В этот раз он пожаловался на то, что только что установленная система стала выдавать синие экраны. Разумеется, я спросил его об установленном софте (особенно меня интересовали антивирус и файрволл) и о том, когда происходит ошибка. Как оказалось, система падает в совершенно произвольный момент, независимо от происходящего, а софта в системе установлено весьма порядочно - как на любой другой домашней геймерской машине
Вообще, если падения системы не связаны с действиями пользователя (асинхронные сбои), то причин у них может быть всего две:

  1. Работа с сетью
  2. Аппаратные сбои

Учитывая наличие на компьютере Kaspersky Internet Security, было бы разумно сходу предложить первую версию, но Маркелл отверг её, мотивировав это тем, что давно пользуется этим файрволлом и не замечал ранее сбоев. Пришлось засучить рукава и лезть в недра дампа (кстати, не знаю, чем это объяснить, но WinDbg согласился читать этот дамп только из корня диска C:, выдавая ошибку при любом другом расположении файла)

Вот, что сказал WinDbg при первом взгляде на крэшдамп Маркелла:

BugCheck 100000D1, {93274fe4, 2, 1, 860d562c}

Unable to load image tcpip.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for tcpip.sys
*** ERROR: Module load completed but symbols could not be loaded for tcpip.sys
Unable to load image TDI.SYS, Win32 error 2
*** WARNING: Unable to verify timestamp for TDI.SYS
*** ERROR: Module load completed but symbols could not be loaded for TDI.SYS
Probably caused by : TDI.SYS ( TDI+3e4 )
Warnings и Errors в данном случае связаны с тем, что у меня нет полного комплекта символьных файлов для WinXP SP2, которая стоит на компе Маркелла. А драйвер TDI.sys отладчик счёл причиной сбоя
TDI.sys - один из низкоуровневых сетевых драйверов WinNT. Учитывая асинхронность сбоя, было бы логично предположить, что TDI.sys повреждён, к примеру, вирусом, потому выдаёт ошибку. Логика в этом есть, но! - обвинять в системных сбоях стандартные драйверы от MicroSoft нужно в последнюю очередь. Сперва нужно предположить, что какой-то "левый" драйвер вторгся в область памяти, принадлежащую TDI.sys (что нетрудно, потому что все ядерные компоненты исполняются в одном адресном пространстве) и затёр критические структуры данных. Но как же найти настоящего преступника?

Были вызваны окна Assembly и Call Stack, а в окно Command вбито две команды: !analyze -v и lmtn. Как выяснилось, сбой с кодом DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) произошёл при попытке записи в память по адресу 93274fe4 4-х байт командой mov [eax+0x14],edx, расположенной по адресу 860d562c
Адрес 860d562c принадлежит... А никому он не принадлежит! Судя по списку загруженных модулей ядра, в эту область памяти не спроецирован ни один модуль. Так что, в целях понимания ситуации, надо бы восстановить ход событий путём обратной трассировки стека. Слегка удручает "WARNING: Frame IP not in any known module. Following frames may be wrong", но мы это переживём. Стек выглядит так:

 # ChildEBP RetAddr  Args to Child
00 f78d2b74 804f15b6 00000000 91464f68 f78d2bd8 0x860d562c
01 f78d2ba4 806567b8 91464f68 8eca8fd8 c0000120 nt!MmProbeAndLockPages+0x1d4
02 f78d2c10 eda68ad2 85e22c18 8605e008 806583d0 nt!VfScatterGatherCallback+0xfc
03 f78d2c28 eda7fa8a 91464f68 c0000241 00000000 tcpip+0x4ad2
04 f78d2c54 eda6ece8 0405e008 00000002 8605e00c tcpip+0x1ba8a
05 f78d2c70 eda6c260 8605e008 00000002 00000040 tcpip+0xace8
06 f78d2c94 eda64a08 00000002 00000002 f78d2cc0 tcpip+0x8260
07 f78d2cc8 eda6494f 00000002 eda64900 eda643d6 tcpip+0xa08
08 f78d2d60 f771f3e4 edaa5180 8c1d4f40 edaa5190 tcpip+0x94f
09 f78d2d7c 805379bd 8c1d4f40 00000000 863c3b30 TDI+0x3e4
Для тех, кто не въехал в сакральный смысл вышеизложенного, поясню: от 09 до 00 - это цепочка вызовов функций, одна функция вызывает другую. И, как видим, предпоследний адрес возврата - f771f3e4 - ведёт к той самой TDI+3e4, т.е. функции, расположенной на 3e4h байт от Image Base драйвера TDI.sys; адрес возврата из TDI+3e4 лежит в окрестностях ntoskrnl.exe, который довольно глупо обвинять в причине сбоя

Итак, самым крайним оказался адрес f771f3e4. И он действительно принадлежит драйверу TDI.sys. Именно с него начинается цепочка вызовов сетевых функций из tcpip.sys, которая в конце и приводит к сбою. Казалось бы, всё ясно... Отнюдь! Даже сейчас остаётся целых три версии произошедшего:

  1. Непосредственное повреждение файла C:\Windows\system32\drivers\tdi.sys - тогда достаточно заменить файл
  2. Если предположить, что область памяти, принадлежащая TDI.sys, была повреждена извне, то на роль виновника идеально подходит Kaspersky Internet Security, тем более, что в списке модулей ядра засветился эмулятор локальной сети Hamachi (драйвер hamachi.sys), а их конфликт - весьма возможная штука
  3. Если предположить повреждение стекового фрейма и искажение адресов возврата, то виновником может оказаться расположенный в области f7717000-f771f000 некто sfhlp02.sys - имя выдаёт его с головой. Это один из драйверов Star Force, и довольно странно видеть его без многочисленных собратьев - драйверов с именами sfhlp**.sys и prodrv**.sys. Эта ситуация носит название "недобитый Star Force" и вполне может служить причиной асинхронных сбоев

    Как видите, анализ малых крэшдампов, хотя и проясняет ситуацию, всё же оставляет кучу вопросов. Поэтому не ждите от этого метода 100%-й диагностики причины сбоя - он может только очертить круг подозреваемых, искать придётся самим

    По поводу "украшательств"

    Моя статья "Украшаем WinXP ч.1", видимо, очень понравилась читателям. По крайней мере, писем с вопросами по этой статье я получил довольно много. Большинство из них касались создания панелей. Отвечу всем сразу: да, при ручном перезапуске процесса Explorer.exe панели, расположенные по бокам экрана, исчезают. Поэтому приходится создавать их вверху и внизу

    Но особенно порадовал меня наш читатель yostefoniks. Он нашёл меня в IM-клиенте Mail.Ru Agent по нику "Вазелиновый пень" (да, именно под таким ником я пишу на www.udaff.com) и задал свои вопросы. Вместе нам удалось решить ряд неточностей в моей статье
    По словам yostefoniks'а выходило, что некоторые папки на его компьютере не хотят менять свой внутренний фон, хотя файл destop.ini создан именно так, как я указывал в своей статье, и наделён атрибутами "скрытый" и "системный". К своему удивлению, я обнаружил и на своей машине несколько таких "непослушных" папок. Причём, если на папку ставился атрибут "системный" - фон менялся. Это меня слегка озадачило, но ровно за 28 минут я нашёл ответ на этот вопрос: на папке должен стоять атрибут "только для чтения" (attrib папка +r в консоли). По большому счёту, разницы между атрибутами "системный" (+s) и "только для чтения"(+r) - почти никакой, но что-то не нравится мне, например, давать папке с порнухой системный атрибут:)

    Попутно выяснилось, что на Win2k этот фокус не работает. Там нужно дописывать в desktop.ini следующее:

    [.ShellClassInfo]
iconfile=
iconindex=
infotip=
confirmfileop=0

[{BE098140-A513-11D0-A3A4-00C04FD706EC}]
iconarea_image=
IconArea_Image=
IconArea_Text=
iconarea_textbackground=
[ExtShellFolderViews]
{BE098140-A513-11D0-A3A4-00C04FD706EC}={BE098140-A513-11D0-A3A4-00C04FD706EC}
[{BE098140-A513-11D0-A3A4-00C04FD706EC}]
{5984FFE0-28D4-11CF-AE66-08002B2E1262}={5984FFE0-28D4-11CF-AE66-08002B2E1262}
    Кстати, насчёт infotip: эта фича по умолчанию отсутствует у файлов desktop.ini в WinXP, но никто не мешает добавить её вручную и сортировать папки в окне Проводника не по имени или времени создания, а по infotip'у

    Спасибо yostefoniks'у от всей команды! И огромное спасибо всем, кто читает нас!
    До новых встреч!

    P.S.

    Уважаемые читатели! Нам очень важно каждое ваше письмо, и мы с большим интересом вникаем в ваши проблемы, но иногда нам присылают такое, что хочется застрелиться. ПОЖАЛУЙСТА, не присылайте нам многомегабайтные фотографии синих экранов - вполне достаточно и вольного пересказа написанного на них текста. И сопровождайте, пожалуйста, свои дампы хотя бы небольшим описанием проблемы: у нашей команды, конечно, есть магический шар, который читает мысли на расстоянии, но мы регулярно сдаём его в химчистку, а гадать на кофейной гуще ещё не научились:)
    И перед тем, как костерить Билла Гейтса и слать письма нам, убедитесь, что с аппаратной частью вашего компьютера всё в порядке. Довольно неприятно, когда читатель жалуется по аське на регулярно появляющиеся сообщения об ошибке "Бла-бла-бла, память не может быть Read", мы выдаём на-гора кучу вариантов, сообщаем их читателю, ни один не проходит - а в конце оказывается, что всё дело было в остановившемся кулере на CPU или повреждённом кабеле дополнительного питания видеокарты (реальный случай). Некоторые вопросы подробно разобраны в нашем FAQ'е - не стоит им пренебрегать
Главная страница Windows Delphi Assembler .NET Delphi Reversing Шаолинь Other Форум Monah'а

Создатель команды, главный редактор, художник и web-мастер: Adrax

Дизайн сайта: WargaL

Ответственный за форум: Monah

RussianFuckersTeam©