Ошибка aspi sys

Aspi.sys

Ошибки Aspi.sys

Проблемы Aspi.sys обычно связаны с ошибкой синего экрана смерти, также известной как ошибка «BSOD» или «Stop»:

• «Windows неожиданно завершает работу из-за проблемы с aspi.sys. «
• «: (Aspi.sys вызвал ошибку. Компьютер необходимо перезагрузить. «
• «STOP 0x0000000A: IRQL_NOT_LESS_EQUAL – aspi.sys»
• 0x01E: КМОДЕ_ИСКЛЮЧЕНИЕ_НЕТ_ОБРАБАТЫВАЕТСЯ — aspi.sys
• СТОП 0x050: СТРАНИЦА_FAULT_IN_NONPAGED_AREA — aspi.sys

В большинстве случаев после установки нового оборудования или программного обеспечения возникнут ошибки синего экрана aspi.sys. Ошибки aspi.sys, связанные с SuSE LINUX 8.2 Personals, часто возникают во время установки программного обеспечения, связанного с aspi.sys, во время завершения работы или запуска Windows или во время загрузки драйвера устройства, связанного с SuSE Inc.. Важно отметить, когда происходят ошибки синего экрана с aspi.sys, так как это помогает устранять проблемы, связанные с SuSE LINUX 8.2 Personals, и сообщать о них в SuSE Inc..

Источник ошибок Aspi.sys

Проблемы с прошивкой, драйвером, оборудованием или программным обеспечением могут привести к ошибкам синего экрана, связанного с aspi.sys. Они могут быть связаны либо с программным обеспечением SuSE LINUX 8.2 Personal или аппаратным обеспечением SuSE Inc., но это не обязательно так.

Более конкретно, данные ошибки aspi.sys могут быть вызваны следующими причинами:

• Неправильно сконфигурированные, старые или поврежденные драйверы устройства SuSE LINUX 8.2 Personal (очень часто).
• Недопустимая или поврежденная запись реестра Aspi.sys, связанная с Aspi.sys и SuSE LINUX 8.2 Personal.
• Вредоносные программы заразили aspi.sys (или связанный с SuSE LINUX 8.2 Personal), создавая повреждения и ошибки aspi.sys.
• Ошибка Aspi.sys изMSuSE Inc. аппаратных конфликтов после новой установки.
• Установка SuSE LINUX 8.2 Personal создание aspi.sys (или связанного системного файла) повреждения или удаления.
• Сбой жесткого диска, связанный с aspi.sys Синий экран смерти.
• Поврежденная оперативная память/память из aspi.sys Синий экран смерти.

Порой случается и такое, что обращаешь внимание на сущую мелочь, безделицу, к изначальному объекту твоего внимания никакого отношения не имеющую. Однако со временем, этот безобидный, на первый взгляд, предмет твоего невольного интереса может запросто превратиться в источник различного рода проблем. Так бывает в жизни и точно таков мир операционных систем, где постоянно изменяющийся код системных компонентов может в какой-то момент кардинально преобразовать ситуацию. Иногда, так сказать по долгу «службы», приходится анализировать системные журналы Windows, представляющие собой один из многочисленных источников информации о состоянии системы. Именно в нем иной раз можно найти записи об уже существующих и даже потенциальных, так сказать предстоящих неисправностях. Так вот, в одной далекой-далекой компании, имя которой не разглашается дабы не скомпрометировать доброе имя и не навредить коммерческим интересам, ну а более в целях создания статейной интриги специалистами было отмечено, что (иногда) при анализе системных журналов встречались любопытные события. Возникавшие с завидной регулярностью, события эти сводились к ошибкам функционирования одного и того же драйвера aspi32.sys, имели коды 7026, 1060, 7000 и содержали следующее описание:

либо такие вот пары событий, следующих друг за другом:

Тем не менее ошибки эти никак внешне себя не проявляли, ну или об этих проявлениях ничего не было известно, поэтому никто этому особого значения и не предавал. Никаких жалоб и замечаний от сотрудников на данных рабочих местах никогда не поступало. Однако, всё течет, всё меняется, и в один прекрасный момент поступило обращение на тему появившейся ни с того, ни с сего, на ровном месте, продолжительной загрузки операционной системы на одной из клиентских рабочих станций. При анализе деталей происшествия было определено, что визуально задержка происходит после появления экрана заставки с логотипом Windows (значок, флажок).

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

Изучение

Поскольку углубиться в проблему можно лишь при использовании специализированных средств, на ум сразу же приходит вариант исследования инцидента при помощи технологию Event Tracking for Windows с применением утилит xbootmgr и xperf из комплекта Windows Performance Tools. После сбора событий (процесс подробно описан в статье по приведенной выше ссылке) и последующего анализа получившихся логов, были локализованы некоторые любопытные моменты. Во-первых, при изучении результирующего графика Boot Phases, открылась следующая картина:

..из которой видно, что фаза Pre Session Init (она же PreSMSS: Kernel Initialization) занимает времени более обычного. Необходимо понимать, что происходит с системой на протяжении всей фазы: одним из основных событий тут является загрузка драйверов с флагом BOOT_START и SYSTEM_START. Соответственно, что бы понять, что именно тормозит на этапе PreSMSS, обратимся к графику Generic Events. Из анализа сводной таблицы (Summary Table) графика, а именно дерева: провайдер: Microsoft-Windows-Kernel-PnP, задача: DriverLoad, я обнаружил вот что:

Очевидно, что драйвер с именем aspi32.sys по какой-то пока что необъяснимой причине пытается инициализироваться в течении 73 (!) секунд. Апофеозом процесса инициализации драйвера является выход с десятичным кодом возврата 3221226347 (шестнадцатеричный эквивалент C000036B), что намекает на NTSTATUS с символическим описанием STATUS_DRIVER_BLOCKED_CRITICAL, фактически указывающим на ошибку инициализации драйвера. Вне зависимости от того, влияет ли это каким-то образом на загрузку остальных драйверов или нет, это ситуация из ряда вон выходящая!!

Что такое ASPI?

Обнаруженный нами драйвер (естественно) сконфигурирован на загрузку в ветке реестра HKLM\SYSTEM\CurrentControlSet\services и помечен флагом SYSTEM_START (параметр Start = 1). Соответствующий файл драйвера с именем aspi32.sys располагается в директории %Windir%\SysWOW64\Drivers\ и судя по ключевому слову ASPI, содержащемуся в названии, явным образом относится к интерфейсу ASPI.

ASPI (акроним Advanced SCSI Programming Interface, Усовершенствованный программный интерфейс SCSI) — программный интерфейс, стандартизирующий взаимодействие между SCSI/ATAPI-контроллером, периферийными устройствами на шинах SCSI/ATAPI и приложениями. Роль интерфейса сводится к абстрагированию от специфических особенностей того или иного хост-адаптера и обеспечению общего, простого программного интерфейса для SCSI/ATAPI-устройств.

В определении важно отметить, что не смотря на явное упоминание SCSI в аббревиатуре, на деле интерфейс ASPI может использоваться не только для взаимодействия с устройствами на шине SCSI, но так же и с IDE/ATAPI-устройствами, поскольку ATAPI практически полностью идентичен SCSI на уровне команд, не зря его называют «SCSI поверх IDE» или «SCSI по ATA-кабелю».
Немного истории. В начале 90х ASPI был разработан компанией Adaptec для обеспечения взаимодействия большого количества не придерживающихся стандарта SCSI-адаптеров, поскольку несмотря на использование единой системы команд, выполнение этих команд адаптеры могли обеспечивать по-разному, в зависимости от собственной специфики. Таким образом ASPI был призван преодолеть разного рода несовместимость всего спектра SCSI-устройств, от устаревших до современных, транслируя данные таким образом, чтобы приложения могли общаться со всеми типами SCSI-устройств и контроллеров. В это время на рынке, помимо SCSI присутствовал и другой стандарт для взаимодействия с дисковыми накопителями называемый ATA(IDE), расширенный чуть позже в ATAPI. В определенный момент в интерфейс ASPI была включена поддержка ATAPI, после чего он стал единой универсальной точкой взаимодействия со SCSI/ATAPI-устройствами, которая существенно облегчала разработчикам драйверов/программ написание «универсального» кода работы с большинством типов существовавших в то время на рынке устройств. Поскольку ASPI начал развиваться задолго до появления Windows, к моменту популяризации операционной системы от Microsoft, он предоставлял собой уже довольно развитой и удобный (с точки зрения программирования) интерфейс. По этой, а так же по ряду других причин интерфейс ASPI на долгое время стал своеобразным стандартом де-факто для работы с внешними накопителями (CD/DVD/Blu-ray), предпочтительным по отношению к встроенным механизмам операционных систем от Microsoft. С поддержкой ASPI было написано большое количество приложений, и именно поэтому слой ASPI так долго просуществовал в виде сторонних реализаций (библиотек/драйверов) во многих операционных системах.

Поддержка ASPI в операционных системах

Но давайте посмотрим как реализована поддержка интерфейса в операционных системах Windows. Во времена Windows 95 никакой похожей на ASPI технологии у разработчиков из Microsoft не было, поэтому предлагаемый Adaptec слой ASPI был лицензирован и интегрирован в систему, в подобном варианте просуществовав вплоть до Windows Millenium. Однако линейка Windows NT/2000/XP, по замыслу разработчиков, изначально была лишена поддержки классического ASPI, вместо него в Microsoft был разработан и внедрен собственный, не совместимый со стандартными вызовами ASPI-функций, минимальный интерфейс ASPI (иначе называемый SCSI Pass Through interface, SPTI). Связано это с тем, что в общем смысле Microsoft всегда преследовал цель избавиться в своих операционных системах от нативной (встроенной) поддержки сторонних технологий, разработанных вне Microsoft, а в частном контексте MS не устраивал уровень безопасности ASPI. Закономерным итогом этой тенденции явилось планомерное вытеснение ASPI более жизнеспособными технологиями, которые опирались на интерфейсы, имеющие встроенную поддержку операционной системы. Фактически после Windows 95/98 Microsoft перевел ASPI в статус внешнего интерфейса, поэтому для инсталляции внешней реализации интерфейса ASPI в операционных системах Windows предписывалось использовать сторонние программные комплекты.
Следовательно, если приложению требовалась поддержка интерфейса ASPI, оно должно самостоятельно позаботиться о ней, установив в систему библиотеки/драйвера посредством инсталляции следующих комплектов:

• Комплект (freeware) Adaptec ASPI;
• Многочисленные «сторонние» пакеты, такие как: ForceASPI, FrogASPI, ASAPI или MekugiASPI;

Подобные вышеописанным комплекты поддержки ASPI устанавливали в систему (как минимум) два файла:

• Библиотека wnaspi32.dll — судя по всему, обеспечивает сопряжение с интерфейсом Win32;
• Драйвер виртуального устройства aspi32.sys — служит для взаимодействия непосредственно с драйверами устройств;

Но, вернемся к теме нашей статьи. Описываемый мною инцидент был зафиксирован под версией Windows 7 Профессиональная x64, и в этой операционной системе мы не обнаруживаем никакой «встроенной» поддержки ASPI. Из этого следует, что драйвер по отношению к Windows 7 считается мало того что «сторонним», но еще и несовместимым, о чем красноречиво говорит нам ошибка Загрузка ASPI32.Sys заблокирована из-за несовместимости с данной системой, и что подтверждается не совсем правильным местоположением проблемного драйвера в 64-битной системе по пути %Windir%\SysWOW64\Drivers\ (должно быть %Windir%\System32\Drivers\). Почему драйвер не совместим? Да потому что он 32-разрядный, а система 64-разрядная. Microsoft в этом случае, подняв вверх указательный палец, многозначительно изрекает:

Drivers designed for 32-bit versions of Windows don’t work on computers running 64-bit versions of Windows.

Для того, что бы хоть как-то защитить своё хрупкое божественное творение от полчищ диких пользователей, Microsoft разработал и внедрил в 64-битные системы механизм под названием WOW64. На самом деле этот механизм разработан с целью обеспечения работоспособности 32-битного программного обеспечения в 64-битных операционных системах Windows.

В 64-разрядных системах реализован механизм WOW64 (Windows on Windows64), основной задачей которого является обеспечение совместимости 32-разрядных приложений с 64-разрядной операционной системой. Среди прочего, происходит перенаправление запросов 32-разрядных приложений, обращающихся с файловыми операциями к директории %Windir%\System32 в каталог %Windir%\SysWOW64.

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

Кто инсталлирует драйвер aspi32.sys?

Остановимся на том, что драйвер aspi32.sys является 32-битным и не совместим с 64-разрядной системой. Тогда каким образом он сюда попал, или, другими словами, кто этот драйвер установил в систему? Судя по всему, это произошло в процессе установки устаревшего 32-битного программного пакета, По классу это могло быть ПО, предназначающееся для низкоуровневой работы с некими SCSI/ATAPI-приводами (CD/DVD/BluRay/MO), внешними устройствами (сканнеры, цифровые камеры), например программы для снятия образов/записи CD/DVD. Одним словом, в эру развития оптических носителей существовало такое огромное количество различного программного обеспечения для работы с ними, что перечислять их всех не хватит никакой статьи С другой стороны, ASPI могло использовать любое ПО, реализующее некий тип защиты от копирования, основанный на взаимодействии с ключевой информацией, каким-либо нестандартным образом размещаемой на оптических (магнитных) носителях, например при помощи тех же суб-каналов (Q/P-каналы).
Но всё же, кто инициатор установки этого драйвера? В директории %Windir%\SysWOW64\Drivers\ мне удалось обнаружить еще один интересный объект — драйвер hwtools.sys, дата и время инсталляции которого в точности совпадали с аналогичными параметрами файла aspi32.sys. В свойствах драйвера можно найти наименование HWTools Driver, авторские права принадлежат ООО «СТМ» 2000-2008. На некоторых других подобных станциях в пределах корпоративной среды, мне так же удалось обнаружить подобные «пары» драйверов по тому же местоположению, и во всех случаях дата и время у них совпадали между собой, либо отличались на очень незначительную величину (одна-две секунды), что само по себе уже наводит на мысль об связанной инсталляции в систему единым источником. На основе продвинутого поиска по файловой системе было выяснено, что в указанное время из комплекта программ СТМ на пользовательские станции инсталлировались такие пакеты как Rail-Тариф, Rail-Атлас, Rail-Инфо и некоторые другие, сама установка была датирована 2011 годом. Из всего этого возникло предположение, что интересующий нас драйвер aspi32.sys тоже был установлен программами СТМ.

Выходит у нас прелюбопытнейшая ситуация: в директорию %Windir%\SysWOW64\Drivers\ было инсталлировано два драйвера, при этом aspi32.sys блокируется как несовместимый, а hwtools.sys превосходно инициализируется (что видно из кода возврата 0 на картинке выше). Как подобное возможно? Да запросто, дело в том, что для механизма WOW64 фактически, важна разрядность приложения, которое производит установку драйверов в систему, а не разрядность самого устанавливаемого драйвера. Таким образом, например 32-разрядное приложение может запросто установить в систему и 64-разрядный рабочий драйвер. Поэтому, в каталог %Windir%\SysWOW64\Drivers\ могут попадать и вполне валидные драйвера и без каких-либо проблем оттуда загружаться.

Далее, проверка свежесозданных директорий установленных программ СТМ на предмет наличия описанных файлов показала, что указанные драйвера в них отсутствуют. Но откуда же они тогда берутся? Появилось предположение, для подтверждения которого я использовал утилиту Process Monitor и на чистой ОС провел инсталляцию программ СТМ. Непосредственно после инсталляции драйвера действительно отсутствуют, а вот при выполнении процедуры активации программ мы видим, что драйвер hwtools.sys появляется в нужном месте, при этом добиться создания aspi32.sys мне так и не удалось. Из отчета Procmon мы можем наблюдать, что создание и запись данных файла hwtools.sys (а так же файла hwtools.cat) инициируется основным процессом запускаемой программы СТМ (например, для Rail-Тариф это tariff.exe), впрочем код инсталляции драйвера, как и сами драйвера, могут содержаться не непосредственно в исполняемом модуле, а в подгружаемых в адресное пространство модуля библиотеках DLL. Изучение адресного пространства процесса tariff.exe в момент записи драйвера обнаружило нам целую серию внутренних библиотек программного пакета, среди которых наибольший интерес представляют две из них с именами comtls32.dll и comtls64.dll.

Реализация защиты

Поскольку изучение и публикация структуры защитного механизма лежат вне правового поля, во избежание различного рода инцидентов, мы ограничимся лишь поверхностными набросками относительно внутреннего устройства библиотек. Основной интерес представляет собой библиотека comtls32.dll, поскольку именно она содержит защитные алгоритмы и участвует в процессе регистрации программ. В самой библиотеке, часть секций которой зашифрованы и расшифровывается стартовым кодом процедуры DllEntryPoint, содержатся запакованные в секции файлы wnaspi32.dll, aspi32.sys, hwtools.sys. Там же содержатся код регистрации (проверки активации) программ и код взаимодействия со слоем ASPI и функциями драйвера hwtools.sys. Драйвер hwtools.sys создает системное устройство \\Device\\HwTools, обращение к устройству происходит из уже знакомой нам библиотеки comtls32.dll.

Выводы

Какие из всего этого можно сделать умозаключения? Поскольку мне так и не удалось создать условия, при которых в систему был бы инсталлирован драйвер aspi32.sys, могу сделать предположение, что в далеком 2011 году для установки по ошибке был использован 32-разрядный инсталляционный пакет СТМ, содержащий иной (в отличии от современных версий) механизм защиты, кроме всего прочего, опирающийся на низкоуровневый доступ к периферийным IDE/ATAPI-устройствам (CD/DVD) через внешний ASPI интерфейс. Это могла быть защита на основе специальным образом сформированных CD/DVD-дисков. В последних же версиях программ СТМ, драйвер aspi32.sys в систему не инсталлируется.
Имеется так же предположение, что алгоритм проверки несовместимого драйвера в ядре содержит ошибки, в следствии чего, в исключительных случаях, возникают такие вот немыслимые задержки на этапе инициализации уже загруженного драйвера. Но это лишь предположение, подтвердить или опровергнуть которое еще только предстоит..

Решение

Исходя из всего вышенаписанного, у нас есть два возможных решения проблемы:

1. Найти в системе программное обеспечение, установившее драйвер aspi32.sys и попытаться переустановить/удалить его, в расчете на то, что вместе с ПО обновится/удалится и драйвер;
2. Отключить загрузку проблемного драйвера вручную;

Для «ручного» отключения драйвера используем следующую стратегию:

• Запускаем редактор реестра regedit.exe;
• В реестре находим ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASPI32;
• Меняем значение параметра Start на 4 (отключен);

Тем, кого драйвер aspi32.sys выбесил уже серьезно, можно порекомендовать удалить ключ ASPI32 полностью

Порой случается и такое, что обращаешь внимание на сущую мелочь, безделицу, к изначальному объекту твоего внимания никакого отношения не имеющую. Однако со временем, этот безобидный, на первый взгляд, предмет твоего невольного интереса может запросто превратиться в источник различного рода проблем. Так бывает в жизни и точно таков мир операционных систем, где постоянно изменяющийся код системных компонентов может в какой-то момент кардинально преобразовать ситуацию. Иногда, так сказать по долгу «службы», приходится анализировать системные журналы Windows, представляющие собой один из многочисленных источников информации о состоянии системы. Именно в нем иной раз можно найти записи об уже существующих и даже потенциальных, так сказать предстоящих неисправностях. Так вот, в одной далекой-далекой компании, имя которой не разглашается дабы не скомпрометировать доброе имя и не навредить коммерческим интересам, ну а более в целях создания статейной интриги специалистами было отмечено, что (иногда) при анализе системных журналов встречались любопытные события. Возникавшие с завидной регулярностью, события эти сводились к ошибкам функционирования одного и того же драйвера aspi32.sys, имели коды 7026, 1060, 7000 и содержали следующее описание:

либо такие вот пары событий, следующих друг за другом:

Тем не менее ошибки эти никак внешне себя не проявляли, ну или об этих проявлениях ничего не было известно, поэтому никто этому особого значения и не предавал. Никаких жалоб и замечаний от сотрудников на данных рабочих местах никогда не поступало. Однако, всё течет, всё меняется, и в один прекрасный момент поступило обращение на тему появившейся ни с того, ни с сего, на ровном месте, продолжительной загрузки операционной системы на одной из клиентских рабочих станций. При анализе деталей происшествия было определено, что визуально задержка происходит после появления экрана заставки с логотипом Windows (значок, флажок).

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

Изучение

Поскольку углубиться в проблему можно лишь при использовании специализированных средств, на ум сразу же приходит вариант исследования инцидента при помощи технологию Event Tracking for Windows с применением утилит xbootmgr и xperf из комплекта Windows Performance Tools. После сбора событий (процесс подробно описан в статье по приведенной выше ссылке) и последующего анализа получившихся логов, были локализованы некоторые любопытные моменты. Во-первых, при изучении результирующего графика Boot Phases, открылась следующая картина:

..из которой видно, что фаза Pre Session Init (она же PreSMSS: Kernel Initialization) занимает времени более обычного. Необходимо понимать, что происходит с системой на протяжении всей фазы: одним из основных событий тут является загрузка драйверов с флагом BOOT_START и SYSTEM_START. Соответственно, что бы понять, что именно тормозит на этапе PreSMSS, обратимся к графику Generic Events. Из анализа сводной таблицы (Summary Table) графика, а именно дерева: провайдер: Microsoft-Windows-Kernel-PnP, задача: DriverLoad, я обнаружил вот что:

Очевидно, что драйвер с именем aspi32.sys по какой-то пока что необъяснимой причине пытается инициализироваться в течении 73 (!) секунд. Апофеозом процесса инициализации драйвера является выход с десятичным кодом возврата 3221226347 (шестнадцатеричный эквивалент C000036B), что намекает на NTSTATUS с символическим описанием STATUS_DRIVER_BLOCKED_CRITICAL, фактически указывающим на ошибку инициализации драйвера. Вне зависимости от того, влияет ли это каким-то образом на загрузку остальных драйверов или нет, это ситуация из ряда вон выходящая!!

Что такое ASPI?

Обнаруженный нами драйвер (естественно) сконфигурирован на загрузку в ветке реестра HKLMSYSTEMCurrentControlSetservices и помечен флагом SYSTEM_START (параметр Start = 1). Соответствующий файл драйвера с именем aspi32.sys располагается в директории %Windir%SysWOW64Drivers и судя по ключевому слову ASPI, содержащемуся в названии, явным образом относится к интерфейсу ASPI.

ASPI (акроним Advanced SCSI Programming Interface, Усовершенствованный программный интерфейс SCSI) — программный интерфейс, стандартизирующий взаимодействие между SCSI/ATAPI-контроллером, периферийными устройствами на шинах SCSI/ATAPI и приложениями. Роль интерфейса сводится к абстрагированию от специфических особенностей того или иного хост-адаптера и обеспечению общего, простого программного интерфейса для SCSI/ATAPI-устройств.

В определении важно отметить, что не смотря на явное упоминание SCSI в аббревиатуре, на деле интерфейс ASPI может использоваться не только для взаимодействия с устройствами на шине SCSI, но так же и с IDE/ATAPI-устройствами, поскольку ATAPI практически полностью идентичен SCSI на уровне команд, не зря его называют «SCSI поверх IDE» или «SCSI по ATA-кабелю».
Немного истории. В начале 90х ASPI был разработан компанией Adaptec для обеспечения взаимодействия большого количества не придерживающихся стандарта SCSI-адаптеров, поскольку несмотря на использование единой системы команд, выполнение этих команд адаптеры могли обеспечивать по-разному, в зависимости от собственной специфики. Таким образом ASPI был призван преодолеть разного рода несовместимость всего спектра SCSI-устройств, от устаревших до современных, транслируя данные таким образом, чтобы приложения могли общаться со всеми типами SCSI-устройств и контроллеров. В это время на рынке, помимо SCSI присутствовал и другой стандарт для взаимодействия с дисковыми накопителями называемый ATA(IDE), расширенный чуть позже в ATAPI. В определенный момент в интерфейс ASPI была включена поддержка ATAPI, после чего он стал единой универсальной точкой взаимодействия со SCSI/ATAPI-устройствами, которая существенно облегчала разработчикам драйверов/программ написание «универсального» кода работы с большинством типов существовавших в то время на рынке устройств. Поскольку ASPI начал развиваться задолго до появления Windows, к моменту популяризации операционной системы от Microsoft, он предоставлял собой уже довольно развитой и удобный (с точки зрения программирования) интерфейс. По этой, а так же по ряду других причин интерфейс ASPI на долгое время стал своеобразным стандартом де-факто для работы с внешними накопителями (CD/DVD/Blu-ray), предпочтительным по отношению к встроенным механизмам операционных систем от Microsoft. С поддержкой ASPI было написано большое количество приложений, и именно поэтому слой ASPI так долго просуществовал в виде сторонних реализаций (библиотек/драйверов) во многих операционных системах.

Поддержка ASPI в операционных системах

Но давайте посмотрим как реализована поддержка интерфейса в операционных системах Windows. Во времена Windows 95 никакой похожей на ASPI технологии у разработчиков из Microsoft не было, поэтому предлагаемый Adaptec слой ASPI был лицензирован и интегрирован в систему, в подобном варианте просуществовав вплоть до Windows Millenium. Однако линейка Windows NT/2000/XP, по замыслу разработчиков, изначально была лишена поддержки классического ASPI, вместо него в Microsoft был разработан и внедрен собственный, не совместимый со стандартными вызовами ASPI-функций, минимальный интерфейс ASPI (иначе называемый SCSI Pass Through interface, SPTI). Связано это с тем, что в общем смысле Microsoft всегда преследовал цель избавиться в своих операционных системах от нативной (встроенной) поддержки сторонних технологий, разработанных вне Microsoft, а в частном контексте MS не устраивал уровень безопасности ASPI. Закономерным итогом этой тенденции явилось планомерное вытеснение ASPI более жизнеспособными технологиями, которые опирались на интерфейсы, имеющие встроенную поддержку операционной системы. Фактически после Windows 95/98 Microsoft перевел ASPI в статус внешнего интерфейса, поэтому для инсталляции внешней реализации интерфейса ASPI в операционных системах Windows предписывалось использовать сторонние программные комплекты.
Следовательно, если приложению требовалась поддержка интерфейса ASPI, оно должно самостоятельно позаботиться о ней, установив в систему библиотеки/драйвера посредством инсталляции следующих комплектов:

• Комплект (freeware) Adaptec ASPI;
• Многочисленные «сторонние» пакеты, такие как: ForceASPI, FrogASPI, ASAPI или MekugiASPI;

Подобные вышеописанным комплекты поддержки ASPI устанавливали в систему (как минимум) два файла:

• Библиотека wnaspi32.dll — судя по всему, обеспечивает сопряжение с интерфейсом Win32;
• Драйвер виртуального устройства aspi32.sys — служит для взаимодействия непосредственно с драйверами устройств;

Но, вернемся к теме нашей статьи. Описываемый мною инцидент был зафиксирован под версией Windows 7 Профессиональная x64, и в этой операционной системе мы не обнаруживаем никакой «встроенной» поддержки ASPI. Из этого следует, что драйвер по отношению к Windows 7 считается мало того что «сторонним», но еще и несовместимым, о чем красноречиво говорит нам ошибка Загрузка ASPI32.Sys заблокирована из-за несовместимости с данной системой, и что подтверждается не совсем правильным местоположением проблемного драйвера в 64-битной системе по пути %Windir%SysWOW64Drivers (должно быть %Windir%System32Drivers). Почему драйвер не совместим? Да потому что он 32-разрядный, а система 64-разрядная. Microsoft в этом случае, подняв вверх указательный палец, многозначительно изрекает:

Drivers designed for 32-bit versions of Windows don’t work on computers running 64-bit versions of Windows.

Для того, что бы хоть как-то защитить своё хрупкое божественное творение от полчищ диких пользователей, Microsoft разработал и внедрил в 64-битные системы механизм под названием WOW64. На самом деле этот механизм разработан с целью обеспечения работоспособности 32-битного программного обеспечения в 64-битных операционных системах Windows.

В 64-разрядных системах реализован механизм WOW64 (Windows on Windows64), основной задачей которого является обеспечение совместимости 32-разрядных приложений с 64-разрядной операционной системой. Среди прочего, происходит перенаправление запросов 32-разрядных приложений, обращающихся с файловыми операциями к директории %Windir%System32 в каталог %Windir%SysWOW64.

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

Кто инсталлирует драйвер aspi32.sys?

Остановимся на том, что драйвер aspi32.sys является 32-битным и не совместим с 64-разрядной системой. Тогда каким образом он сюда попал, или, другими словами, кто этот драйвер установил в систему? Судя по всему, это произошло в процессе установки устаревшего 32-битного программного пакета, По классу это могло быть ПО, предназначающееся для низкоуровневой работы с некими SCSI/ATAPI-приводами (CD/DVD/BluRay/MO), внешними устройствами (сканнеры, цифровые камеры), например программы для снятия образов/записи CD/DVD. Одним словом, в эру развития оптических носителей существовало такое огромное количество различного программного обеспечения для работы с ними, что перечислять их всех не хватит никакой статьи С другой стороны, ASPI могло использовать любое ПО, реализующее некий тип защиты от копирования, основанный на взаимодействии с ключевой информацией, каким-либо нестандартным образом размещаемой на оптических (магнитных) носителях, например при помощи тех же суб-каналов (Q/P-каналы).
Но всё же, кто инициатор установки этого драйвера? В директории %Windir%SysWOW64Drivers мне удалось обнаружить еще один интересный объект — драйвер hwtools.sys, дата и время инсталляции которого в точности совпадали с аналогичными параметрами файла aspi32.sys. В свойствах драйвера можно найти наименование HWTools Driver, авторские права принадлежат ООО «СТМ» 2000-2008. На некоторых других подобных станциях в пределах корпоративной среды, мне так же удалось обнаружить подобные «пары» драйверов по тому же местоположению, и во всех случаях дата и время у них совпадали между собой, либо отличались на очень незначительную величину (одна-две секунды), что само по себе уже наводит на мысль об связанной инсталляции в систему единым источником. На основе продвинутого поиска по файловой системе было выяснено, что в указанное время из комплекта программ СТМ на пользовательские станции инсталлировались такие пакеты как Rail-Тариф, Rail-Атлас, Rail-Инфо и некоторые другие, сама установка была датирована 2011 годом. Из всего этого возникло предположение, что интересующий нас драйвер aspi32.sys тоже был установлен программами СТМ.

Выходит у нас прелюбопытнейшая ситуация: в директорию %Windir%SysWOW64Drivers было инсталлировано два драйвера, при этом aspi32.sys блокируется как несовместимый, а hwtools.sys превосходно инициализируется (что видно из кода возврата 0 на картинке выше). Как подобное возможно? Да запросто, дело в том, что для механизма WOW64 фактически, важна разрядность приложения, которое производит установку драйверов в систему, а не разрядность самого устанавливаемого драйвера. Таким образом, например 32-разрядное приложение может запросто установить в систему и 64-разрядный рабочий драйвер. Поэтому, в каталог %Windir%SysWOW64Drivers могут попадать и вполне валидные драйвера и без каких-либо проблем оттуда загружаться.

Далее, проверка свежесозданных директорий установленных программ СТМ на предмет наличия описанных файлов показала, что указанные драйвера в них отсутствуют. Но откуда же они тогда берутся? Появилось предположение, для подтверждения которого я использовал утилиту Process Monitor и на чистой ОС провел инсталляцию программ СТМ. Непосредственно после инсталляции драйвера действительно отсутствуют, а вот при выполнении процедуры активации программ мы видим, что драйвер hwtools.sys появляется в нужном месте, при этом добиться создания aspi32.sys мне так и не удалось. Из отчета Procmon мы можем наблюдать, что создание и запись данных файла hwtools.sys (а так же файла hwtools.cat) инициируется основным процессом запускаемой программы СТМ (например, для Rail-Тариф это tariff.exe), впрочем код инсталляции драйвера, как и сами драйвера, могут содержаться не непосредственно в исполняемом модуле, а в подгружаемых в адресное пространство модуля библиотеках DLL. Изучение адресного пространства процесса tariff.exe в момент записи драйвера обнаружило нам целую серию внутренних библиотек программного пакета, среди которых наибольший интерес представляют две из них с именами comtls32.dll и comtls64.dll.

Реализация защиты

Поскольку изучение и публикация структуры защитного механизма лежат вне правового поля, во избежание различного рода инцидентов, мы ограничимся лишь поверхностными набросками относительно внутреннего устройства библиотек. Основной интерес представляет собой библиотека comtls32.dll, поскольку именно она содержит защитные алгоритмы и участвует в процессе регистрации программ. В самой библиотеке, часть секций которой зашифрованы и расшифровывается стартовым кодом процедуры DllEntryPoint, содержатся запакованные в секции файлы wnaspi32.dll, aspi32.sys, hwtools.sys. Там же содержатся код регистрации (проверки активации) программ и код взаимодействия со слоем ASPI и функциями драйвера hwtools.sys. Драйвер hwtools.sys создает системное устройство \Device\HwTools, обращение к устройству происходит из уже знакомой нам библиотеки comtls32.dll.

Выводы

Какие из всего этого можно сделать умозаключения? Поскольку мне так и не удалось создать условия, при которых в систему был бы инсталлирован драйвер aspi32.sys, могу сделать предположение, что в далеком 2011 году для установки по ошибке был использован 32-разрядный инсталляционный пакет СТМ, содержащий иной (в отличии от современных версий) механизм защиты, кроме всего прочего, опирающийся на низкоуровневый доступ к периферийным IDE/ATAPI-устройствам (CD/DVD) через внешний ASPI интерфейс. Это могла быть защита на основе специальным образом сформированных CD/DVD-дисков. В последних же версиях программ СТМ, драйвер aspi32.sys в систему не инсталлируется.
Имеется так же предположение, что алгоритм проверки несовместимого драйвера в ядре содержит ошибки, в следствии чего, в исключительных случаях, возникают такие вот немыслимые задержки на этапе инициализации уже загруженного драйвера. Но это лишь предположение, подтвердить или опровергнуть которое еще только предстоит..

Решение

Исходя из всего вышенаписанного, у нас есть два возможных решения проблемы:

1. Найти в системе программное обеспечение, установившее драйвер aspi32.sys и попытаться переустановить/удалить его, в расчете на то, что вместе с ПО обновится/удалится и драйвер;
2. Отключить загрузку проблемного драйвера вручную;

Для «ручного» отключения драйвера используем следующую стратегию:

• Запускаем редактор реестра regedit.exe;
• В реестре находим ключ HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesASPI32;
• Меняем значение параметра Start на 4 (отключен);

Тем, кого драйвер aspi32.sys выбесил уже серьезно, можно порекомендовать удалить ключ ASPI32 полностью

ACPI.sys – это файл операционной системы Windows, связанный с MSDN 2939. Драйвер ACPI для Windows, Acpi.sys, является компонентом входящих сообщений операционной системы Windows. В обязанности Acpi.sys входит поддержка управления питанием и перечисления устройств Plug and Play (PnP). Известно, что этот файл, если он поврежден, вызывает ошибку “синий экран”. Другие причины включают конфликты, такие как ОЗУ, проблемы с жестким диском, несовместимые микропрограммы, поврежденные драйверы или заражение вредоносным ПО, и т. Д. Существуют некоторые возможные исправления и обходные пути, которые мы рассмотрим сегодня.

Могут быть следующие ошибки BSOD, связанные с этим файлом:

• KMODE ИСКЛЮЧЕНИЕ НЕ ОБРАБОТАНО.
• НЕИСПРАВНОСТЬ СТРАНИЦЫ В НЕПРЕРЫВНОЙ ОБЛАСТИ.
• СИСТЕМНАЯ РЕЗЬБА ИСКЛЮЧЕНИЯ НЕ ОБРАБОТАНА.
• IRQL НЕ МЕНЬШЕ ИЛИ РАВЕН.
• СТРАНИЦА ДАННЫХ ЯДРА.
• ИСКЛЮЧЕНИЕ ОБСЛУЖИВАНИЯ СИСТЕМЫ.

Ошибка синего экрана ACPI.sys

Ниже приведены возможные исправления ошибки «синий экран», вызванной ACPI.sys.

1. Обновите или откатите драйвер ACPI
2. Использовать проверку системных файлов
3. Используйте Восстановление системы.

1] Обновите или откатите драйвер ACPI

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

Из меню WinX откройте диспетчер устройств. Выберите драйвер ACPI.sys и откройте Свойства правой кнопкой мыши. Затем перейдите в раздел «Драйвер». Откат доступен только в том случае, если обновление было последним. Если это не так, нажмите «Обновить драйвер», и Windows автоматически проверит наличие проблем.

Если это не помогает, вы можете скопировать файл системного драйвера ACPI.sys из папки System32 другого хорошего компьютера с той же версией ОС Windows и поместить его в проблемную систему и посмотреть, поможет ли это.

2] Запустите проверку системных файлов

Вы можете запустить проверку системных файлов и посмотреть, поможет ли это вам.

 sfc/scannow 

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

Вы также можете использовать наше бесплатное FixWin для запуска утилиты проверки системных файлов одним щелчком мыши.

3] Использование восстановления системы

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

Если вы находитесь в разделе «Дополнительные параметры запуска», вы можете напрямую выбрать «Восстановление системы» и продолжить выполнение шагов. Если вы только что загрузились в безопасном режиме, запустите sysdm.cpl , используя поле поиска

Выберите вкладку с надписью Защита системы , а затем нажмите кнопку Восстановление системы .

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

Теперь перезагрузите компьютер и проверьте, смог ли этот метод решить вашу проблему.

