Залізо

Windows 7 як визначити косячний драйвер. Як виявити проблемні драйвера за допомогою Driver Verifier. Додаткові відомості для розробників драйверів

Отже, у вас є повторюваний синій екран смерті, і, як і багато BSoD, це тому, що поганий драйвер винен. Проте, екран не дає вам правильну інформацію, або тому, що він взагалі не містить жодного драйвера, або тому, що він перераховує системний драйвер, який діє як помилковий.

Driver Verifier - безкоштовна утиліта, яка включена в усі версії Windows з Windows XP. Він буквально перевіряє кожен з драйверів на вашому ПК до тих пір, поки він не зіткнеться з проблемою, що викликала проблему, навмисно створивши той же синій екран, але потім записуючи інформацію в файл журналу, допомагаючи вам виявити проблему.

Запустити драйвер драйверів

Якщо ви часто користуєтеся одним і тим же синім екраном, і ви хотіли б стати активним і виправити його, ось як використовувати Driver Verifier.

  1. Натисніть кнопку Пуск
  2. натисніть « Виконати »...
  3. Введіть CMD і натисніть Enter.
  4. У новому вікні введіть верифікатор і натисніть Enter.


У Windows Vista і 7:

  1. Натисніть кнопку Пуск
  2. Введіть CMD в поле і натисніть Enter.
  3. У новому вікні введіть верифікатор і натисніть Enter.


У Windows 8 і 8.1:

  1. натисніть Windows + X
  2. натисніть « Командний рядок »(« Адміністратор ») (Windows PowerShell (Admin) в Windows 8.1)
  3. У новому вікні введіть верифікатор і натисніть Enter.


Всі версії Windows:

  1. Переконайтеся, що обрана настройка призначених для користувача налаштувань (для розробників коду) .
  2. натисніть « далі » .
  3. Виберіть " Вибрати індивідуальні настройки »з повного списку .
  4. натисніть « далі » .
  5. скасуйте вибір системного моделювання з низьким ресурсом і запити на введення-виведення в режим очікування . (Ці два завдають непотрібну робоче навантаження на вашому ПК.) Переконайтеся, що вибрано все інше.
  6. Двічі натисніть « далі » .
  7. Виберіть " Вибрати імена драйверів »в списку .
  8. натисніть « далі » .
  9. Виберіть всі драйвери на цьому екрані, крім тих, які говорять Microsoft Corporation під Постачальником. Це дуже малоймовірно, що драйвер Microsoft викликає цю проблему.
  10. натисніть « Готово » .


Примітка. Якщо ви не можете виконати вищевказані дії, тому що синій екран продовжує відбуватися, спробуйте спочатку завантажити в.

На цьому етапі ви повинні перезавантажити комп'ютер. Потім спробуйте знову викликати BSoD, виконавши те, що ви робили раніше. Windows додає додаткове навантаження на ваших водіїв, щоб допомогти вам. Якщо ви не можете відтворити BSoD, спробуйте запустити комп'ютер на ніч. Як тільки BSoD з'явиться знову, перезавантажте комп'ютер в і прочитайте файл Minidump.


Читання файлу дампа

Драйвер Verifier буде запускатися, запускати синій екран і записувати файл журналу. Цей файл журналу знаходиться в C: \\ Windows \\ Minidump \\. Прочитайте його, і ви побачите, який драйвер викликає цю проблему. Спробуйте знайти ім'я драйвера, щоб дізнатися, яка частина обладнання на вашому ПК використовує.

Отже, як ви його читаєте? Вам потрібен інструмент налагодження, який ви можете завантажити з Microsoft.

А. Завантажте SDK, встановіть його, виберіть інструменти налагодження і зніміть всього іншого.

Зверніть увагу, що інструменти налагодження для попередніх версій Windows більше недоступні; вам доведеться відправити файл дампа технічного фахівця Microsoft для аналізу.


Після його установки знайдіть його на екрані запуску. Він називається windbg (x64). Запустити його.

  1. натисніть « файл » , Потім « Відкрити збій » .
  2. перейдіть до C: \\ Windows \\ Minidump \\ і відкрийте файл.DMP, що міститься всередині.
  3. Подивіться на нижню частину результуючого файлу, де рядок говорить « Ймовірно, викликана » . Це хороший показник того, який драйвер викликає цю проблему.

виправити драйвер

Оновіть драйвер, пов'язаний з цим апаратним забезпеченням:

  1. Натисніть кнопку Пуск
  2. натисніть Панель управління
  3. натисніть « Переключитися на класичний вид »
  4. двічі клацніть систему
  5. перейдіть на вкладку «Обладнання»
  6. натисніть Диспетчер пристроїв
  7. натисніть « Оновити драйвер ».

У Windows Vista і 7:

  1. Натисніть кнопку Пуск
  2. натисніть Панель управління
  3. двічі клацніть Диспетчер пристроїв
  4. Знайдіть пристрій, що викликає проблему
  5. Клацніть правою кнопкою миші по ньому
  6. натисніть « Оновити драйвер ».


У Windows 8 і 8.1:

  1. натисніть Windows + X
  2. натисніть Панель управління
  3. Перегляд по маленьким піктограм
  4. натисніть Диспетчер пристроїв
  5. Знайдіть пристрій, що викликає проблему
  6. Клацніть правою кнопкою миші по ньому
  7. натисніть « Оновити драйвер ».

Або використовуйте наш додаток, щоб не плутати з Driver Verifier. Driver Reviver автоматично оновлює всі існуючі драйвери на вашому ПК і особливо хороший для поновлення малоефективних драйверів, таких як ця, до останньої і найбільшої версії.

Після виправлення драйвера проблеми ви захочете відключити Driver Verifier.

Відключити верифікатор драйверів

Після того, як ви закінчите використовувати Driver Verifier, ви захочете відключити його, так як це досить важко для вашого ПК під час його роботи.

У всіх версіях Windows:

  1. Повторно запустіть Driver Verifier, використовуючи наведені вище кроки.
  2. Виберіть " Видалити існуючі налаштування » .
  3. натисніть « Готово » .
  4. Перезавантажте комп'ютер знову.


Збережіть цю статтю в закладки в майбутньому, так що всякий раз, коли у вас є синій екран, ви можете виправити проблему. Крім того, ознайомтеся з нашим інтерактивним і введіть ім'я своєї помилки для отримання додаткових рад за рішенням вашого конкретного синього екрану смерті. Успіхів!

8021

Про Однією з найбільш ймовірних причин появи синього екрану смерті є некоректно працюють драйвера. Встановити точну причину збою можна проаналізувавши файл дампа після BSOD, Але так буває не завжди. У деяких випадках визначити джерело проблеми не вдається навіть при самому ретельному аналізі дампов. У таких ситуаціях може допомогти - штатна утиліта Windows, призначена для розширеного тестування драйверів.

Працюючи у фоновому режимі, вона не тільки веде спостереження за роботою драйверів, а й імітує різні «Стресові» ситуації, наприклад, брак оперативної пам'яті. Отримана в ході тестування інформація «Дописується» в файл дампа DMP. Driver Verifier дозволяє аналізувати помилки введення-виведення, контролювати переповнення буфера, виявляти помилки в механізмі IRQL і т.п. Одним словом, програма дозволяє виявити ситуації, при яких драйвер може привести до падіння системи з BSOD.

Специфічність утиліти зовсім не виключає її використання звичайними користувачами. Створити з її допомогою звіт може кожен, зовсім інша справа займатися його розшифровкою. Але цього від простих користувачів ніхто не вимагає, що ж стосується отриманого дампа, то його аналіз можна покласти на плечі професіоналів, звернувшись за допомогою на який-небудь відомий комп'ютерний форум.

Важливе зауваження: перед використанням утиліти настійно рекомендується створити системну точку відновлення або повну резервну копію. У Windows 8 і 8.1 також буде потрібно активувати режим безпечного завантаження. Це необхідно на випадок виникнення непередбачених помилок при роботі Driver Verifier. Так ви зможете завантажитися, відключити режим тестування і виконати відкат системи.

Запустити утиліту можна командою verifier.

У наступному вікні Диспетчера відзначте параметри, за якими буде виконуватися тестування (Для повноти картини можна вибрати все).

У третьому вікні можна нічого не міняти.

У четвертому віконці утиліта запропонує вибрати групу драйверів для тестування.

За замовчуванням вибираються всі непідписані драйвера, як входять до групи ризику, але також ви можете вказати драйвера самостійно, зазначивши їх галочками в п'ятому вікні Диспетчера перевірки.

Це все. Після перезавантаження комп'ютера буде активований режим перевірки драйверів. Весь цей час комп'ютер можна використовувати як зазвичай, аж до моменту появи BSOD. Після цього копіюємо файл дампа з каталогу C: / Windows / Minidump і відправляємо його на аналіз. На завантаження ПК з включеним режимом тестування драйверів може знадобитися трохи більше часу, так що не лякайтеся. Це нормальне явище. Після отримання всіх даних режим налагодження необхідно відключити вручну, вибравши в графічному інтерфейсі утиліти пункт «Видалити існуючі параметри».

Утиліта Driver Verifier (verifier.exe) призначена для аналізу проблемних драйверів, коли аналіз дампов пам'яті після BSOD не дозволяє знайти проблемний драйвер. Driver Verifier - це "паличка виручалочка" в найбільш проблемних ситуаціях.

За допомогою Driver Verifier можна виконувати:

    стрес тест драйвера (імітуються умови нестачі ресурсів);

    контроль переповнення буфера;

    контроль за помилками, що виникають при неправильній роботі при заданому IRQL;

    аналіз помилок введення-виведення;

    детектування ситуацій deadlock і т.д.

Утиліта Driver Verifier буває дуже корисною коли:

    у адміністратора (користувача) є підозри, що саме цей драйвер викликає крах системи і він хоче додатково перевірити чи так це насправді;

    розробники драйвера, хочуть протестувати свій драйвер;

    при аналізі дампа після BSOD знайти проблемний драйвер не можна.

Одним з найскладніших випадків аналізу дампов пам'яті є випадок, коли драйвер помилково перезаписує дані до початку або за кінцем буфера, виділеного їм. У таких випадках, виникають помилки в ядрі ОС (наприклад, аналіз дампа після BSOD показує, що помилка виникла в ntoskrnl.exe).

Давайте подивимося подібний випадок на конкретному прикладі. За допомогою утиліти NotMyfault викликаємо BSOD - "Buffer overflow".

Результат аналізу дампа за допомогою windbg у вкладенні нижче.

Згідно аналізу дампа отримуємо.

1. Arg1: 00000007, Attempt to free pool which was already freed (Була спроба звільнення вже звільненого пулу)

2. IMAGE_NAME: ntkrpamp.exe (Відношення до цього має саме ядро \u200b\u200bсистеми)

Саме при подібних помилках, на допомогу приходить verifier.

Запускаємо verifier.

Вибираємо "Створити не стандартні параметри". Далі вибираємо "Вибрати параметри зі списку".

Вибираємо все крім "Імітація брак ресурсів".

Після чого вибираємо "Вибрати незавантажені драйвери до цього списку" і вказуємо шлях до драйвера myfault.sys, який знаходиться в тому ж каталозі, що і програма NotMyfault.exe.

Після чого відзначаємо драйвер і натискаємо "Готово". Після цього, нам необхідно перевантажити комп'ютер.

Виконуємо всі ті ж дії, що і на початку. Запускаємо NotMyfault.exe, вибираємо "Buffer overflow" і натискаємо "Crash". Як ви помітили крах може відбутися не відразу, оскільки хто і коли буде намагатися працювати з цією пам'яттю невідомо заздалегідь. Як бачимо на зображенні нижче, завдяки verifier система може визначити проблемний драйвер.

Наведу аналіз за допомогою! Analyze -v в windbg.exe дампа пам'яті після BSOD.

Програма verifier робить так, що перевірявся драйвер замість звичайної пам'яті доступної в ядрі використовує спеціальний пул, призначений для визначення подібної помилки. Завдяки цьому, можна знайти драйвер, який призводить до BSOD.

