Раздел: Документация
0 ... 78 79 80 81 82 83 84 ... 102 Типичная реакция домашнего пользователя на нестабильность работы своей а1ннны — полная переустановка всей операционной системы. Иногда ото помогает, иногда нет, но, как бы там ни было, переустановка операционной системы — достаточно «занимательное» событие, самое малое на целый день выводящее вас из игры (в смысле текущей работы). Квалифицированный хакер оттичается от неквалифицированного тем, что со всеми проблемами справляется налету, до минимума сводя время простоя вычислительной техники. Вообше-то хорошо отлаженная система, базирующаяся на ОС типа FreeBSD (или подобных ей), способна без сбоев работать годами, не требуя к себе совершенно никакого внимания. Системы, построенные на базе Windows NT, этим, увы, похвастаться не могут, и для достижения сколько-нибудь стабильной работы за ними приходится постоянно «ухаживать». Аппаратное обеспечение, собираемое на коленках в ближайшем подвале, прямо скажем, не очень надежно, а отличить качественную подделку от оригинала по внешним признакам достаточно трудно. На просторах России свободно продаются отбракованные чипы, левым путем добытые у производителей и выдаваемые за настоящие. Кстати, многие из именитых производителей грешат передачей своих торговых марок третьим фирмам, выпускающим посредственное оборудование, но продающим его по «брэндовым» ценам. Яркий тому пример — пишущий привод ТЕАС 552Е, к которому фирма ТЕАС просто не имеет никакого отношения. Про материнские платы и модули памяти и говорить не стоит. Их клепают все кому не лень, и многие модели вообще не работают, кое-как запускаясь на пониженных таймингах и частотах. Словом, если сбой старушки БЭСМ-6 был настоящим ЧП, то зависание современного компьютера — вполне обычное дело, воспринимаемое нами, как неизбежное зло. Это приложение не убережет вас ни от критических ошибок приложений, ни от отказа оборудования, по, по крайней мере, научит быстро и безошибочно находить их источник. Речь пойдет преимущественно о Windows NT и производных от нее системах (Windows 2000, Windows ХР), хотя поклонники UNIX также найдут здесь немало интересного. АППАРАТНАЯ ЧАСТЬ °т два основных аппаратных виновника нестабильной работы системы — опе-Ратштая память и блок питания. Рассмотрим их поподробнее, отмечая особенности взаим°Действия с памятью в современных чипсетах, таких как 1п- 857Р и подобных ему. ссная связь между программным и аппаратным обеспечением затрудняет де-Ние материала приложения на две равные части, поскольку ряд сбоев систе- Ь1 (и пресловутых «голубых экранов смерти» в том числе) вызван отнюдь не оритмическими ошибками, а неисправностью железа. Но на начальном эта-аНализа голубого экрана смерти (далее по тексту просто голубого экрана) 1 Не можем надежно установить его источник и, чтобы не описывать одни 252 Приложение А. Практические советы по восстановлению системы в боевых услови и те же методики дважды, условимся относить все критические ошибки систе мы к программной среде. В действительности же это не вызывает никакого про тиворечия, поскольку с аппаратными ошибками приходится бороться п цр0 граммными средствами (помните известное: «Как нематериальная дун,, возвращается в тело в результате материальных действий врача»?). ОПЕРАТИВНАЯ ПАМЯТЬ Оперативная намять относится к одному из наименее надежных компонентов вычислительной системы, и потому львиная доля всех сбоев приходится именно на нее. Проявления их могут быть самыми разнообразными: от критических ошибок приложений до периодических или непериодических ошибок чтения (записи) на жесткий диск или даже каскадных ошибок приема/ передачи ТСР/ТР-пакетов (что не покажется удивительным, если вспомнить о котирующей природе всех драйверов, обслуживающих устройства ввода/ вывода). Любой аппаратный ресурс, требующий для своей работы некоторого количества оперативной памяти, так или иначе зависим от работоспособности последней. Существует мнение, что намять «с четностью» полностью решает проблему своей надежности п сводит риск разрушения данных к разумному минимуму. На самом деле это не так. Память с четностью распознает лишь одиночные ошибки и не гарантирует обнаружение групповых. Память тина ЕСС ( Error Check & Correction/Error Correction Code — контроль и исправление ошибок) способна автоматически исправлять любые одиночные ошибки и обнаруживать любые двойные. До тех нор, пока оперативная намять функционирует более или менее нормально, противостояние энтропии и помехозащитных кодов решается в пользу последних. Однако при полном или частичном выходе одного или нескольких модулей памяти из строя корректирующих способностей контролирующих кодов перестает хватать, и система начинает работать крайне нестабильно. Концепция виртуальной памяти, реализованная в операционных системах семейства Windows и UNIX, рассматривает основную оперативную намять как своеобразный кэш. Л это значит, что одни и те же логические страницы адресного пространства в разное время могут отображаться на различные физические адреса. Разрушение одной-единственнон физической ячейки памяти за трагивает множество виртуальных ячеек, и потому сбои памяти нрактическ всегда проявляются «коллективными» критическими ошибками приложении, рассредоточенными в широком диапазоне виртуальных адресов. Если же кри тические ошибки возникают лишь в некоторых процессах и располагаются более или менее постоянным адресам — с высокой степенью вероятности м°* но предположить, что это программная, а не аппаратная ошибка. Исключе составляет неоткачиваемая область памяти (non-paged pool), занятая я \ системы и всегда размещающаяся по одним и тем же физическим адресам, личие дефектных ячеек в данной области обычно приводит к голубому зкрт смерти и/или полному зависанию системы, хотя в некоторых случаях оши драйверов передаются на прикладной уровень и роняют один или несколько процесс01*- Самое интересное, что при прогоне нестабильно работающих драйверов/процессов под отладчиком ошибка волшебным образом может исчезать. В действительности ничего загадочного тут нет. За счет многократного снижения интенсивности доступа к памяти отладчик позволяет «вытянуть» даже дефектные ячейки, затрудняя их локализацию. Некоторые руководства рекомендуют исследовать дамп, сброшенный системой при возникновении критической ошибки в ядре, наивно полагая, что искаженные ячейки будут выглядеть как бессмысленный мусор, сразу бросающийся в глаза даже при минимальных навыках дезассемблирования. При разрушении большого количества ячеек памяти, затрагивающих исполняемый код, это действительно так. Однако искажение областей данных предложенный алгоритм выявить не в состоянии. Только опытный разработчик драйверов заподозрит, что здесь что-то не так. А ведь в некоторых случаях неисправный модуль содержит всего лишь один-единственный дефектный бит информации, который при визуальном осмотре дампа вообще нереально обнаружить. К тому же не стоит забывать, что «замусоривание» памяти может быть вызвано не только аппаратными, но и программными ошибками (например, программист забыл проиннциализировать буферы или направил указатели в «космос», передав управление по произвольному адресу памяти). Худший случай — это разрушение буферов ввода/вывода, зачастую приводящее к полному краху файловой системы без какой-либо надежды на ее восстановление. По непонятной причине разработчики дисковых драйверов отказались от подсчета контрольной суммы пересылаемых через них блоков данных, что сделало файловую систему чрезвычайно уязвимой. Причем NTFS отказывается даже в худшей ситуации, чем FAT32, поскольку FAT32 требует значительно меньшего объема буферной памяти для своей поддержки и к тому же значительно легче поддается «ручному» восстановлению. Автор использует отказоустойчивые буферы, построенные на основе демонстрационных драйверов, входящих в состав DDK и дополненные специальными средствами кон-тР°ля. Главное ноу-хау данной технологии состоит в том, что обмен с диском Ждется на «сыром» (RAW MODE) уровне, то есть, помимо области пользовательских данных, в сектор входит контрольная сумма, но которой драйвер с од-н°и и привод с другой стороны контролируют целостность данных. В жизни автора эта технология срабатывала дважды (в смысле выявляла дефектный Модуль памяти, пытавшийся разрушить жесткий диск), так что усилия, затратные на разработку драйверов, окупили себя сполна! стати, тестирование оперативной памяти путем прогона специальных про-6Ы lM neck PC Diagnostic и им подобных) — не самый лучший путь для вдения ее работоспособности. В силу физической неоднородности подсис-Л10£Ь Намяти Дефективность бракованных модулей зачастую проявляется не на -1е °И а "а стРого определенной последовательности запросов и при онреде-„ °м сочетании содержимого разрушенной и окрестных ячеек. Тестирующие гРаммы перебирают ограниченное количество наиболее типичных шабло- 0 ... 78 79 80 81 82 83 84 ... 102
|