Всего наилучшего!

Что такое Acpi.sys?

Acpi.sys представляет собой разновидность файла SYS, связанного с MSDN 2939, который разработан Microsoft для ОС Windows. Последняя известная версия Acpi.sys: 1.0.0.0, разработана для Windows. Данный файл SYS имеет рейтинг популярности 2 звезд и рейтинг безопасности «Неизвестно».

Что из себя представляют файлы SYS?

Файлы SYS, такие как acpi.sys – это сторонние (например, Microsoft) драйверы устройств или важные системные файлы, которые поставляются как часть операционной системы Windows. Большинство файлов SYS позволяет внутреннему оборудованию ПК или подключенному оборудованию, например, принтеру, взаимодействовать со сторонними программами (например, с веб-браузерами, текстовыми процессорами, MSDN 2939) и операционной системой (например, Windows).

Другие файлы SYS – это важные системные файлы, называемые «драйверы устройств режима ядра», которые используются для работы операционной системы Windows. Такие файлы, как «CONFIG.SYS», содержат содержат параметры конфигурации и указывают, какие драйверы устройств должны загружаться операционной системой. Без файлов драйверов, таких как acpi.sys, вы бы не могли выполнять такие простые задачи, как печать документа.

Почему у меня наблюдаются ошибки в файлах типа SYS?