Якщо подивитися результати аналізу то ми бачимо наступне.

1. DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) - це одна з помилок, яка генерується verifier

2. IMAGE_NAME: myfault.sys - драйвер, який привів до проблеми.

Таким чином, якщо аналіз дампа пам'яті після BSOD не дозволяє знайти "винний драйвер" скористайтеся програмою verifier.exe (встановіть всі перевірки, крім браку пам'яті).

Найбільш простим варіантом використання Driver Verifier (verifier.exe) є його запуск з наступними параметрами:

verifier / standard / driver ім'я файлу драйвера

Post Views 1 042

Попереджаємо, що будь-які експерименти з драйверами небезпечні і можуть вивести з ладу систему. Краще заздалегідь зробити бекап системи і потім не схрещувати пальці, видаляючи з вінди черговий підозрілий драйвер.

І як тільки не лають Windows від Microsoft, Називаючи бідолаху одночасно і гальмівний, і глючной і навіть нестабільною. Тільки ось відмовлятися від неї ніхто не поспішає, та й взагалі навряд чи вже коли-небудь відмовиться. Тому, замість того щоб лаяти бідних розробників і розводити безглуздий флейм, добре б розібратися: а чому, власне, система глючить? Відкрию тобі невеликий секрет. У горезвісних екранах смерті і нестабільної роботи Windows в переважній більшості випадків винні драйвери сторонніх виробників, а сама операційка тут абсолютно ні при чому. Зараз ми розповімо, як такі драйвери виявити і з системи видалити.

Дефекти проектування драйверів можуть носити самий різний характер: від випадінь в блакитний екран смерті ( BSOD - Blue Screen of Death) і до уповільнення роботи комп'ютера і дивацтв поведінки деяких зовсім не пов'язаних з драйвером прикладних програм.

Блакитний екран смерті чудовий (без жодної іронії!) Тим, що явно сигналізує про наявність серйозної проблеми і дає наводку, звідки рити. Найчастіше (але далеко не завжди) ім'я «провинився» драйвера висвічується безпосередньо в правому верхньому кутку блакитного екрану смерті. Однак там його може і не бути або, що ще гірше, там може стояти ім'я зовсім сторонньої драйвера.

Так, наприклад, один досить поширений драйвер від відеокарти Matrox G450 має тенденцію руйнувати базові структури графічної підсистеми Windows 2000 , В результаті чого в BSOD'е відображається ім'я системного драйвера win32k.sys, В якому реалізована значна частина функцій USER і GDI і який, природно, тут зовсім ні при чому. Так що інтерпретація свідчень блакитного екраном смерті - це і магія, і інтуїція, і наука, і мистецтво - всього потроху.

Крім дефектів драйверів, блакитні екрани смерті можуть також викликатися відмовами заліза, наприклад розігнаним процесором, несправною оперативною пам'яттю, кривим контролером жорсткого диска, не до кінця увіткненою в слот PCI-картою, неконтакт в одному з роз'ємів, поганим блоком живлення, роздутим електролітичним конденсатором на материнської плати. А дуються останні з різних причин: через перегрів від поруч розташованого процесора, нестачі керамічних конденсаторів, «недоложенних» виробником (в результаті чого ВЧ-складова йде через електроліт і сильно його розігріває), нарешті, через витік ключових транзисторів в вузлі стабілізатора. Тому, перш ніж колоти дрова, необхідно переконатися, що залізо, на якому ми сидимо, повністю справно. А як це можна зробити?

Розборки з залізом

Блакитні екрани смерті, викликані збоями заліза, носять стихійний характер, з'являючись непередбачувано і незалежно ні від яких конкретних дій користувача. Прикладні програми також починають видавати критичні помилки в самих різних місцях, причому коди помилок, адреси та інша інформація, яка видається системою, у всіх випадках будуть різними! До речі кажучи, драйвери, обробні асинхронні запити від пристроїв введення / виводу, наприклад бездротових мереж, поводяться практично точно так же. Блакитні екрани смерті, викликані дефектними драйверами, як правило, виникають при здійсненні певного набору дій і містять більш-менш постійну інформацію.

