Компьютер зависает намертво: решение за 5 шагов

Что есть сам classpnp.sys?

Classpnp — общая библиотека класса устройств хранения информации (жестких/твердотельных накопителей, ленточных устройств, CD/DVD-ROM’ов и аналогичных), используемая драйверами жестких дисков, CD/DVD-ROM, ленточных накопителей (включая SATA/SCSI-накопители).

Из определения следует, что любой драйвер, относящийся к классу устройств хранения информации (магнитных, ленточных, оптических), использует функции данной библиотеки в процессе функционирования. Действительно, образ представляет собой типовую системную библиотеку (DLL), содержащую набор устройствонезависимых процедур (функций), используемых классом отмеченных ранее устройств.

Похоже что данная библиотека — это библиотека, функции которой используются всеми драйверами накопителей (устройств хранения) в операционной системе Windows. Библиотека обеспечивает для системных/сторонних драйверов уровня ядра общие процедуры работы с устройствами хранения на уровне обслуживания пакетов IRP, поддержки функций PnP и управления питанием, выполнения общих алгоритмов работы с памятью, чтения, записи, инициализации, конфигурации устройств, работа с уровнями IRQL, обработку ошибок и много прочей аналогичной необходимой требухи.

В Windows XP и последующих операционных системах, некоторые из наиболее часто используемых сервисов, ранее предоставляемых прямыми вызовами к библиотеке classpnp.sys, теперь предоставляются драйвером класса. Поэтому в Windows XP (и более поздних системах) обычно нет необходимости прямого вызова функции classpnp.sys из сторонних минипорт-драйверов.

Драйвера класса устройств хранения информации вместе с соответствующим драйвером порта, используются для взаимодействия с конечными физическими накопителями. Драйвера класса располагаются в стеке (драйверов) выше драйверов портов и управляют устройствами своего класса, вне зависимости от того, к какой шине они подключены.

Ну что же, бегло ознакомились с функциональными особенностями мнимого виновника торжества? Теперь нам необходимо разобраться со структурой данного «драйвера», понять как и когда он загружается и загружается ли вообще.

Что еще между точками?

Ну хорошо, помимо инициализации вышеописанных драйверов, что у нас еще расположено между найденными нами точками останова? Да там адская прорва кода!! Получается, что весь код, размещающийся от начала кода модуля ядра в функции KiSystemStartup и до окончания в функции Phase1InitializationDiscard (фактически всей фазы 1), может, потенциально, являться причиной изучаемого нами подвисания (в безопасном режиме).

Да уж, тут, что называется, без комментариев!!Но не все так страшно, как кажется на первый взгляд. В большинстве расположенного на этом участке кода ядра выполняется обработка возникающих ошибок, что тем или иным образом (в виде сообщений) становится известно пользователю.

А вот где действительно могут скрываться «мертвые» зависания процесса загрузки, так это на стыке хорошо отлаженного кода ядра и кода сторонних драйверов (то есть на этапе загрузки/инициализации драйверов сторонних разработчиков). Судя по всему в ядре существуют несколько цепочек кода загрузки подобных драйверов:

Вот перечисленные то функции нам в первую очередь и интересны. В дополнение участвует функция MmLoadSystemImage, которая выполняет загрузку исполняемого образа драйвера в адресное пространство ядра (создает секции и производит связывание, заполняет таблицы импорта, перемещения, выполняет проверки безопасности и прочие задачи.).

Еще одна функция IopLoadDriver работает с реестром, ответственная за открытие файла драйвера, создание объекта драйвера и передачу управления на точки входа (вызов процедуры инициализации DriverEntry).

Для драйверов режима BOOT_START, функции IopLoadDriver и MmLoadSystemImage не участвуют в процессе, поскольку, как мы писали ранее, данные драйвера загружаются еще на этапе winload.exe.

Если предположить, что я допустил ошибку в оценке области подвисания, то в эту область еще должны входить последующие этапы, начиная с smss.exe и до самого logonui.exe. А мы знаем, что на этих этапах уязвимым для сбоев местом являются сервисы/службы режимов AUTO_START и DEMAND_START как загружаемые на схожих с драйверами принципах.

. . .

ПРОДОЛЖЕНИЕ СЛЕДУЕТ

. . .

Classpnp.sys отказывается грузиться: в чем причина?

Вторая точка останова

Теперь давайте попробуем определиться со второй точкой останова.

Как искать вторую точку? Загружаясь в безопасном режиме на нормально работающей станции, мы замечаем, что после вывода на экран имени classpnp.sys происходит кратковременная задержка и выполняется переключение между графическими режимами видеоадаптера.

Судя по всему, ядро принимает от кода модуля Winload.exe управление в собственной точке входа, которая является первой инструкцией функции KiSystemStartup. После этого процесс инициализации ядра системы проходит несколько внутренних этапов, во время которых на экране отображается все тот же «текстовый» режим (с уже знакомым нам списком загруженных драйверов).

Затем происходит переключение в графический режим с разрешением 640×480 и выводом анимированного логотипа загрузки (bootscreen). Анимация этого логотипа обеспечивается группой функций с суффиксом Invb*, которые занимаются инициализацией драйвера видеокарты и последующим выводом разнообразных графических примитивов.

Например, функция InbvUpdateProgressBar в определенном режиме обновляет прогресс-бар времени загрузки.Но это все представляет для нас лишь опосредованный интерес, поскольку после текстового режима загрузка уходит в графический режим далеко не сразу.

Этап с выводом логотипа находится в модуле ядра, а вот переход к следующему (графическому) этапу происходит позже, во время загрузки диспетчера (менеджера) сессий SMSS (модуль smss.exe). Вычислил я это экспериментальным путем, проставляя точки останова по ходу исполнения этапов инициализации ядра.

В конце концов я обнаружил интересную процедуру с именем Phase1Initialization, в которой происходит вызов вложенной процедуры Phase1InitializationDiscard, в конце которой мы находим следующий фрагмент кода:

Между точками: инициализация драйвера classpnp.sys

Помните мы говорили, что загрузка большинства драйверов происходит на этапе работы модуля Winload.exe, а вот связывание и инициализация этих драйверов происходит уже на этапе работы модуля ядра (ntoskrnl.exe).

Выходит что и инициализация интересующей нас библиотеки classpnp.sys происходит на этапе функционирования ядра. Давайте проверим, могут ли проблемы с инициализацией быть причиной зависания, для этого изучим внутреннюю структуру драйвера classpnp.sys.

и код вызываемой подфункции:

Ну и что мы тут видим? Помимо сервисной функции __security_init_cookie, которая, по заверению разработчиков, предназначается для защиты от переполнения буфера (При входе в функцию с защитой от переполнения cookie-файл помещается в стек, а при выходе значение в стеке сравнивается с глобальным cookie-файлом.

Любое различие между ними указывает, что произошло переполнение буфера, что приводит к немедленному завершению работы программы), процедура инициализации этого драйвера не выполняет никаких специфических действий, по большому счету не делает вообще ничего, что могло бы её подвесить, даже не инициализирует привычных структур драйвера и не содержит никаких вложенных вызовов, просто-напросто возвращает управление с кодом STATUS_SUCCESS (EAX=0). И о чем нам это может говорить? Это говорит нам о том, что:

Сам по себе код classpnp.sys на этапе инициализации не является источником проблем, поскольку это библиотека для стороннего использования и процедура инициализации её исключительно формальна (предельно проста).

Такое возможно, однако требуется дополнительное подтверждение. Вспоминаем, что драйвер classpnp.sys является библиотекой класса устройств и его функции вызываются из других драйверов. Надо проверить все драйвера режима BOOT_START на предмет использования функций данной библиотеки.

Между точками: инициализация драйвера disk.sys

Ну что же, тогда перейдем к драйверу disk.sys и проверить гипотезу о причастности его к подвисанию, с этой целью дизассемблируем и заглянем в код. Данный драйвер является драйвером класса дисковых накопителей и обеспечивает монтирование сконфигурированных в системе дисковых томов.

В драйвере процедура инициализации (DriverEntry) выглядит уже намного сложнее, в ней мы обнаруживаем вызовы функции ClassInitialize, которая не является собственной внутренней функцией драйвера, а импортируется из библиотеки класса устройств classpnp.sys.

Один интересный момент: на экране (в списке) мы видим пункт с драйвером disk.sys ДО classpnp.sys, тем не менее, для того, чтобы disk.sys мог использовать некоторые свои функции, библиотека classpnp.sys должна быть УЖЕ загружена и инициализирована ДО загрузки и инициализации disk.sys.

Этот факт лишний раз подтверждает, что та последовательность загрузки драйверов, которую мы наблюдаем на экране при запуске в защищенном режиме, всего-навсего отражает очередность загрузки драйверов/библиотек в память на этапе работы модуля загрузчика Winload, но никак не отражает очередность их инициализации на стадии ядра Ntoskrnl.

Хорошо, переключаемся на изучение исходного кода драйвера classpnp.sys и анализируем код функции ClassInitialize, а вот он то как раз ужасающе огромен 🙂 Но ошибочные коды возврата все же удалось обнаружить:

• Функция возвращает C0000059 (STATUS_REVISION_MISMATCH): в случае расхождения размера структуры InitializationData, фактически проверка версии файла classpnp.sys.
• Функция возвращает C0000059 (STATUS_REVISION_MISMATCH): если требуемые поля структуры (фактически ссылки на соответствующие функции драйвера) нулевые (NULL).
• Функция возвращает C000009A (STATUS_INSUFFICIENT_RESOURCES): если нулевое значение буфера RegistryPath.Buffer в расширениях driverExtension. То есть похоже не выделился буфер по каким-то причинам.
• Функция возвращает C0000035 (STATUS_OBJECT_NAME_COLLISION): в любом ином случае.

Драйвер disk.sys обеспечивает функционирование стека устройств хранения в операционной системе Windows, и ниже данного драйвера в стеке располагаются:

• драйверы многопутевого ввода-вывода (MPIO-драйвера, обеспечивающие доступность томов по нескольким путям) (mpio.sys и прч.);
• драйверы порта (обеспечивает поддержку транспортного протокола: SCSI/SAS/SATA/ATAPI);
• драйвер минипорта (обеспечивает функциональность контроллера на материнской плате);

Но, опять же, сам драйвер disk.sys на этапе функционирования ядра (ntoskrnl.exe) не может быть причиной зависания, поскольку тут он инициализируется: вызывается функция инициализации драйвера DriverEntry.

Общая теория загрузки

Перед тем как понять, какое же место classpnp.sys занимает в системе, нам необходимо освежить в памяти общую теорию загрузки. Из неё мы знаем, что весь процесс запуска операционной системы Windows 7 на начальных стадиях можно описать следующим образом (упрощенное представление):

Есть примета, что если зависает на classpnp.sys — это к апгрейду 🙂 Если серьезно, то за все время компьютерной практики относительно данной темы накопилось несколько наблюдений:

1. В разные периоды практики удавалось понаблюдать очень похожие между собой сбои, когда возникали ситуации, в которых загрузка в безопасном режиме зависала не на самом драйвере classpnp.sys, а на следующих за ним, то есть этот драйвер не был последним в списке (например, иногда загрузка вставала на agp440.sys).
2. На нормально загружающихся в безопасном режиме системах периодически наблюдал картину, когда текстовый режим кончался на выводе строки classpnp.sys с надписью «Подождите, пожалуйста…», после чего присутствовала совсем уж короткая пауза и загрузка уходила в графический режим и продолжалась. Делаем выводы, что приведенная строка ожидания характеризует конец одного (визуально определяемого нами как «текстовый») этапа загрузки и переход к следующему (визуально «графическому»).

Каково, а? Первый пункт, я бы сказал, просто расшатывает столпы веры в то, что виновником является именно драйвер classpnp.sys. Отсюда непременно возникает один резонный вопрос: действительно ли причина зависания кроется в тех драйверах, которые мы наблюдаем в списке на экране монитора? Или то что мы видим является ли истинной причиной происходящего?

Общие причины

Общие причины подвисания следующие:

• установленное на станции железо: после загрузки общих библиотек/драйверов (в том числе и classpnp.sys) начинается перечисление устройств и загрузка драйверов к ним.
• подключение системных томов: возможно ядро не может проинициализировать устройство (накопитель), на котором располагается один из сконфигурированных в системе разделов.
• установленное на станции железо: возможно загрузка какого-либо драйвера устройства проводит первичную инициализацию устройства (через вызов инициализации драйвера и вложенных процедур), которая не может завершиться, подвешивая весь процесс запуска системы.

Первая точка останова

Как уже было рассмотрено, процесс загрузки некоторых драйверов категории BOOT_START начинается на этапе работы модуля winload.exe. Поэтому было решено начать с модуля winload.exe и попытаться обнаружить в нем участок кода, в котором процесс загрузки может подвиснуть на том самом текстовом участке (после вывода списка драйверов и сообщения «Подождите, пожалуйста..»).

Далее, мы постараемся модифицировать найденный фрагмент таким образом, чтобы ввести в бесконечный цикл (подвесить), тем самым найдя первую точку останова. Самая удачная, по моему мнению, точка — это непосредственно перед передачей управления коду ядра ntoskrnl.exe.

Где осуществляется передача управления? Для выяснения этого стартуем с начала основной процедуры OslMain и доходим до её финальной части, где код передачи управления происходит через вызов процедуры OslArchTransferToKernel. Вот так выглядит обрамляющий участок кода:

после непродолжительного оттупления, было решено заменить два маркированных (выделены цветом) пуша на инструкцию зацикленного прыжка jmp $ (опкоды EB FE). Изменения выполняем в шестнадцатеричном редакторе методом поиска длинной сигнатуры и замены (двух) байтов.

Удача!! Произошло зависание процесса загрузки внутри «текстового» этапа на строке, содержащей имя драйвера classpnp.sys. Значит, мы попали своей модификацией в нужное место. Условимся, что отправная первая точка останова найдена.

Теория

На данный исторический момент уровень моих знаний оставляет желать лучшего, тем не менее, все же попытаемся выйти за привычный ареал обитания, распахнуть, так сказать, рамки собственного познания, тем самым устремившись навстречу эволюции 🙂 В очередной раз не перестаешь удивляться отсутствию у одной из самых популярных настольных операционных систем продуманной диагностической подсистемы.

Частные причины [решения]

предположение: проблема как то связана с загрузочным носителем либо контроллером или шлейфом.. одним словом с дисковой подсистемой.решения:

• BIOS: перепрошивка BIOS на последнюю версию сброс всех настроек в [Factory] Default (умолчание);
• BIOS: замена механизма подключения дисков с AHCI → IDE (и наоборот);
• BIOS: смена режима работы контроллера с Compatible (Legacy) Mode → Enhanced (Native) mode (и наоборот);
• BIOS: смена режима загрузки CSM (Legacy) ↔ UEFI;
• Железо: вышедшие из строя сторонние аппаратные модули (например: WIFI/Bluetooth/CardReader): отключение их в BIOS или (при возможности) физически на материнской плате;
• Железо: попробовать использовать для загрузочного диска другой порт IDE/SATA на материнской плате;
• Железо: в случае наличия в системе нескольких накопителей — поочередное отключение носителей (HDD/SSD);

Железо: заменить кабели данных/питания;

• Железо: проверка утилитами SMART-мониторинга состояния основного загрузочного диска (замена в случае наличия существенных проблем);
• Железо: проблема с модулями ОЗУ (RAM) нестандартные настройки таймингов при использовании «нестандартных» модулей/разгоне;
• ОС: загрузиться с LiveCD, подцепить реестр сбойной машины, в ветке HKLMSYSTEMCurrentControlSetservices пройтись по всем ключам и для каждого драйвера с параметром START = 0 проверить физическое наличие в файловой системе соответствующего файла.
• ОС: загрузиться с LiveCD, подцепить реестр сбойной машины (ветка HKLMSYSTEMCurrentControlSetservices), пробежаться по всем ключам и для каждого драйвера этапа BOOT_START (список выше в статье) проверить чтобы параметр START был равен 0.
• ОС: проверка файловой системы диска (команда: chkdsk c: /f /r);
• ОС: подмена/повреждение драйверов этапа загрузки:
• ОС: Разнообразные модификации ключевых структур разметки жесткого диска: например, сокрытие/отображение дисков при помощи сторонних утилит (Acronis);
• ОС: Отключение любого ПО, способного вмешиваться в ранние этапы загрузки ОС: антивирусы, оптимизаторы, системы обнаружения вторжений и прочее подобное;

Шаг 1: драйвера

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

Если картинка встает при запуске музыки или проигрывании видео, то тут может быть проблема со звуковой картой. Особенно это актуально, если изначально был установлен кривой драйвер. Вот что я бы сделал:

1. Откройте «Диспетчер устройств» – этот пункт находится в «Свойствах» компьютера.

2. Открываем раздел «Видеоадаптеры», нажимаем правой кнопкой мыши по вашей видюхе и удаляем устройство. Аналогично проделываем и со звуковой картой.

3. После этого, будучи подключенным к интернету нажимаем по кнопке обновления конфигурации оборудования, которая находится в верхней панели. Эти же устройства можно обновить и вручную, или просто перезагрузив компьютер.