Ошибки файла SYS обычно вызваны неисправностями оборудования или повреждениями файлов драйверов устройств. Ввиду важности Acpi.sys в работе MSDN 2939 и других функций Windows, любое повреждение этого файла может привести к критическим системным ошибкам в форме «синего экрана смерти» (BSOD). Для получения дополнительной информации см. «Причины ошибок Acpi.sys» ниже.

В каких случаях появляются ошибки в файлах типа SYS?

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

Распространенные сообщения об ошибках в Acpi.sys

Большинство ошибок %% knowledgebase_file_name%%, с которыми вам придется столкнуться, связано с ошибками типа «синий экран» (также известными как «BSOD» или «ошибка ОСТАНОВКИ»), которые появляются в Windows XP, Vista, 7 и 8:

• «Была обнаружена проблема, и Windows была выгружена, чтобы предотвратить повреждения компьютера. Очевидно, проблема вызвана следующим файлом: Acpi.sys.»
• «:( Ваш компьютер столкнулся с проблемой и нуждается в перезагрузке. Мы соберем необходимую информацию и осуществим перезагрузку. Если вам нужна дополнительная информация, вы можете позже поискать в Интернете по названию ошибки: acpi.sys.»
• «STOP 0x0000000A: IRQL_NOT_LESS_EQUAL – acpi.sys»
• «STOP 0x0000001E: KMODE_EXCEPTION_NOT_HANDLED – acpi.sys»
• «STOP 0×00000050: PAGE_FAULT_IN_NONPAGED_AREA – acpi.sys»

В большинстве случаев вы сталкиваетесь в ошибками типа «синий экран» acpi.sys после установки нового аппаратного или программного обеспечения. Синие экраны acpi.sys могут появляться при установке программы, если запущена программа, связанная с acpi.sys (например, MSDN 2939), когда загружается драйвер Microsoft или во время запуска или завершения работы Windows. Отслеживание момента появления ошибки ОСТАНОВКИ является важной информацией при устранении проблемы.

Причины ошибок в файле Acpi.sys

Ошибки типа «синий экран» файла Acpi.sys могут быть вызваны множеством проблем аппаратного обеспечения, прошивки, драйвера или программного обеспечения. Они, в свою очередь, могут быть связаны либо с программным обеспечением MSDN 2939, либо с аппаратным обеспечением Microsoft, но это не всегда так.

Более конкретно, данные ошибки acpi.sys могут быть вызваны следующими причинами:

• Неправильно сконфигурированные, старые или поврежденные драйверы устройства MSDN 2939 (очень часто).
• Повреждение реестра Windows из-за недавнего изменения программного обеспечения (установка или удаление), связанного с acpi.sys.
• Вирус или вредоносное ПО, которые повредили файл acpi.sys или связанные с MSDN 2939 программные файлы.
• Конфликт оборудования после установки нового оборудования Microsoft, или оборудования, связанного с acpi.sys.
• Поврежденные или удаленные системные файлы после установки программного обеспечения или драйверов, связанных с MSDN 2939.
• Синий экран acpi.sys вызван повреждениями жесткого диска.
• Ошибка остановки файла acpi.sys в связи с повреждением оперативной памяти (RAM).

Звоните или оставляйте заявку прямо на сайте! Наши специалисты с удовольствием помогут Вам!

> Support > Windows® 10  >  aspi32.sys Errors

Download certified for Windows® 

Windows Help Center

Trademarks: Microsoft, Windows and the Windows logos are trademarks of Microsoft. and the logos are trademarks of the corporation. Disclaimer: pcsystemfix.com is not affiliated with any hardware manufacturer or Microsoft, nor claims direct affiliation. The information on this page is provided for informational purposes only.

© PCSystemFix.com

Download

How to Repair aspi32.sys Errors 

Recommended: To repair aspi32.sys errors, use this software package; Advanced System Repair. This repair tool has been proven to identify and fix these file errors and other Windows problems with very high efficiency.

aspi32.sys errors and other critical malfunctions can arise when the Windows operating system becomes overloaded with invalid system references, corrupted or missing registry files, malware and outdated device drivers. These problems commonly occur due to a lack of regular PC maintenance. As a computer operating system gets older, errors and crashes start to become more frequent and problematic.

Our recommended solution is to download and install the aspi32.sys Errors Repair Tool. This tool has been designed to diagnose and repair various Windows issues while simultaneously increasing system performance, optimizing memory, improving security and fine tuning your PC for maximum reliability.

What causes errors and performance problems? Windows errors can occur for a number of reasons, including programs not installing or uninstalling properly, malware, system conflicts, Active X errors, and the most common, registry errors. PC registry errors occur over time due to the constant writing, editing and deleting of information from your computer’s registry over time as programs are installed, modified and removed.

Over time, conflicts and errors can occur due to a buildup of unnecessary registry entries as well as partially deleted and incorrect information. Many malware and spyware programs can also cause unwanted changes to your PC registry, which leads to the errors and reduced PC performance you are likely experiencing. In some cases, registry errors can be occurring without you noticing. They are still harmful and should be fixed regularly.

We recommend downloading Advanced System Repair to optimize your PC’s performance and stability. This repair tool has been proven to identify and fix ActiveX and Windows registry errors, delete junk files, temporary files and processes, decrease startup times, restore lost memory on your hard drive, protect confidential information, open unknown files, defrag your PC, remove malware and other various errors. This utility makes your computer run smoothly and at its maximum potential.

Step 1: Click here to download Advanced System Repair
Step 2: Install and launch the application
Step 3: Click the Scan Now button to detect errors and abnormalities
Step 4: Click the Repair All button to fix the errors

•Only your system and hardware are evaluated.

•100% safe as confirmed by Norton.