Щоб зняти з заліза всі підозри, досить підключити до системи ще один жорсткий диск, встановити на нього невинно чисту Windows і попрацювати на ній деякий час. Якщо блакитні екрани смерті не зникнуть, значить, дійсно, винувато залізо і його прийшла пора міняти. Пошук дефективних компонентів - тема для окремої розмови, який ми залишимо на наступний раз, а поки, засукавши рукава, впритул візьмемося за ці підступні драйвери.

Дрова без сертифіката відразу в топку

Весь комплект інструментарію, необхідний для розробки драйверів ( DDK - Driver Development Kit), Microsoft поширює безкоштовно разом з супутньою йому документацією. Драйверів, часом дуже глючних і нестабільних.

Щоб такого свавілля не відбувалося, Microsoft ще в стародавні часи ввела процедуру сертифікації драйверів на відповідність пропонованим до них вимогам, після якої драйверу видається цифровий підпис. Або ... не видається, і він вирушав на доопрацювання. І хоча сертифікація - всього лише формальна процедура, що не гарантує відсутність фатальних помилок і дефектів розробки, частина відверто «піонерських» драйверів вона все-таки відсіває.

В ідеалі, в системі слід тримати тільки драйвери, завірені цифровим підписом. І хоча цифровий підпис не страховий поліс, її наявність вже вказує на певний рівень культури розробки. Драйвери без цифрового підпису - це гірше, ніж кіт з кішкою в мішку, і від них по можливості слід позбавлятися (тим більше що багато хто з них є шкідливими програмами, що встановлюються rootkit'амі або агресивними захисними механізмами, глибоко проникаючими в систему і викликають її нестабільність ). Коротше, не буде розводити демагогії, а спробуємо відповісти на одне просте запитання: як скласти список драйверів без цифрового підпису?

У цьому нам допоможе утиліта sigverif.exe, Що входить в штатний комплект поставки операційної системи і розташовується в каталозі WINNT \\ System32. Запускаємо її і бачимо діалогове вікно. Натискаємо кнопку «Додатково» і у вкладці «Пошук» налаштовуємо критерії відбору, переміщаючи радіокнопку з положення «Повідомляти про непідписані системних файлах» (де вона і животіла за замовчуванням) в положення «Пошук інших файли, які не підписані цифровим підписом». Після цього в «Параметрах пошуку» відкриваємо бокс «Шукати файли наступного типу» і вибираємо «* .sys», а нижче вказуємо папку для пошуку «C: \\ WINNT», обов'язково зазначивши галочку «Включаючи підпапки».

Взагалі-то, строго кажучи, драйвери не зобов'язані мати розширення sys і далеко не завжди обмежуються каталогом WINNT, перебуваючи в каталогах «своїх» додатків, а деякі додатки і зовсім зберігають драйвери ... всередині себе! Відразу ж після запуску (або в будь-який інший час) вони зберігають файл на диск в поточну або тимчасову директорію, завантажують драйвер в пам'ять і ... тут же видаляють його з диска! Так надходять не тільки шкідливі віруси, але і цілком респектабельні програми, на кшталт деяких утиліт відомого дослідника надр Windows Марка Руссиновича.

Тому для чистоти експерименту нам зовсім не завадить отримати список драйверів, що знаходяться в даний момент в пам'яті, і порівняти їх з драйверами, розташованими на диску. Слова «в даний момент» - ключові, оскільки завантаження / розвантаження драйверів може відбуватися безкоштовно без перезавантаження операційної системи. Цю операцію бажано виконати кілька разів, запускаючи утиліту командного рядка drivers.exe, що входить до складу DDK, який можна завантажити з сервера копанні Microsoft. Запущена без будь-яких ключів командою рядка, утиліта drives.exe вивалює всю інформацію на екран, що не є добре, оскільки драйверів в системі зазвичай присутній дуже багато і на екран вони не поміщаються. Однак релігія нам дозволяє перенаправити потік виведення в текстовий файл (drivers.exe\u003e \u200b\u200bfile-name.txt), що відкривається будь-яким текстовим редактором - хоч Word'ом, хоч блокнотом. Потім залишається тільки виділити вертикальний блок (чого блокнот не дозволяє) і отримати список драйверів. Прямо з ядра операційної системи!

Якщо хоча б один з цих драйверів відсутня в каталозі C: \u200b\u200b\\ WINNT \\, то його цифровий підпис перевірена не буде! Природно, такий драйвер відразу ж привертає до себе увагу, і у нас з'являється резонне питання: звідки він береться? Спочатку скануємо всі каталоги на диску; якщо його там немає, встановлюємо точку зупину на функцію CreateFileW в Soft-Ice і дивимося на передані їй аргументи. Рано чи пізно ми зустрінемо наш глючний драйвер, після чого залишиться тільки поглянути в правий нижній кут екрану Soft-Ice, де висвічується ім'я процесу, який породив його. Більш детально - у книзі «Техніка налагодження програм без вихідних текстів», електронну копію якої можна знайти на ftp- або http-сервері nezumi.org.ru, а також на нашому диску. А ми продовжуємо мучити утиліту sigverif.exe.

Після натискання на «ОК», «Пуск» на екрані з'явиться «градусник», що відображає хід прогресу, і жорсткий диск почне шарудіти усіма своїми головками, які у нього тільки є. По завершенні роботи буде складено і виведений на екран список драйверів без цифрового підпису.

Деякі гарячі голови пропонують, в порядку очищення системи від єресі, видалити всі непідписані драйвери - тоді, мовляв, всі проблеми як хвостом зніме. А як це можна зробити? Саме грубе рішення - просто взяти і видалити їх з диска через FAR або провідник (природно, володіючи правами адміністратора!). Але наслідки такої операції можуть виявитися вельми плачевними, і краще, клікнувши правою клавішею миші на іконку драйвера в провіднику, знайти в «Властивості» ім'я виробника, за яким можна визначити, що за додаток / залізяка встановила цей драйвер, і деінсталювати її цивілізованим шляхом. Правда, тут є одне «але».

На наведеному малюнку виділено драйвер g400m.sys, Що йде разом з картою Matrox G450, і хоча Matrox зовсім не квола компанія, цифровий підпис вона не отримала (чи то Microsoft не дала, то чи сама Matrox не захотіла морочитися). Природно, після видалення його із системи, про SVGA-режимі доведеться забути. Можна, правда, сходити на сайт Matrox, скачавши найновіший драйвер (вона вже забезпечена цифровим підписом). Тільки ось ... і підписана, і непідписана версії містять безліч фатальних помилок, зокрема, в результаті збігу певних обставин при спробі перейти в overlay mode, система падає в BSOD, оскільки драйвер намагається звільнити вже звільнену пам'ять.

Таким чином, наявність / відсутність цифрового підпису саме по собі ще ні про що не говорить, і, навіть якщо ми використовуємо тільки підписані драйвери, ніяких гарантій стабільності це нам не дає.

Ось тут-то ми і переходимо до другої частини статті, а саме до тестування драйверів в умовах, наближених до бойових.

Влаштовуємо дров справжнє випробування

До складу DDK входить чудова утиліта Driver Verifier, Що створює для драйверів максимально суворі умови, які межують з екстримом і суїцидом, в яких імовірність відмови максимальна, а ім'я дефектного драйвера визначається з найвищою точністю (навіть якщо він через дефекти розробки страждає не сам, а руйнує структуру даних чужих драйверів).

Важливо відзначити, що Driver Verifier - це не ліки, а тільки засіб діагностики. Від збоїв воно все одно не врятує (навпроти, збільшить їх інтенсивність на пару порядків), але зате допоможе виявити «підлий» драйвер з достатнім ступенем вірогідності.

Отже, запускаємо verifier.exe, бачимо вікно Driver Verifier Manager, Йдемо в закладку Setting і переводимо радіокнопку в положення Verify all drivers, після чого тиснемо кнопку «Preferred Setting», яка встановлює наступні типи перевірок (verification type):

  • Special pool - перевіряється драйверам буде відведена спеціальна область пам'яті для виділення, не дуже швидко працює, зате здатна виявляти більшість типів руйнувань своїх і чужих даних.
  • Force IRQL checking. IRQL - це рівень запиту переривань (Interrupt Request Level). Найбільш частою помилкою розробників драйверів є спроба звернутися до пам'яті на такому рівні IRQL, на якому менеджер підкачки не працює. І якщо потрібна сторінка раптом виявиться витісненої на диск, система обернеться в блакитний екран з написом «IRQL_LESS_OR_EQULAR». Форсування цього режиму примусово витісняє сторінки драйвера на диск, щоб дефект розробки проявлявся в 100% випадків.
  • Low resource simulation корисно встановити, щоб подивитися, як драйвер буде вести себе при катастрофічній нестачі системних ресурсів, однак цього можна і не робити, а ось галочку Pool tracking (відстеження коректності поводження з пулом пам'яті) краще залишити. Помилки введення / виведення (I / O verification) складають незначну частину всіх помилок, тому положення цієї галки в общем-то абсолютно некритично.

Покінчивши з вибором налаштувань, натискаємо кнопку «Apply» (застосувати) і, як нам і пропонують, перезавантажується.

Відразу ж після початку завантаження робота системи відчутно сповільнитися, що так і повинно бути, оскільки ядро \u200b\u200bвиконує набагато більше перевірок, ніж зазвичай. При виявленні помилок спалахує блакитний екран смерті з ім'ям драйвера і деякою іншою інформацією, корисною для розробників, але марною для нас. Все, що ми можемо зробити, - це оновити драйвер до самої останньої версії або відмовитися від використання програми (залізяки), задействующей його. Взагалі-то, у нас є трохи більше можливостей з розпалення сирих дров, але про це трохи пізніше.

Дізнатися статус перевірки можна в будь-який момент запуском verifier.exe. У закладці Driver Status перераховані статуси всіх виявлених драйверів з поясненням поточної ситуації. Статус Loaded означає, що даний драйвер був завантажений і перевірений, по крайней мере, один раз (але, можливо, не повністю, тобто не всі ділянки драйвера встигли відпрацювати). Статус Unloaded готує про те, що драйвер був завантажений, перевірений (можливо, частково) і вивантажено використовує його системою / програмою або за своїм власним бажанням. Останнє особливо характерно для драйверів, що залишилися від обладнання, яке було видалено шляхом варварського висмикуючи плати розширення з слота, тобто без виконання деінсталяції. Що залишився в живих драйвер сканує шину, намагаючись намацати «своє» обладнання, обламується з пошуком, після чого вивантажує себе з пам'яті, до речі кажучи, сповільнюючи завантаження системи (іноді дуже значно) і конфліктуючи з іншими драйверами. Мораль: обладнання з системи потрібно видаляти за всіма правилами! Однак не всякий статус Unloaded ознака ненормальності ситуації, і, перш ніж видаляти драйвер з таким статусом, потрібно розібратися, що це за північний олень такий і звідки він взагалі тут узявся.

Статус Never Loaded вказує на те, що даний драйвер ще не був завантажений, а значить, не був і перевірений, отже, треба почекати, запускаючи різні програми, які можуть бути з ним пов'язані. Втім, деякі драйвери (особливо некоректно Деінсталювати) не завантажуються і, відповідно, не перевіряються ніколи.

Попрацювавши з системою в режимі жорсткої перевірки деякий час (від декількох годин до декількох днів), ми виявимо практично всі дефектні драйвери, від яких страждали раніше, і запишемо їх імена на папірець.

Повернути систему в нормальний режим (тобто без додаткових перевірок, зжирає продуктивність), можна за допомогою все того ж verifier'а. Повертаємося до закладки Setting, переводимо радіокнопку в положення Verify selected drivers (при цьому ніякої драйвер не повинен бути виділений), тиснемо на «Reset All», потім на «Apply» і перезавантажуємося. Усе! Тепер система працює з нормальною швидкістю, але без перевірок.

Що робити з сирими дровами?

А дійсно, що можна зробити з дефектним драйвером? Хакери, які вміють тримати відладчик в руках, при наявності достатньої кількості вільного часу, можуть його аналізувати код (благо за обсягом драйвери зазвичай невеликі), знайти помилку, і придумати спосіб її виправлення, але ... це занадто трудомісткий шлях.

Викидати драйвер (разом з тим залізом / програмою, що його використовує) теж не варіант. Хоча якщо відомо, що в блакитних екранах смерті винна звукова карта незнайомого китайського виробника вартістю $ 20, то у нас з'являється цілком вагома мотивація її замінити чимось більш гідним. Але це, власне кажучи, всім і так зрозуміло і додаткових коментарів не потребує.

Зате далеко не кожен знає, що величезна кількість збоїв і блакитних екранів смерті пов'язано з тим, що драйвер, розроблений (і протестований) в однопроцессорной середовищі, ставлять на двухпроцессорную машину. Під «двопроцесорним» тут мається на увазі як реальна платформа з двома каменями, так і Hyper-Threading / багатоядерні процесори. Відомо (і підтверджено великою кількістю тестів), що домашнього комп'ютера два процесора абсолютно ні до чого, тому що на переважній більшості додатків збільшення продуктивності при цьому практично не спостерігається.

Тому якщо система працює нестабільно, а позбутися від дефектного драйвера з тих чи інших обставин ніяк не вдається, можна спробувати залізти в BIOS Setup, перетворивши свою «віртуальну двухпроцессорную» машину в однопроцесорних. Аналогічного ефекту можна домогтися, відкривши файл boot.ini (на комп'ютерах з Windows NT / 2000 / XP він розташований в кореневому каталозі логічного диска, на якому встановлена \u200b\u200bсистема) і додавши до нього ключ / ONECPU, після чого перезавантажитися в надії, що помилки зникнуть.

лістинг 1

Приклад типового файлу boot.ini


timeout \u003d 30

multi (0) disk (0) rdisk (0) partition (1) \\ WINNT \u003d "Windows 2000 Pro" / fastdetect / SOS

лістинг 2

Налаштовуємо систему на використання тільки одного процесора з усіх наявних


timeout \u003d 30
default \u003d multi (0) disk (0) rdisk (0) partition (1) \\ WINNT
multi (0) disk (0) rdisk (0) partition (1) \\ WINNT \u003d "Windows 2000 Pro" / fastdetect / SOS / ONECPU

А ось на Windows Vista файлу boot.ini немає, і, хоча існує (тимчасова) можливість конфігурувати її завантажувальні настройки за допомогою спеціальної утиліти, Microsoft планує повністю відмовитися від цієї лазівки, так що залишиться тільки BIOS Setup. Втім, що стосується Vista, То до моменту переходу на неї розробники драйверів, напевно, обзаведуться багатопроцесорними машинами (оскільки інших просто не залишиться в продажу) та тестуватимуть свої творіння в многопроцессорном оточенні.

Ще один тонкий момент. Пам'ятаєш, ми вище говорили, що найбільш часто зустрічається помилка розробників драйверів - звернення до витісняється пам'яті на тому рівні IRQL, на якому менеджер підкачки не працює, і якщо запитувана сторінка відсутня в пам'яті, настає крах? Очевидним рішенням тут буде збільшення оперативної пам'яті до того обсягу, при якому витіснення сторінок на диск практично не відбувається. При нинішніх цінах на пам'ять прикупити пару нових «плашок» може дозволити собі практично кожен. Але існує і більш доступне (і більш елегантне) рішення проблеми. якщо параметр DisablePagingExecutive, Що знаходиться в наступній гілці реєстру HKLM \\ SYSTEM \\ CurrentControlSet \\ Control \\ Session Manager \\ MemoryManagement, Дорівнює одиниці (за замовчуванням нулю), ядерні компоненти витіснятися не будуть. Тому просто запускаємо «Редактор реєстру», міняємо цей заповітний параметр і перезавантажуємося (зміни вступають в силу тільки після перезавантаження), сподіваючись, що це допоможе вирішити проблему збоїв.