Шаг 2: чистка системы

В первую очередь вспомните, не устанавливали ли вы ранее какие-то программы и приложения, после которых начался весь этот бардак. Чистку мы начнем именно с удаления лишних программ в системе:

1. Зайдите в «Панель управления». В Windows 7 нужно перейти в «Пуск», а в Виндовс 10, нажать на клавиши и R и вписать команду:

control

2. Переходим в «Программы и компоненты».

3. Теперь вам нужно пройтись по всем установленным приложениям и удалить, все лишнее и не нужное – то что вы не используете.

Теперь нам нужно зайти в раздел «Автозагрузка» и посмотреть, какие программы висят при запуске ОС. В Windows 7 нужно нажать на клавиши и R и прописать команду:

msconfig

В винде десятке кликаем правой кнопкой мыши по кнопке «Пуск» и вызываем «Диспетчер задач».

На вкладке «Автозагрузка» расположены все программы, которые работают сразу при загрузке системы. Отключите все кроме антивирусной программы. Если вы увидите что-то с названиями NVIDIA или AMD, то тоже отключите – это не драйвера, а программы, которые в теории не особо нужны. После этого перезагружаем комп.

Шаг 3: проверка и чистка компьютера

Нам нужно снять боковую крышку компьютера и почистить его от пыли. Особенно это касается самых горячих мест: видеокарта и процессор. Желательно также поменять термопасту, если вы давно этого не делали. Проверьте, чтобы все цепи питания были плотно подключены к устройствам. Можно даже попробовать вытащить и переподключить коннекторы от блока питания.

Можно проверить температурный режим в процессоре и видеокарте в той же программе AIDA64. Если температура очень высокая, то скорее всего проблема именно в термопасте.

Шаг 4: оперативная память и жесткий диск

В первую очередь давайте проверим жесткий диск. Для этого можно использовать любую из предложенных программ:

• HDD Health, HDDLife
• Hard Disk Sentinel
• HDD Victoria

Программы покажут вам оценку вашего носителя.

Далее нужно обязательно проверить оперативную память. Это можно сделать несколькими способами. Можно воспользоваться средствами Windows – нажимаем R и прописываем mdsched.

Или воспользоваться сторонней программой memtest86 . Её можно запустить как в уже установленной винде, так и из-под BIOS с помощью загрузочной флешки. Есть ещё третий способ проверки оперативы – нужно вытащить все плашки памяти кроме одной и тестировать работу в таком режиме. Если виновник будет найден, то нужно будет заменить поломанную плашку.

Шаг 5: причины и действия

Читатель, если ты читаешь эти строки, то скорее всего тебе ничего не помогло (из того, что я уже писал выше). А значит проблема кроется, скорее всего, в железе. Причин может быть несколько:

• Если вы недавно установили новую видеокарту, то в первую очередь проверьте, чтобы мощности вашего блока питания хватало для работы всей системы.
• Проблема может крыться в SSD – тогда его можно попробовать перепрошить.
• Пробуйте зайти в BIOS и отключить режим «Turbo Mode» – этот режим увеличивает частоту процессора в играх или программах.

• Если есть возможность, то попробуйте подключить другой блок питания.

В качестве последнего совета, я бы установил на комп новую систему. Особенно это касается случаев, когда вы до этого меняли какие-то комплектующие (видеокарту, материнскую плату, процессор и т.д.).

Этап ntoskrnl

Собственно, это ни что иное как ядро операционной системы. На самом деле имя ntoskrnl.exe используется только в одноядерной системе (без режимов SMP/PAE). Имена ядра определяются следующим образом:

• ntoskrnl.exe — (1 ядро ЦП);
• ntkrnlmp.exe — (N ядер ЦП, SMP);
• ntkrnlpa.exe — (1 ядро ЦП, PAE);
• ntkrpamp.exe — (N ядер ЦП, SMP, PAE);

Как мы знаем из теории загрузки операционной системы Windows, после передачи управления на код модуля ядра, в нем происходит последовательная инициализация множества подсистем ядра. Поэтому дизассемблируем и начинаем изучать исходный текст актуального (на моей тестовой конфигурации это был ntkrnlpa.exe) ядра.

Если честно, задача перед нами стоит не такая уж и тривиальная и по уму нам предстоит проанализировать множество этапов загрузки операционной системы и попытаться связать кодовые ветвления с событиями, происходящими на экране монитора. Тем не менее, при отсутствии исходников на языке C и знаний по декомпиляции кода из машинного языка в листинг на C, разобраться в дизассемблированных исходных кодах будет непросто, благо что разработчиком предоставляются символы ядра.

Итак, выше мы уже упоминали, что визуально на экране надпись «Подождите, пожалуйста…» знаменует окончание какого-то одного этапа загрузки и переход к следующему, при том что деление это чисто формальное, но для нас оно требуется с целью упрощения понимания происходящего.

Теперь, за неимением другой внятной логики, нам надо визуально привязаться к тому, что происходит на экране, но как отследить момент начала текстового этапа и его конец? Поскольку я не умею пока работать с удаленной отладкой, был использован следующий алгоритм действий: мы будем расставлять так называемые «точки зацикливания» (точки «подвисания»), представляющие собой пару машинных опкодов EB FE (команда «прыжка на месте» — jmp $) и вводящие процессор в бесконечный цикл выполнения.

Этап winload

Где же впервые в коде модулей запуска встречается загрузка каких-либо системных или сторонних драйверов/библиотек? Очевидно что на этапе Winload.exe, поскольку именно в коде данного модуля впервые начинают загружаться системные драйвера с флагом BOOT_START.

С целью анализа нам придется изучать исходный код, для этого расчехляем IDA и дизассемблируем код модуля Winload.exe. После продолжительного изучения алгоритмов можно прийти к выводу, что исполнение кода модуля начинается с точки входа в процедуре OslMain.

Уже из этой процедуры вызывается дочерняя функция OslInitializeCodeIntegrity, которая проверяем целостность модулей, участвующих в загрузке. В коде основной функции встречается интересная вложенная функция под названием OslpLoadAllModules, которая используется разнообразным кодом для обеспечения загрузки системных модулей (они же — драйвера/библиотеки режима ядра). Могу ошибаться, но мне показалось, что все модули, загружаемые через неё на начальной стадии, делятся на:

Непосредственно сама загрузка производится через вложенную функцию OslLoadImage (и подчиненную LoadImageEx). Теперь настало время ознакомиться с полным списком загружаемых кодом модуля Winload.exe драйверов:

В таблице представлены (сведены) драйверы, у которых соответствующий параметр START выставлен в значение 0, то есть приведенные в таблице драйвера можно смело назвать группировкой драйверов режима загрузки (BOOT). Столбец зависимостей приведен в таблице не случайно, он то как раз нужен нам с целью определения функциональных взаимосвязей (зависимостей на уровне функций) того или иного драйвера.

В модуле winload.exe драйвер с именем classpnp.sys вы не найдете ни в жесткозакодированных (вкомпилированных) переменных, ни в ветвях реестра. Он загружается при разборе зависимостей от драйвера disk.sys, который использует некоторые функции classpnp.sys.

Одним из первых загружается образ ядра (ntoskrnl.exe) и уровень аппаратных абстракций HAL.DLL, но секции импорта у этих модулей на данном этапе не разрешаются (то есть указанные модули просто подгружаются в память без связывания).

Соответственно и код библиотеки на этом этапе всего-лишь загружается в адресное пространство ядра, для того что бы в последствии, после инициализации, функции были «видимыми» (доступными) для кода других драйверов. Затем, таблица импорта актуального модуля ядра (ntoskrnl.exe и аналогичные) заполняется и связывается (при помощи функции LoadImports и вложенной в неё BindImportRefences).

В процессе функционирования модуля Winload.exe драйвера режима загрузки только лишь подгружаются в память, но не инициализируются.

Отсюда рождается ряд вопросов:

Выводы

При изучении некоторых функций модулей загрузки, я вышел на некий термин Adding Event Tracing to Kernel-Mode Drivers, вероятно возможность появилась начиная с версии Windows Vista. ETW и WPP — два инструмента диагностики для системных приложений (в том числе и драйверов).

Интересно, можно включить через утилиту perfmon логгирование для classpnp/disk? Памятка: Группы сборщиков данных — сеансы отслеживания событий — ПКМ — создать — группа сборщиков данных — создать вручную (для опытных) — далее — в окне поставщики жмем добавить — Disk Class Driver Tracing Provider и Classpnp.

Тем не менее, тут же возникает резонный вопрос: как это применимо к уже подвисающим станциям? Как на них можно включить логгирование и получить отчет?К тому же, интересно, описанная в статье проблема зависания на classpnp.sys решена в Windows 10?