Classpnp sys windows 7 перезагружается

Зависает на classpnp.sys

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

При этом, та же проблема имеет зеркальное отображение и в обычном (нормальном) режиме загрузки: в редких случаях загрузка останавливается на анимированном логотипе (значке) Windows (bootscreen), который может «видоизменяться» на экране приветствия бесконечно долго:

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

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

Теория

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

Справедливо, поскольку зависание на classpnp.sys , наряду с черным экраном смерти и штормом прерываний, является примером недоработок в архитектуре системы Windows 7, вероятно ведущих свою родословную из недостатков архитектуры x86. Странно другое, ведь на ранних стадиях загрузки операционной системы (начиная с кода сектора MBR, Bootmgr) уже обеспечена простая диагностика, которая выводит сообщения в текстовом режиме в качестве реакции на ошибки. Получается, что отсутствие подобного подхода при зависании на classpnp.sys наблюдается по причине возникновения блокировок в коде ядра в части обработки ошибок/таймаутов от сторонних драйверов [устройств] на раннем этапе загрузки, вероятно разработчики посчитали подобный код бессмысленными, поскольку он все-равно не сможет отработать? Поэтому:

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

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

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

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

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

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

• Выполняется код микропрограммы BIOS /UEFI (POST);
• Выполняется код сектора MBR;
• Выполняется код сектора(ов) PBR;
• Выполняется код модуля Bootmgr.exe(.efi);
• Выполняется код модуля Winload.exe(.efi) ;
• Выполняется инициализация ядра ( ntoskrnl.exe | ntkrnpa.exe | ntkrnlmp.exe | ntkrpamp.exe )
• Ядро создает/запускает процесс SMSS , который создает сессии:
  • Сессия 0
    • запускается копия процесса CSRSS :
    • Wininit
    • SCM (services.exe)
    • LSASS
    • LSM
  • Сессия 1
    • запускается копия процесса CSRSS :
    • WinLogon
    • LogonUI.exe
    • UserInit
    • оболочка ( explorer.exe )
    • Приложения автозагрузки

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

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

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

Этап Winload

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

• жестко заданные во внутренней переменной OslMicrosoftBootImages ;
• загружаемые уже при подключении и разборе ветви реестра HKLM\SYSTEM\CurrentControlSet\services ;
• загружаемые при разборе зависимостей используемых функций;

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

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

Источник