Попереджаємо, що будь-які експерименти з драйверами небезпечні і можуть вивести з ладу систему. Краще заздалегідь зробити бекап системи і потім не схрещувати пальці, видаляючи з вінди черговий підозрілий драйвер.
І як тільки не лають Windows від Microsoft. називаючи бідолаху одночасно і гальмівний, і глючной і навіть нестабільною. Тільки ось відмовлятися від неї ніхто не поспішає, та й взагалі навряд чи вже коли-небудь відмовиться. Тому, замість того щоб лаяти бідних розробників і розводити безглуздий флейм, добре б розібратися: а чому, власне, система глючить? Відкрию тобі невеликий секрет. У горезвісних екранах смерті і нестабільної роботи Windows в переважній більшості випадків винні драйвери сторонніх виробників, а сама операційка тут абсолютно ні при чому. Зараз ми розповімо, як такі драйвери виявити і з системи видалити.
Дефекти проектування драйверів можуть носити самий різний характер: від випадінь в блакитний екран смерті (BSOD - Blue Screen of Death) і до уповільнення роботи комп'ютера і дивацтв поведінки деяких зовсім не пов'язаних з драйвером прикладних програм.
Блакитний екран смерті чудовий (без жодної іронії!) Тим, що явно сигналізує про наявність серйозної проблеми і дає наводку, звідки рити. Найчастіше (але далеко не завжди) ім'я «провинився» драйвера висвічується безпосередньо в правому верхньому кутку блакитного екрану смерті. Однак там його може і не бути або, що ще гірше, там може стояти ім'я зовсім сторонньої драйвера.
Крім дефектів драйверів, блакитні екрани смерті можуть також викликатися відмовами заліза, наприклад розігнаним процесором, несправною оперативною пам'яттю, кривим контролером жорсткого диска, не до кінця увіткненою в слот PCI-картою, неконтакт в одному з роз'ємів, поганим блоком живлення, роздутим електролітичним конденсатором на материнської плати. А дуються останні з різних причин: через перегрів від поруч розташованого процесора, нестачі керамічних конденсаторів, «недоложенних» виробником (в результаті чого ВЧ-складова йде через електроліт і сильно його розігріває), нарешті, через витік ключових транзисторів в вузлі стабілізатора. Тому, перш ніж колоти дрова, необхідно переконатися, що залізо, на якому ми сидимо, повністю справно. А як це можна зробити?
Розборки з залізом
Щоб зняти з заліза всі підозри, досить підключити до системи ще один жорсткий диск, встановити на нього невинно чисту Windows і попрацювати на ній деякий час. Якщо блакитні екрани смерті не зникнуть, значить, дійсно, винувато залізо і його прийшла пора міняти. Пошук дефективних компонентів - тема для окремої розмови, який ми залишимо на наступний раз, а поки, засукавши рукава, впритул візьмемося за ці підступні драйвери.
Дрова без сертифіката відразу в топку
Весь комплект інструментарію, необхідний для розробки драйверів (DDK - Driver Development Kit), Microsoft поширює безкоштовно разом з супутньою йому документацією. Драйверів, часом дуже глючних і нестабільних.
Щоб такого свавілля не відбувалося, Microsoft ще в стародавні часи ввела процедуру сертифікації драйверів на відповідність пропонованим до них вимогам, після якої драйверу видається цифровий підпис. Або ... не видається, і він вирушав на доопрацювання. І хоча сертифікація - всього лише формальна процедура, що не гарантує відсутність фатальних помилок і дефектів розробки, частина відверто «піонерських» драйверів вона все-таки відсіває.
В ідеалі, в системі слід тримати тільки драйвери, завірені цифровим підписом. І хоча цифровий підпис не страховий поліс, її наявність вже вказує на певний рівень культури розробки. Драйвери без цифрового підпису - це гірше, ніж кіт з кішкою в мішку, і від них по можливості слід позбавлятися (тим більше що багато хто з них є шкідливими програмами, що встановлюються rootkit'амі або агресивними захисними механізмами, глибоко проникаючими в систему і викликають її нестабільність ). Коротше, не буде розводити демагогії, а спробуємо відповісти на одне просте запитання: як скласти список драйверів без цифрового підпису?
У цьому нам допоможе утиліта sigverif.exe. що входить в штатний комплект поставки операційної системи і розташовується в каталозі WINNT \ System32. Запускаємо її і бачимо діалогове вікно. Натискаємо кнопку «Додатково» і у вкладці «Пошук» налаштовуємо критерії відбору, переміщаючи радіокнопку з положення «Повідомляти про непідписані системних файлах» (де вона і животіла за замовчуванням) в положення «Пошук інших файли, які не підписані цифровим підписом». Після цього в «Параметрах пошуку» відкриваємо бокс «Шукати файли наступного типу» і вибираємо «* .sys», а нижче вказуємо папку для пошуку «C: \ WINNT», обов'язково зазначивши галочку «Включаючи підпапки».
Взагалі-то, строго кажучи, драйвери не зобов'язані мати розширення sys і далеко не завжди обмежуються каталогом WINNT, перебуваючи в каталогах «своїх» додатків, а деякі додатки і зовсім зберігають драйвери ... всередині себе! Відразу ж після запуску (або в будь-який інший час) вони зберігають файл на диск в поточну або тимчасову директорію, завантажують драйвер в пам'ять і ... тут же видаляють його з диска! Так надходять не тільки шкідливі віруси, але і цілком респектабельні програми, на кшталт деяких утиліт відомого дослідника надр Windows Марка Руссиновича.
Якщо хоча б один з цих драйверів відсутня в каталозі C: \ WINNT \, то його цифровий підпис перевірена не буде! Природно, такий драйвер відразу ж привертає до себе увагу, і у нас з'являється резонне питання: звідки він береться? Спочатку скануємо всі каталоги на диску; якщо його там немає, встановлюємо точку зупину на функцію CreateFileW в Soft-Ice і дивимося на передані їй аргументи. Рано чи пізно ми зустрінемо наш глючний драйвер, після чого залишиться тільки поглянути в правий нижній кут екрану Soft-Ice, де висвічується ім'я процесу, який породив його. Більш детально - у книзі «Техніка налагодження програм без вихідних текстів», електронну копію якої можна знайти на ftp- або http-сервері. а також на нашому диску. А ми продовжуємо мучити утиліту sigverif.exe.
Після натискання на «ОК», «Пуск» на екрані з'явиться «градусник», що відображає хід прогресу, і жорсткий диск почне шарудіти усіма своїми головками, які у нього тільки є. По завершенні роботи буде складено і виведений на екран список драйверів без цифрового підпису.
Деякі гарячі голови пропонують, в порядку очищення системи від єресі, видалити всі непідписані драйвери - тоді, мовляв, всі проблеми як хвостом зніме. А як це можна зробити? Саме грубе рішення - просто взяти і видалити їх з диска через FAR або провідник (природно, володіючи правами адміністратора!). Але наслідки такої операції можуть виявитися вельми плачевними, і краще, клікнувши правою клавішею миші на іконку драйвера в провіднику, знайти в «Властивості» ім'я виробника, за яким можна визначити, що за додаток / залізяка встановила цей драйвер, і деінсталювати її цивілізованим шляхом. Правда, тут є одне «але».
На наведеному малюнку виділено драйвер g400m.sys. що йде разом з картою Matrox G450, і хоча Matrox зовсім не квола компанія, цифровий підпис вона не отримала (чи то Microsoft не дала, то чи сама Matrox не захотіла морочитися). Природно, після видалення його із системи, про SVGA-режимі доведеться забути. Можна, правда, сходити на сайт Matrox, скачавши найновіший драйвер (вона вже забезпечена цифровим підписом). Тільки ось ... і підписана, і непідписана версії містять безліч фатальних помилок, зокрема, в результаті збігу певних обставин при спробі перейти в overlay mode, система падає в BSOD, оскільки драйвер намагається звільнити вже звільнену пам'ять.
Таким чином, наявність / відсутність цифрового підпису саме по собі ще ні про що не говорить, і, навіть якщо ми використовуємо тільки підписані драйвери, ніяких гарантій стабільності це нам не дає.
Ось тут-то ми і переходимо до другої частини статті, а саме до тестування драйверів в умовах, наближених до бойових.
Влаштовуємо дров справжнє випробування
До складу DDK входить чудова утиліта DriverVerifier. створює для драйверів максимально суворі умови, які межують з екстримом і суїцидом, в яких імовірність відмови максимальна, а ім'я дефектного драйвера визначається з найвищою точністю (навіть якщо він через дефекти розробки страждає не сам, а руйнує структуру даних чужих драйверів).
Важливо відзначити, що DriverVerifier - це не ліки, а тільки засіб діагностики. Від збоїв воно все одно не врятує (навпроти, збільшить їх інтенсивність на пару порядків), але зате допоможе виявити «підлий» драйвер з достатнім ступенем вірогідності.
Отже, запускаємо verifier.exe, бачимо вікно DriverVerifierManager. йдемо в закладку Setting і переводимо радіокнопку в положення Verify all drivers, після чого тиснемо кнопку «Preferred Setting», яка встановлює наступні типи перевірок (verification type):
- Specialpool - перевіряється драйверам буде відведена спеціальна область пам'яті для виділення, не дуже швидко працює, зате здатна виявляти більшість типів руйнувань своїх і чужих даних.
- ForceIRQL checking. IRQL - це рівень запиту переривань (Interrupt Request Level). Найбільш частою помилкою розробників драйверів є спроба звернутися до пам'яті на такому рівні IRQL, на якому менеджер підкачки не працює. І якщо потрібна сторінка раптом виявиться витісненої на диск, система обернеться в блакитний екран з написом «IRQL_LESS_OR_EQULAR». Форсування цього режиму примусово витісняє сторінки драйвера на диск, щоб дефект розробки проявлявся в 100% випадків.
- Lowresourcesimulation корисно встановити, щоб подивитися, як драйвер буде вести себе при катастрофічній нестачі системних ресурсів, однак цього можна і не робити, а ось галочку Pool tracking (відстеження коректності поводження з пулом пам'яті) краще залишити. Помилки введення / виведення (I / O verification) складають незначну частину всіх помилок, тому положення цієї галки в общем-то абсолютно некритично.
Покінчивши з вибором налаштувань, натискаємо кнопку «Apply» (застосувати) і, як нам і пропонують, перезавантажується.
Відразу ж після початку завантаження робота системи відчутно сповільнитися, що так і повинно бути, оскільки ядро виконує набагато більше перевірок, ніж зазвичай. При виявленні помилок спалахує блакитний екран смерті з ім'ям драйвера і деякою іншою інформацією, корисною для розробників, але марною для нас. Все, що ми можемо зробити, - це оновити драйвер до самої останньої версії або відмовитися від використання програми (залізяки), задействующей його. Взагалі-то, у нас є трохи більше можливостей з розпалення сирих дров, але про це трохи пізніше.
Дізнатися статус перевірки можна в будь-який момент запуском verifier.exe. У закладці Driver Status перераховані статуси всіх виявлених драйверів з поясненням поточної ситуації. Статус Loaded означає, що даний драйвер був завантажений і перевірений, по крайней мере, один раз (але, можливо, не повністю, тобто не всі ділянки драйвера встигли відпрацювати). Статус Unloaded готує про те, що драйвер був завантажений, перевірений (можливо, частково) і вивантажено використовує його системою / програмою або за своїм власним бажанням. Останнє особливо характерно для драйверів, що залишилися від обладнання, яке було видалено шляхом варварського висмикуючи плати розширення з слота, тобто без виконання деінсталяції. Що залишився в живих драйвер сканує шину, намагаючись намацати «своє» обладнання, обламується з пошуком, після чого вивантажує себе з пам'яті, до речі кажучи, сповільнюючи завантаження системи (іноді дуже значно) і конфліктуючи з іншими драйверами. Мораль: обладнання з системи потрібно видаляти за всіма правилами! Однак не всякий статус Unloaded ознака ненормальності ситуації, і, перш ніж видаляти драйвер з таким статусом, потрібно розібратися, що це за північний олень такий і звідки він взагалі тут узявся.
Статус Never Loaded вказує на те, що даний драйвер ще не був завантажений, а значить, не був і перевірений, отже, треба почекати, запускаючи різні програми, які можуть бути з ним пов'язані. Втім, деякі драйвери (особливо некоректно Деінсталювати) не завантажуються і, відповідно, не перевіряються ніколи.
Попрацювавши з системою в режимі жорсткої перевірки деякий час (від декількох годин до декількох днів), ми виявимо практично всі дефектні драйвери, від яких страждали раніше, і запишемо їх імена на папірець.
Повернути систему в нормальний режим (тобто без додаткових перевірок, зжирає продуктивність), можна за допомогою все того ж verifier'а. Повертаємося до закладки Setting, переводимо радіокнопку в положення Verify selected drivers (при цьому ніякої драйвер не повинен бути виділений), тиснемо на «Reset All», потім на «Apply» і перезавантажуємося. Усе! Тепер система працює з нормальною швидкістю, але без перевірок.
Що робити з сирими дровами?
А дійсно, що можна зробити з дефектним драйвером? Хакери, які вміють тримати відладчик в руках, при наявності достатньої кількості вільного часу, можуть його аналізувати код (благо за обсягом драйвери зазвичай невеликі), знайти помилку, і придумати спосіб її виправлення, але ... це занадто трудомісткий шлях.
Зате далеко не кожен знає, що величезна кількість збоїв і блакитних екранів смерті пов'язано з тим, що драйвер, розроблений (і протестований) в однопроцессорной середовищі, ставлять на двухпроцессорную машину. Під «двопроцесорним» тут мається на увазі як реальна платформа з двома каменями, так і Hyper-Threading / багатоядерні процесори. Відомо (і підтверджено великою кількістю тестів), що домашнього комп'ютера два процесора абсолютно ні до чого, тому що на переважній більшості додатків збільшення продуктивності при цьому практично не спостерігається.
Приклад типового файлу boot.ini
Налаштовуємо систему на використання тільки одного процесора з усіх наявних
А ось на WindowsVista файлу boot.ini немає, і, хоча існує (тимчасова) можливість конфігурувати її завантажувальні настройки за допомогою спеціальної утиліти, Microsoft планує повністю відмовитися від цієї лазівки, так що залишиться тільки BIOS Setup. Втім, що стосується Vista. то до моменту переходу на неї розробники драйверів, напевно, обзаведуться багатопроцесорними машинами (оскільки інших просто не залишиться в продажу) та тестуватимуть свої творіння в многопроцессорном оточенні.
-
Статті відносяться до даної теми: