Windows setup api что это за процесс

Windows Setup API грузит процессор при включении ПК Windows 10 Pro x64 — как исправить?

Здравствуйте, помогите пожалуйста, что это?

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

В то же время на моих 2 (более новых) ноутбуках и 2 моих других (старых) ПК такого нет.

Ровно через 8 минут 40 секунд, по таймеру диспетчера задач компьютера, это действие полностью исчезает.

Абсолютно все компьютеры с Windows 10 обновлены с Windows 8.1 со всеми сохраненными данными.

Все полностью авторизовано! Заранее спасибо за помощь.

Выполните чистую загрузку: (запускайте аналогично W8)

Щелкните правой кнопкой мыши по кнопке «ПУСК» — в открывшемся меню — щелкните по командной строке (администратор)

Выполните следующие команды в командной строке (администратор):

Выполните команды одну за другой.

dISM / онлайн / очистка-изображение / scanhealth

dISM / онлайн / очистка-образ / Restorehealth

Источник

Статья SetupAPI – информация об устройствах

Перед любым системным программистом, рано или поздно встаёт задача определения текущего оборудования системы. Причин для этого может быть много, например: установить драйвер на девайс, собрать лог всех устройств для последующей работы с ними и т.п. Если мы не будем готовы к таким поворотам судьбы, то придётся переобуваться в воздухе (на скорую руку штудируя доки), в результате чего на выходе получим как-минимум кривой софт.

Да. в штатной поставке Windows имеется оснастка WMI Control – Windows Management Instrumentation (инструментарий управления Win), которая прекрасно решает проблемы данного характера. Однако вызывать сторонние сервисы и приложения из своих программ слишком накладно по времени, и наше приложение будет жутко тормозить. Личные опыты показали, что одну и ту-же задачу WMI решает аж в 60 раз медленнее, чем если этот-же функционал реализовать прямым вызовом системных функций WinAPI – аргумент явно не в пользу WMI, хотя данная оснастка и требует от нас меньших телодвижений.

Основное назначение библиотеки setupapi.dll – это установка драйверов устройств и законченная их регистрация в системном реестре. Данная библиотека состоит из двух самостоятельных модулей:

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

Знакомство с классами устройств, и их идентификаторами GUID

Современная архитектура компьютерных систем имеет огромное количество устройств, и только часть из них внешние. К внешним относятся жёсткий диск, клавиатура, мышь, модем, монитор и прочая ботва, с которой нас знакомили на уроках информатики. Однако внутри чипсета материнской платы зарыты внутренние устройства – это различного рода шины, таймеры, контролёры, мосты и много другое. Более того, в системе могут присутствуют одинаковые по типу, но разные по назначению устройства, а значит их нужно как-то фильтровать.

Таким образом, все устройства в системе (будь-то внешние или внутренние) разделяются на классы, например: класс шины PCI, класс USB, видео-класс, класс принтеров, модемов, клавиатуры и т.д. В системе, буквально любое устройство обязательно принадлежит к какому-нибудь классу. Каждый класс устройств идентифицируется своим GUID«ом (глобальный уникальный идентификатор), который представляет из-себя 16-байтную (128 битную) запись вида: <50127dc3-0f36-415e-a6cc-4cb3be910b65>. Схематически это можно представить так:

Информационной базой всех устройств является системный реестр, где для каждого класса-устройств выделена своя ветвь. Все классы собраны в разделе реестра HKLMSYSTEMCurrentControlSetControlClass. В этой папке мы найдём зарегистрированные когда-либо в системе GUID’ы и даже тех классов, привязанных устройств к которым в текущий момент может и не быть. Например подключили мы к компьютеру месяц назад камеру, а потом убрали её за ненадобность. Это нужно учитывать при сканировании устройств, выставляя флаг DIGCF_PRESENT=2 (только активные девайсы).

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

Забегая вперёд скажу, что для каждого из найденных устройств, функция SetupDiGetDeviceRegistryProperty() как пылесос может вытянуть до 37-ми его характеристик – именно такое количество SPDRP-флагов мы можем передавать ей в аргументе. Как-говорится – хоть лопатой греби..

В талмуде мелкомягких, глобальный идентификатор GUID описывается вполне легальной структурой. Например на рисунке выше, GUID характеризует класс USB-устройств и имеет значение: <36fc9e60-c465-11cf-8056444553540000>. Если копнуть доки, то можно найти значения GUID всех (само)настраивающихся устройств PnP – в представлении ассемблера каждая запись выглядит так, и я собрав их в инклуде setupapi.inc, прикрепил его в скрепке (в штатной поставке fasm’a их нет):

Основные API-функции для сбора информации

Будем считать, что с теорией разобрались – перейдём к практической части..
Из указанных 600-функций библиотеки setupapi.dll мы будем использовать всего 6-7. Эти функции позволят нам выжать достаточно информации от первого свидания с этой либой. В качестве демонстрации напишем приложение, которое перечислит все идентификаторы GUID системы и отобразит в читабельном виде, какому именно классу принадлежит тот-или-иной GUID. Здесь в окопах нас поджидают некоторые нюансы – разберём их в кратце..

1. В цикле обходит все классы и возвращает нам их GUID’ы функция CM_Enumerate_Classes() с таким прототипом:

Если коротко, то нам нужно организовать цикл и на каждой его итерации, начиная с нуля увеличивать индекс класса. Эта функция BOOL, так-что если она вернёт EAX=1, значит мы обошли всю базу и пора из цикла выходить. Второй аргумент – это указатель на 16 байтный буфер, в который функция будет сбрасывать GUID текущего индекса. Третий аргумент не используется и должен быть установлен в нуль.

Эта функция сбрасывает в буфер GUID в виде Unicode-строки, значит для вывода на консоль её нужно будет преобразовать в Ascii. Для этого будем просто читать по 2-байта, и перезаписывать в тот-же буфер по одному байту (т.е. отсекать парные нули). Вот как выглядит эта информация в секции-данных программы, после того-как функция StringFromGUID2() отработает:

4. Можно прикрутить в исходник код профилировщика, чтобы лицезреть время, потраченное программой на реализацию задуманного. Мы просто на входе в основную процедуру запомним текущие тики системного таймера функцией GetTickCount() , а на выходе из процедуры запросим их опять, и вычислим разницу. Так мы получим хоть какой-то метроном, который отстучит нам потраченное на исполнение кода время. Теме профайлеров мы посвятим отдельную статью, а пока будем довольствоваться этим алго времён динозавров.

Теперь, законченная реализация кода для вывода имени-класса по его GUID может выглядеть примерно так:

Что мы тут имеем? Значит всего классов-устройств в системе равно 60, и соответственно столько-же идентификаторов GUID. Пусть вас не смущает время выполнение данного кода 560 миллисекунд – это тестировалось на виртуальной машине VirtualBox, скорость которой можно сравнить с активностью уставшей улитки. К примеру на скрине ниже я запустил этот-же кодес на реальном процессоре под хр, так хрюша пробежала эту дистанцию всего за 32 мс – как говорится, почувствуйте разницу: 560/32=17.5 раз быстрее:

Перечисляем все, или принадлежащие только к одному классу устройства

1. SetupDiGetClassDevs() – возвращает дескриптор инфо-базы по GUID-класса (см.рис.2), или нуль в случае ошибки. На входе принимает 4 аргумента, первые-три из которых опциональны и могут быть равны нулю (в этом случае фильтр отключается и сканируются все устройства). В природе, на все случаи жизни имеются три распространённых шаблона аргументов этой функции, которые закоментированы в исходнике ниже – это шаблон для всех устройств, фильтр по текстовой маске (возможные варианты: USB/PCI/PCMCIA/SCSI), и фильтрация устройств по классу GUID.

2. SetupDiEnumDeviceInfo() – заполняет структуру SP_DEVINFO_DATA, которая описывает конкретный элемент в классе-устройств. Больше эта функция ничего не делает. Позже, мы должны будем передать указатель на эту структуру третьей функции в этой тусовке, чтобы она черпала с неё информацию. Для перечисления всего списка-устройств указанного класса, нужно поместить данную функцию в цикл, каждый раз увеличивая значение индекса на 1. Эта функция BOOL и возвращает EAX=0 при ошибке (последний элемент в списке):

3. SetupDiGetDeviceRegistryProperty() – последняя, довольно творческая единица и делает всю черновую работу. Именно эта функция лезет в системный реестр, заполняя наш приёмный буфер нарытими данными. Для начала посмотрим на её аргументы, а потом разберёмся с деталями:

Здесь мы рассмотрели всего 1% из имеющихся 600 функций в библиотеки setupapi.dll. За бортом осталась довольно могучая SetupDiGetDeviceInterfaceDetail() и многие другие. Однако когда-нибудь нужно сделать первый шаг к покорению этой вершины, что открывает богатые возможности для программирования железа из пользовательского режима. Кстати MSDN хорошо раскрывает эту тему и содержит много полезных материалов – учите и вам обязательно зачтётся.

Под занавес статьи, хочу привести пример bat-файла, который поможет вам искать различные константы в огромном море сишных (и не только) инклуд. Он универсальный и ищет текст по указанной маске, рекурсивно обходя все папки и файлы на жёстком диске. Просто кидаете его в корневую папку и подставляете текст для поиска в аргумент команды FINDSTR между двумя прямыми слэшами. Пошурша некоторое время блинами диска, батник вернём вам директории и имена файлов, где имеется указанный текст – очень удобно (для отображения кириллицы, сохраните его в кодировке OEM-866):

Источник

Windows setup api что это за процесс

Проверить файл setupapi.dll

Описание setupapi.dll

setupapi.dll

. был замечен в директориях

. вот такого размера

. и таким копирайтом

Что такое AdminService.exe? Это безопасно или вирус? Как удалить или исправить это

Что такое AdminService.exe?

AdminService.exe это исполняемый файл, который является частью Bluetooth Win7 Suite Программа, разработанная Atheros Communications, Программное обеспечение обычно о 14.95 MB по размеру.

AdminService.exe безопасно, или это вирус или вредоносная программа?

Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как AdminService.exe, должен запускаться из C: Program Files Bluetooth Suite AdminService.exe, а не где-либо еще.

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

Наиболее важные факты о AdminService.exe:

Если у вас возникли какие-либо трудности с этим исполняемым файлом, вы должны определить, заслуживает ли он доверия, прежде чем удалять AdminService.exe. Для этого найдите этот процесс в диспетчере задач.

Найдите его местоположение (оно должно быть в C: Program Files Bluetooth Suite ) и сравните его размер с приведенными выше фактами.

Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус AdminService.exe, необходимо Загрузите и установите приложение полной безопасности, например Malwarebytes., Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.

Могу ли я удалить или удалить AdminService.exe?

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

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

Наиболее распространенные ошибки AdminService.exe, которые могут возникнуть:

• «Ошибка приложения AdminService.exe».
• «Ошибка AdminService.exe».
• «AdminService.exe столкнулся с проблемой и должен быть закрыт. Приносим извинения за неудобства».
• «AdminService.exe не является допустимым приложением Win32».
• «AdminService.exe не запущен».
• «AdminService.exe не найден».
• «Не удается найти AdminService.exe».
• «Ошибка запуска программы: AdminService.exe».
• «Неверный путь к приложению: AdminService.exe».

Как исправить AdminService.exe

Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.

Чтобы помочь вам проанализировать процесс AdminService.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.

Обновлено апреля 2021 года:

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

Загрузите или переустановите AdminService.exe

Вход в музей Мадам Тюссо не рекомендуется загружать заменяемые exe-файлы с любых сайтов загрузки, так как они могут содержать вирусы и т. д. Если вам нужно скачать или переустановить AdminService.exe, мы рекомендуем переустановить основное приложение, связанное с ним. Bluetooth Win7 Suite.

Информация об операционной системе

Ошибки AdminService.exe могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:

Что такое Windows API

Интерфейс прикладного программирования WindowsAPI (applicationprogramminginterface) является интерфейсом системного программирования в пользовательском режиме для семейства операционных систем Windows. До выхода 64-разрядных версий Windows программный интерфейс для 32-разрядных версий операционных систем Windows назывался Win32 API, чтобы его можно было отличить от исходной 16-разрядной версии Windows API (которая служила интерфейсом программирования для начальных 16-разрядных версий Windows).

Windows API состоит из нескольких тысяч вызываемых функций, которые разбиты на следующие основные категории:

Описание WindowsAPI можно найти в документации по набору инструментальных средств разработки программного обеспечения — WindowsSoftwareDevelopmentKit (SDK). Эта документация доступна на веб-сайте www.msdn.microsoft.com. Она также включена со всеми уровнями подписки в сеть MicrosoftDeveloperNetwork (MSDN), предназначенную для разработчиков.

Службы, функции и стандартные программы.

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

История Win32 API.

Интересно, что Win32 не планировался в качестве исходного интерфейса программирования для той системы, которая в ту пору называлась Windows NT. Поскольку проект Windows NT запускался в качестве замены для OS/2 версии 2, первоначальным интерфейсом программирования был 32-разрядный OS/2 PresentationManagerAPI. Но через год после запуска проекта произошел взлет поступившей в продажу Microsoft Windows 3.0. В результате этого Microsoft сменила направление и сделала Windows NT будущей заменой семейства продуктов Windows, а не заменой OS/2. В связи с этим и возникла необходимость выработать спецификацию Windows API — до этого, в Windows 3.0, API существовал только в виде 16-разрядного интерфейса.

Хотя в Windows API намечалось введение множества новых функций, недоступных в Windows 3.1, Microsoft решила сделать новый API, по возможности, максимально совместимым по именам, семантике и используемым типам данных с 16-разрядным Windows API, чтобы облегчить бремя переноса существующих 16-разрядных Windows-приложений в Windows NT. Этим, собственно, и объясняется тот факт, что многие имена функций и интерфейсов могут показаться непоследовательными: так нужно было для обеспечения совместимости нового Windows API со старым 16-разрядным Windows API.

Windows setup api что это

Windows API (англ. application programming interfaces ) — общее наименование набора базовых функций интерфейсов программирования приложений операционных систем семейств Microsoft Windows корпорации «Майкрософт». Предоставляет прямой способ взаимодействия приложений пользователя с операционной системой Windows. Для создания программ, использующих Windows API, корпорация «Майкрософт» выпускает комплект разработчика программного обеспечения, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств для разработки.

Содержание

Общие сведения [ править | править код ]

Windows API спроектирован для использования в языке Си для написания прикладных программ, предназначенных для работы под управлением операционной системы MS Windows. Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. В то же время конвенция вызова функций отличается от cdecl, принятой для языка C: Windows API использует stdcall (winapi). Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие.

Для облегчения переноса на другие платформы программ, написанных с опорой на Windows API, сделана библиотека Wine.

Персональные инструменты

Содержание

Общие сведения

Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие. Эти функции в свою очередь могут быть разбиты на следующие основные категории:

История Microsoft API

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

Обзор

Функции, предоставляемые Windows API, могут быть представлены следующим образом:

Взаимодействие программ

Версии Windows API

Почти каждая новая версия Microsoft Windows представила свои собственные дополнения и изменения в Windows API.

Microsoft также предоставляет несколько интерфейсов API для кодирования медиа и воспроизведения:

Со вчерашнего дня, господа, можно написать вот такой скрипт:

и, запустив его в Windows, получить желаемый результат — диалоговое окно Windows.

Это стало возможным потому, что модуль (обёртку вокруг той необыкновенно полезной библиотеки которая используется для вызова библиотек на языке Си не менее чем других языках) вчера портировали на Windows.

Следует, разумеется, помнить о том, что в Windows API используются строки в формате а джаваскриптовые строки Node.js хранит Воплощением этой разницы является в моём примере преобразователь аналог одноимённого макро, описанного

Ясное дело, что на Windows API свет клином не сошёлся: модуль можно использовать для вызова какой угодно библиотеки, написанной на языке Си или соблюдающей принятый в Си способ вызова функций (например, в Си++ это достигается директивою

Что означает этот шаг эволюции возможностей Node.js?

Напомню предсказание, сделанное мною меньше месяца назад — шестнадцатого декабря 2011 года:

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

И месяца не прошло, как второй из этих трёх пунктов реализовался. Любая библиотека может быть оскриптована джаваскриптами. Соответственно, приложениям на Node.js под Windows стала доступна вся мощь системных API, а кросс-платформенные приложения могут невозбранно обращаться ко кросс-платформенным библиотекам, таская их с собою.

Первый из этих трёх пунктов (касавшийся как раз таскания библиотек с собою) не реализовался в том виде, в каком я мечтал о нём: пакетный менеджер npm всё ещё не обеспечивает возможность доставки только того скомпилированного кода, который нужен конкретной системе. Но у меня появился новый повод для оптимизма после того, как я увидел, что разработчикам модуля удалось обойти нехватку такой возможности. Их модуль содержит один и тот же код, скомпилированный под полдесятка различных платформ:
а скрипт lib/bindings.js во время вызова модуля оглядывается, соображая, куда же попал он, и подбирает нужный двоичный код:

Как видно, работает ничуть не хуже; папка «compiled» вот только занимает ≈700 килобайтов, но при нынешних объёмах дисков и скоростях сетей об этом можно позабыть.

Статья SetupAPI – информация об устройствах

Перед любым системным программистом, рано или поздно встаёт задача определения текущего оборудования системы. Причин для этого может быть много, например: установить драйвер на девайс, собрать лог всех устройств для последующей работы с ними и т.п. Если мы не будем готовы к таким поворотам судьбы, то придётся переобуваться в воздухе (на скорую руку штудируя доки), в результате чего на выходе получим как-минимум кривой софт.

Да. в штатной поставке Windows имеется оснастка WMI Control – Windows Management Instrumentation (инструментарий управления Win), которая прекрасно решает проблемы данного характера. Однако вызывать сторонние сервисы и приложения из своих программ слишком накладно по времени, и наше приложение будет жутко тормозить. Личные опыты показали, что одну и ту-же задачу WMI решает аж в 60 раз медленнее, чем если этот-же функционал реализовать прямым вызовом системных функций WinAPI – аргумент явно не в пользу WMI, хотя данная оснастка и требует от нас меньших телодвижений.

Основное назначение библиотеки setupapi.dll – это установка драйверов устройств и законченная их регистрация в системном реестре. Данная библиотека состоит из двух самостоятельных модулей:

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

Знакомство с классами устройств, и их идентификаторами GUID

Современная архитектура компьютерных систем имеет огромное количество устройств, и только часть из них внешние. К внешним относятся жёсткий диск, клавиатура, мышь, модем, монитор и прочая ботва, с которой нас знакомили на уроках информатики. Однако внутри чипсета материнской платы зарыты внутренние устройства – это различного рода шины, таймеры, контролёры, мосты и много другое. Более того, в системе могут присутствуют одинаковые по типу, но разные по назначению устройства, а значит их нужно как-то фильтровать.

Информационной базой всех устройств является системный реестр, где для каждого класса-устройств выделена своя ветвь. Все классы собраны в разделе реестра HKLMSYSTEMCurrentControlSetControlClass. В этой папке мы найдём зарегистрированные когда-либо в системе GUID’ы и даже тех классов, привязанных устройств к которым в текущий момент может и не быть. Например подключили мы к компьютеру месяц назад камеру, а потом убрали её за ненадобность. Это нужно учитывать при сканировании устройств, выставляя флаг DIGCF_PRESENT=2 (только активные девайсы).

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

Забегая вперёд скажу, что для каждого из найденных устройств, функция SetupDiGetDeviceRegistryProperty() как пылесос может вытянуть до 37-ми его характеристик – именно такое количество SPDRP-флагов мы можем передавать ей в аргументе. Как-говорится – хоть лопатой греби..

Основные API-функции для сбора информации

Будем считать, что с теорией разобрались – перейдём к практической части..
Из указанных 600-функций библиотеки setupapi.dll мы будем использовать всего 6-7. Эти функции позволят нам выжать достаточно информации от первого свидания с этой либой. В качестве демонстрации напишем приложение, которое перечислит все идентификаторы GUID системы и отобразит в читабельном виде, какому именно классу принадлежит тот-или-иной GUID. Здесь в окопах нас поджидают некоторые нюансы – разберём их в кратце..

1. В цикле обходит все классы и возвращает нам их GUID’ы функция CM_Enumerate_Classes() с таким прототипом:

Если коротко, то нам нужно организовать цикл и на каждой его итерации, начиная с нуля увеличивать индекс класса. Эта функция BOOL, так-что если она вернёт EAX=1, значит мы обошли всю базу и пора из цикла выходить. Второй аргумент – это указатель на 16 байтный буфер, в который функция будет сбрасывать GUID текущего индекса. Третий аргумент не используется и должен быть установлен в нуль.

Эта функция сбрасывает в буфер GUID в виде Unicode-строки, значит для вывода на консоль её нужно будет преобразовать в Ascii. Для этого будем просто читать по 2-байта, и перезаписывать в тот-же буфер по одному байту (т.е. отсекать парные нули). Вот как выглядит эта информация в секции-данных программы, после того-как функция StringFromGUID2() отработает:

4. Можно прикрутить в исходник код профилировщика, чтобы лицезреть время, потраченное программой на реализацию задуманного. Мы просто на входе в основную процедуру запомним текущие тики системного таймера функцией GetTickCount() , а на выходе из процедуры запросим их опять, и вычислим разницу. Так мы получим хоть какой-то метроном, который отстучит нам потраченное на исполнение кода время. Теме профайлеров мы посвятим отдельную статью, а пока будем довольствоваться этим алго времён динозавров.

Теперь, законченная реализация кода для вывода имени-класса по его GUID может выглядеть примерно так:

Что мы тут имеем? Значит всего классов-устройств в системе равно 60, и соответственно столько-же идентификаторов GUID. Пусть вас не смущает время выполнение данного кода 560 миллисекунд – это тестировалось на виртуальной машине VirtualBox, скорость которой можно сравнить с активностью уставшей улитки. К примеру на скрине ниже я запустил этот-же кодес на реальном процессоре под хр, так хрюша пробежала эту дистанцию всего за 32 мс – как говорится, почувствуйте разницу: 560/32=17.5 раз быстрее:

Перечисляем все, или принадлежащие только к одному классу устройства

1. SetupDiGetClassDevs() – возвращает дескриптор инфо-базы по GUID-класса (см.рис.2), или нуль в случае ошибки. На входе принимает 4 аргумента, первые-три из которых опциональны и могут быть равны нулю (в этом случае фильтр отключается и сканируются все устройства). В природе, на все случаи жизни имеются три распространённых шаблона аргументов этой функции, которые закоментированы в исходнике ниже – это шаблон для всех устройств, фильтр по текстовой маске (возможные варианты: USB/PCI/PCMCIA/SCSI), и фильтрация устройств по классу GUID.

2. SetupDiEnumDeviceInfo() – заполняет структуру SP_DEVINFO_DATA, которая описывает конкретный элемент в классе-устройств. Больше эта функция ничего не делает. Позже, мы должны будем передать указатель на эту структуру третьей функции в этой тусовке, чтобы она черпала с неё информацию. Для перечисления всего списка-устройств указанного класса, нужно поместить данную функцию в цикл, каждый раз увеличивая значение индекса на 1. Эта функция BOOL и возвращает EAX=0 при ошибке (последний элемент в списке):

3. SetupDiGetDeviceRegistryProperty() – последняя, довольно творческая единица и делает всю черновую работу. Именно эта функция лезет в системный реестр, заполняя наш приёмный буфер нарытими данными. Для начала посмотрим на её аргументы, а потом разберёмся с деталями:

Здесь мы рассмотрели всего 1% из имеющихся 600 функций в библиотеки setupapi.dll. За бортом осталась довольно могучая SetupDiGetDeviceInterfaceDetail() и многие другие. Однако когда-нибудь нужно сделать первый шаг к покорению этой вершины, что открывает богатые возможности для программирования железа из пользовательского режима. Кстати MSDN хорошо раскрывает эту тему и содержит много полезных материалов – учите и вам обязательно зачтётся.

Под занавес статьи, хочу привести пример bat-файла, который поможет вам искать различные константы в огромном море сишных (и не только) инклуд. Он универсальный и ищет текст по указанной маске, рекурсивно обходя все папки и файлы на жёстком диске. Просто кидаете его в корневую папку и подставляете текст для поиска в аргумент команды FINDSTR между двумя прямыми слэшами. Пошурша некоторое время блинами диска, батник вернём вам директории и имена файлов, где имеется указанный текст – очень удобно (для отображения кириллицы, сохраните его в кодировке OEM-866):

Источник

Проверить файл setupapi.dll

Описание setupapi.dll

setupapi.dll

. был замечен в директориях

. вот такого размера

. и таким копирайтом

Источник

Что такое AdminService.exe? Это безопасно или вирус? Как удалить или исправить это

Что такое AdminService.exe?

AdminService.exe это исполняемый файл, который является частью Bluetooth Win7 Suite Программа, разработанная Atheros Communications, Программное обеспечение обычно о 14.95 MB по размеру.

AdminService.exe безопасно, или это вирус или вредоносная программа?

Первое, что поможет вам определить, является ли тот или иной файл законным процессом Windows или вирусом, это местоположение самого исполняемого файла. Например, такой процесс, как AdminService.exe, должен запускаться из C: Program Files Bluetooth Suite AdminService.exe, а не где-либо еще.

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

Наиболее важные факты о AdminService.exe:

Если у вас возникли какие-либо трудности с этим исполняемым файлом, вы должны определить, заслуживает ли он доверия, прежде чем удалять AdminService.exe. Для этого найдите этот процесс в диспетчере задач.

Найдите его местоположение (оно должно быть в C: Program Files Bluetooth Suite ) и сравните его размер с приведенными выше фактами.

Если вы подозреваете, что можете быть заражены вирусом, вы должны немедленно попытаться это исправить. Чтобы удалить вирус AdminService.exe, необходимо Загрузите и установите приложение полной безопасности, например Malwarebytes., Обратите внимание, что не все инструменты могут обнаружить все типы вредоносных программ, поэтому вам может потребоваться попробовать несколько вариантов, прежде чем вы добьетесь успеха.

Могу ли я удалить или удалить AdminService.exe?

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

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

Наиболее распространенные ошибки AdminService.exe, которые могут возникнуть:

• «Ошибка приложения AdminService.exe».
• «Ошибка AdminService.exe».
• «AdminService.exe столкнулся с проблемой и должен быть закрыт. Приносим извинения за неудобства».
• «AdminService.exe не является допустимым приложением Win32».
• «AdminService.exe не запущен».
• «AdminService.exe не найден».
• «Не удается найти AdminService.exe».
• «Ошибка запуска программы: AdminService.exe».
• «Неверный путь к приложению: AdminService.exe».

Как исправить AdminService.exe

Если у вас возникла более серьезная проблема, постарайтесь запомнить последнее, что вы сделали, или последнее, что вы установили перед проблемой. Использовать resmon Команда для определения процессов, вызывающих вашу проблему. Даже в случае серьезных проблем вместо переустановки Windows вы должны попытаться восстановить вашу установку или, в случае Windows 8, выполнив команду DISM.exe / Online / Очистка-изображение / Восстановить здоровье, Это позволяет восстановить операционную систему без потери данных.

Чтобы помочь вам проанализировать процесс AdminService.exe на вашем компьютере, вам могут пригодиться следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Единый рейтинг риска безопасности указывает на вероятность того, что это шпионское ПО, вредоносное ПО или потенциальный троянский конь. Это антивирус обнаруживает и удаляет со своего жесткого диска шпионское и рекламное ПО, трояны, кейлоггеры, вредоносное ПО и трекеры.

Обновлено апреля 2021 года:

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

Загрузите или переустановите AdminService.exe

Вход в музей Мадам Тюссо не рекомендуется загружать заменяемые exe-файлы с любых сайтов загрузки, так как они могут содержать вирусы и т. д. Если вам нужно скачать или переустановить AdminService.exe, мы рекомендуем переустановить основное приложение, связанное с ним. Bluetooth Win7 Suite.

Информация об операционной системе

Ошибки AdminService.exe могут появляться в любых из нижеперечисленных операционных систем Microsoft Windows:

Источник

Что такое Windows API

Интерфейс прикладного программирования WindowsAPI (applicationprogramminginterface) является интерфейсом системного программирования в пользовательском режиме для семейства операционных систем Windows. До выхода 64-разрядных версий Windows программный интерфейс для 32-разрядных версий операционных систем Windows назывался Win32 API, чтобы его можно было отличить от исходной 16-разрядной версии Windows API (которая служила интерфейсом программирования для начальных 16-разрядных версий Windows).

Windows API состоит из нескольких тысяч вызываемых функций, которые разбиты на следующие основные категории:

Описание WindowsAPI можно найти в документации по набору инструментальных средств разработки программного обеспечения — WindowsSoftwareDevelopmentKit (SDK). Эта документация доступна на веб-сайте www.msdn.microsoft.com. Она также включена со всеми уровнями подписки в сеть MicrosoftDeveloperNetwork (MSDN), предназначенную для разработчиков.

Службы, функции и стандартные программы.

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

История Win32 API.

Интересно, что Win32 не планировался в качестве исходного интерфейса программирования для той системы, которая в ту пору называлась Windows NT. Поскольку проект Windows NT запускался в качестве замены для OS/2 версии 2, первоначальным интерфейсом программирования был 32-разрядный OS/2 PresentationManagerAPI. Но через год после запуска проекта произошел взлет поступившей в продажу Microsoft Windows 3.0. В результате этого Microsoft сменила направление и сделала Windows NT будущей заменой семейства продуктов Windows, а не заменой OS/2. В связи с этим и возникла необходимость выработать спецификацию Windows API — до этого, в Windows 3.0, API существовал только в виде 16-разрядного интерфейса.

Хотя в Windows API намечалось введение множества новых функций, недоступных в Windows 3.1, Microsoft решила сделать новый API, по возможности, максимально совместимым по именам, семантике и используемым типам данных с 16-разрядным Windows API, чтобы облегчить бремя переноса существующих 16-разрядных Windows-приложений в Windows NT. Этим, собственно, и объясняется тот факт, что многие имена функций и интерфейсов могут показаться непоследовательными: так нужно было для обеспечения совместимости нового Windows API со старым 16-разрядным Windows API.

Источник

Windows setup api что это

Windows API (англ. application programming interfaces ) — общее наименование набора базовых функций интерфейсов программирования приложений операционных систем семейств Microsoft Windows корпорации «Майкрософт». Предоставляет прямой способ взаимодействия приложений пользователя с операционной системой Windows. Для создания программ, использующих Windows API, корпорация «Майкрософт» выпускает комплект разработчика программного обеспечения, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств для разработки.

Содержание

Общие сведения [ править | править код ]

Windows API спроектирован для использования в языке Си для написания прикладных программ, предназначенных для работы под управлением операционной системы MS Windows. Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. В то же время конвенция вызова функций отличается от cdecl, принятой для языка C: Windows API использует stdcall (winapi). Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие.

Для облегчения переноса на другие платформы программ, написанных с опорой на Windows API, сделана библиотека Wine.

Персональные инструменты

Содержание

Общие сведения

Работа через Windows API — это наиболее близкий к операционной системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

Windows API представляет собой множество функций, структур данных и числовых констант, следующих соглашениям языка Си. Все языки программирования, способные вызывать такие функции и оперировать такими типами данных в программах, исполняемых в среде Windows, могут пользоваться этим API. В частности, это языки C++, Pascal, Visual Basic и многие другие. Эти функции в свою очередь могут быть разбиты на следующие основные категории:

История Microsoft API

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

Обзор

Функции, предоставляемые Windows API, могут быть представлены следующим образом:

Взаимодействие программ

Версии Windows API

Почти каждая новая версия Microsoft Windows представила свои собственные дополнения и изменения в Windows API.

Microsoft также предоставляет несколько интерфейсов API для кодирования медиа и воспроизведения:

Со вчерашнего дня, господа, можно написать вот такой скрипт:

и, запустив его в Windows, получить желаемый результат — диалоговое окно Windows.

Это стало возможным потому, что модуль (обёртку вокруг той необыкновенно полезной библиотеки которая используется для вызова библиотек на языке Си не менее чем других языках) вчера портировали на Windows.

Следует, разумеется, помнить о том, что в Windows API используются строки в формате а джаваскриптовые строки Node.js хранит Воплощением этой разницы является в моём примере преобразователь аналог одноимённого макро, описанного

Ясное дело, что на Windows API свет клином не сошёлся: модуль можно использовать для вызова какой угодно библиотеки, написанной на языке Си или соблюдающей принятый в Си способ вызова функций (например, в Си++ это достигается директивою

Что означает этот шаг эволюции возможностей Node.js?

Напомню предсказание, сделанное мною меньше месяца назад — шестнадцатого декабря 2011 года:

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

И месяца не прошло, как второй из этих трёх пунктов реализовался. Любая библиотека может быть оскриптована джаваскриптами. Соответственно, приложениям на Node.js под Windows стала доступна вся мощь системных API, а кросс-платформенные приложения могут невозбранно обращаться ко кросс-платформенным библиотекам, таская их с собою.

Первый из этих трёх пунктов (касавшийся как раз таскания библиотек с собою) не реализовался в том виде, в каком я мечтал о нём: пакетный менеджер npm всё ещё не обеспечивает возможность доставки только того скомпилированного кода, который нужен конкретной системе. Но у меня появился новый повод для оптимизма после того, как я увидел, что разработчикам модуля удалось обойти нехватку такой возможности. Их модуль содержит один и тот же код, скомпилированный под полдесятка различных платформ:
а скрипт lib/bindings.js во время вызова модуля оглядывается, соображая, куда же попал он, и подбирает нужный двоичный код:

Как видно, работает ничуть не хуже; папка «compiled» вот только занимает ≈700 килобайтов, но при нынешних объёмах дисков и скоростях сетей об этом можно позабыть.

Источник

Статья SetupAPI – информация об устройствах

Перед любым системным программистом, рано или поздно встаёт задача определения текущего оборудования системы. Причин для этого может быть много, например: установить драйвер на девайс, собрать лог всех устройств для последующей работы с ними и т.п. Если мы не будем готовы к таким поворотам судьбы, то придётся переобуваться в воздухе (на скорую руку штудируя доки), в результате чего на выходе получим как-минимум кривой софт.

Да. в штатной поставке Windows имеется оснастка WMI Control – Windows Management Instrumentation (инструментарий управления Win), которая прекрасно решает проблемы данного характера. Однако вызывать сторонние сервисы и приложения из своих программ слишком накладно по времени, и наше приложение будет жутко тормозить. Личные опыты показали, что одну и ту-же задачу WMI решает аж в 60 раз медленнее, чем если этот-же функционал реализовать прямым вызовом системных функций WinAPI – аргумент явно не в пользу WMI, хотя данная оснастка и требует от нас меньших телодвижений.

Основное назначение библиотеки setupapi.dll – это установка драйверов устройств и законченная их регистрация в системном реестре. Данная библиотека состоит из двух самостоятельных модулей:

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

Знакомство с классами устройств, и их идентификаторами GUID

Современная архитектура компьютерных систем имеет огромное количество устройств, и только часть из них внешние. К внешним относятся жёсткий диск, клавиатура, мышь, модем, монитор и прочая ботва, с которой нас знакомили на уроках информатики. Однако внутри чипсета материнской платы зарыты внутренние устройства – это различного рода шины, таймеры, контролёры, мосты и много другое. Более того, в системе могут присутствуют одинаковые по типу, но разные по назначению устройства, а значит их нужно как-то фильтровать.

Таким образом, все устройства в системе (будь-то внешние или внутренние) разделяются на классы, например: класс шины PCI, класс USB, видео-класс, класс принтеров, модемов, клавиатуры и т.д. В системе, буквально любое устройство обязательно принадлежит к какому-нибудь классу. Каждый класс устройств идентифицируется своим GUID«ом (глобальный уникальный идентификатор), который представляет из-себя 16-байтную (128 битную) запись вида: <50127dc3-0f36-415e-a6cc-4cb3be910b65>. Схематически это можно представить так:

Информационной базой всех устройств является системный реестр, где для каждого класса-устройств выделена своя ветвь. Все классы собраны в разделе реестра HKLMSYSTEMCurrentControlSetControlClass. В этой папке мы найдём зарегистрированные когда-либо в системе GUID’ы и даже тех классов, привязанных устройств к которым в текущий момент может и не быть. Например подключили мы к компьютеру месяц назад камеру, а потом убрали её за ненадобность. Это нужно учитывать при сканировании устройств, выставляя флаг DIGCF_PRESENT=2 (только активные девайсы).

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

Забегая вперёд скажу, что для каждого из найденных устройств, функция SetupDiGetDeviceRegistryProperty() как пылесос может вытянуть до 37-ми его характеристик – именно такое количество SPDRP-флагов мы можем передавать ей в аргументе. Как-говорится – хоть лопатой греби..

В талмуде мелкомягких, глобальный идентификатор GUID описывается вполне легальной структурой. Например на рисунке выше, GUID характеризует класс USB-устройств и имеет значение: <36fc9e60-c465-11cf-8056444553540000>. Если копнуть доки, то можно найти значения GUID всех (само)настраивающихся устройств PnP – в представлении ассемблера каждая запись выглядит так, и я собрав их в инклуде setupapi.inc, прикрепил его в скрепке (в штатной поставке fasm’a их нет):

Основные API-функции для сбора информации

Будем считать, что с теорией разобрались – перейдём к практической части..
Из указанных 600-функций библиотеки setupapi.dll мы будем использовать всего 6-7. Эти функции позволят нам выжать достаточно информации от первого свидания с этой либой. В качестве демонстрации напишем приложение, которое перечислит все идентификаторы GUID системы и отобразит в читабельном виде, какому именно классу принадлежит тот-или-иной GUID. Здесь в окопах нас поджидают некоторые нюансы – разберём их в кратце..

1. В цикле обходит все классы и возвращает нам их GUID’ы функция CM_Enumerate_Classes() с таким прототипом:

Если коротко, то нам нужно организовать цикл и на каждой его итерации, начиная с нуля увеличивать индекс класса. Эта функция BOOL, так-что если она вернёт EAX=1, значит мы обошли всю базу и пора из цикла выходить. Второй аргумент – это указатель на 16 байтный буфер, в который функция будет сбрасывать GUID текущего индекса. Третий аргумент не используется и должен быть установлен в нуль.

Эта функция сбрасывает в буфер GUID в виде Unicode-строки, значит для вывода на консоль её нужно будет преобразовать в Ascii. Для этого будем просто читать по 2-байта, и перезаписывать в тот-же буфер по одному байту (т.е. отсекать парные нули). Вот как выглядит эта информация в секции-данных программы, после того-как функция StringFromGUID2() отработает:

4. Можно прикрутить в исходник код профилировщика, чтобы лицезреть время, потраченное программой на реализацию задуманного. Мы просто на входе в основную процедуру запомним текущие тики системного таймера функцией GetTickCount() , а на выходе из процедуры запросим их опять, и вычислим разницу. Так мы получим хоть какой-то метроном, который отстучит нам потраченное на исполнение кода время. Теме профайлеров мы посвятим отдельную статью, а пока будем довольствоваться этим алго времён динозавров.

Теперь, законченная реализация кода для вывода имени-класса по его GUID может выглядеть примерно так:

Что мы тут имеем? Значит всего классов-устройств в системе равно 60, и соответственно столько-же идентификаторов GUID. Пусть вас не смущает время выполнение данного кода 560 миллисекунд – это тестировалось на виртуальной машине VirtualBox, скорость которой можно сравнить с активностью уставшей улитки. К примеру на скрине ниже я запустил этот-же кодес на реальном процессоре под хр, так хрюша пробежала эту дистанцию всего за 32 мс – как говорится, почувствуйте разницу: 560/32=17.5 раз быстрее:

Перечисляем все, или принадлежащие только к одному классу устройства

1. SetupDiGetClassDevs() – возвращает дескриптор инфо-базы по GUID-класса (см.рис.2), или нуль в случае ошибки. На входе принимает 4 аргумента, первые-три из которых опциональны и могут быть равны нулю (в этом случае фильтр отключается и сканируются все устройства). В природе, на все случаи жизни имеются три распространённых шаблона аргументов этой функции, которые закоментированы в исходнике ниже – это шаблон для всех устройств, фильтр по текстовой маске (возможные варианты: USB/PCI/PCMCIA/SCSI), и фильтрация устройств по классу GUID.

2. SetupDiEnumDeviceInfo() – заполняет структуру SP_DEVINFO_DATA, которая описывает конкретный элемент в классе-устройств. Больше эта функция ничего не делает. Позже, мы должны будем передать указатель на эту структуру третьей функции в этой тусовке, чтобы она черпала с неё информацию. Для перечисления всего списка-устройств указанного класса, нужно поместить данную функцию в цикл, каждый раз увеличивая значение индекса на 1. Эта функция BOOL и возвращает EAX=0 при ошибке (последний элемент в списке):

3. SetupDiGetDeviceRegistryProperty() – последняя, довольно творческая единица и делает всю черновую работу. Именно эта функция лезет в системный реестр, заполняя наш приёмный буфер нарытими данными. Для начала посмотрим на её аргументы, а потом разберёмся с деталями:

Здесь мы рассмотрели всего 1% из имеющихся 600 функций в библиотеки setupapi.dll. За бортом осталась довольно могучая SetupDiGetDeviceInterfaceDetail() и многие другие. Однако когда-нибудь нужно сделать первый шаг к покорению этой вершины, что открывает богатые возможности для программирования железа из пользовательского режима. Кстати MSDN хорошо раскрывает эту тему и содержит много полезных материалов – учите и вам обязательно зачтётся.

Под занавес статьи, хочу привести пример bat-файла, который поможет вам искать различные константы в огромном море сишных (и не только) инклуд. Он универсальный и ищет текст по указанной маске, рекурсивно обходя все папки и файлы на жёстком диске. Просто кидаете его в корневую папку и подставляете текст для поиска в аргумент команды FINDSTR между двумя прямыми слэшами. Пошурша некоторое время блинами диска, батник вернём вам директории и имена файлов, где имеется указанный текст – очень удобно (для отображения кириллицы, сохраните его в кодировке OEM-866):

Источник

Видео

«Всемирный исход» пользователей в рамках бесплатного обновления с Windows 7/8 до Windows 10 сопровождался огромным количеством различных ошибок и ситуаций, когда с виду абсолютно статичный компьютер демонстрировал крайне высокое потребление ресурсов, не типичных как для самой ситуации, так и в принципе для отдельно взятого устройства. Безусловно, такая массовость должна была создать (и что греха таить, успешно создала) множество проблем большинству пользователей, из которых некоторые вариации продолжают «терроризировать» владельцев ОС от Microsoft и можно быть в достаточной степени уверенным, что и в дальнейшем от них никуда не деться. Поэтому большинство проблем прошлых лет (1-2 года назад) не теряет свою актуальность и в настоящее время. И в рамках настоящей статьи речь пойдёт о процессе «Modern Setup Host», который тесно связан с обозначенным выше функционалом и при определённых обстоятельствах создаёт крайне чувствительную нагрузку на ресурсы компьютера. В чём причина этого? А главное — как исправить такое высокое потребление ресурсов? На ответах на эти и другие вопросы и следует остановиться далее более подробно.

Для чего нужен процесс Modern Setup Host

Итак, что это за процесс – Modern Setup Host, какие функции он выполняет в операционной системе? Исходный файл процесса, SetupHost.exe, – это один из элементов (служба) функционала актуализации операционной системы, необходимый в процессе запуска/остановки RPC-process. Данный функционал проявлял особую активность ранее, когда файлы, необходимые для перехода на Windows 10, ждали неаккуратного действия пользователя для своего запуска. Сейчас же его всё ещё можно встретить (но уже с менее значительным влиянием на быстродействие ОС) при осуществлении своей работы со стороны «Центра обновления Windows». Учитывая выполняемый «Modern Setup Host» функционал, можно с уверенностью отметить, что большая часть создаваемой им нагрузки приходится на непосредственный период поиска, скачивания и установки файлов, что является временным явлением и не должно создавать заметную нагрузку именно на диск и процессор, вынуждая пользователя обратить внимание на «Диспетчер задач».

Это во многом позволяет ответить на главный вопрос относительно Modern Setup Host – что это за процесс и для чего он нужен.

Почему он грузит диск

Пользователи порой могут замечать, что на их ПК и ноутбуках с ОС Windows 10 грузит диск. Но тут ещё важно понять, чем именно это вызвано. Совершенно не исключено, что это связано с Modern Setup Host. Вариантов подобного развития событий, на самом деле, не так много, и все они сводятся к одному – штатной работе процесса мешает или сам пользователь, или сторонний фактор. В первом случае эти помехи могут быть следующей направленности:

• инициирование запуска программного обеспечения, которое забирает большую часть ресурсов компьютера (в том числе интернет-трафика) для своих нужд, что приводит к большей затрате времени на поиск и установку обновлений;
• частая перезагрузка компьютера со стороны пользователя;
• частая смена активных учётных записей с завершением сеанса;
• самостоятельное отключение функционала «Центра обновления Windows»;
• ручное прерывание процесса загрузки, в том числе аварийное завершение работы компьютера или выключение интернет-соединения.

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

СОВЕТ. Например, реальный случай из практики – в процессе установки накопительного обновления пользователь случайно отключил автоматическую установку даты и времени, что вызвало появление ошибки и «BSOD». Как оказалось после, отключение синхронизации с сервером стало последним звеном в череде мелких нюансов, но так или иначе данная мелочь вызвала серьёзный сбой в работе ОС.

Возвращаясь к сути вопроса. К особо ярким и значимым внешним факторам, приводящим к таким неприятным последствиям, как сильная загрузка процессора в Windows 10 службой Modern Setup Host, следует отнести:

• недостаток свободного пространства на системном разделе диска;
• некорректная работа жёсткого диска или твердотельного накопителя;
• некорректная работа «Центра обновления», вызванная случайным обрывом интернет-соединения;
• вмешательство в работу ОС вирусного программного обеспечения и т. п.

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

Как решить проблему с нагрузкой

В отличие от представителей причинно-следственной связи, коих может быть множество, решений по «сбросу» чрезмерной нагрузки на ресурсы компьютера существует не так много, так как достаточно сложно выстроить цепочку действий, которые и привели к некорректной работе процесса «Modern Setup Host». Самым действенным вариантом является осуществление данных действий:

• Нажмите комбинацию клавиш «WIN+R» и выполните команду «services.msc».
• В открывшемся окне найдите службу «Центр обновления Windows».
• Переведите её в режим «Отключено» и сохраните изменения, не закрывая окна «Службы».
• Пройдите в папку «C:WindowsSoftwareDistributionDownload».
• Выделите все имеющиеся там файлы и удалите их.
• Вернитесь к окну «Службу» и включите «Центр обновления».
• Откройте «Параметры»-«Обновление и безопасность» и инициируйте поиск и скачивания необходимых для работы Windows файлов.

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

Заключение

В заключении стоит отметить, что существует определённая вероятность, что за процессом «Modern Setup Host» скрывается вирусное программное обеспечение, но происходит это крайне редко. В качестве альтернативных вариантов решения проблем следует выделить фактическое отключение функционала обновления. Сложно назвать решением, но за неимением других альтернатив вполне подойдёт для временного применения.

Почему процесс WSAPPX сильно нагружает диск и процессор в Windows 10

Вопрос

Привет, админ! На моей Windows 10 после установки последних обновлений Windows процесс wsappx начал сильно грузить систему, отъедая почти 50% ресурсов процессора и сильно нагружая диск (30-40%). Что это такое и можно ли как-то снизить потребление ресурсов компьютера процессом wsappx?

Ответ

Доброго дня! Действительно, в Windows 10 есть такой системный процесс wsappx (это не вирус и не стороннее приложение), который может иногда вызывать проблемы с производительностью системы. Попытаюсь подробно рассказать о нем и предложить возможные варианты действий по его «приручению» .

WSAPPX — что это за процесс?

WSAPPX – это системный процесс Window 10 (и Windows 8.1), который тесно связан с магазином приложений Windows и платформой универсальных приложений (Universal Windows Platform — UWP).

Как можно убедитmся в диспетчере задач, процесс WSAPPX в Window 10 включает в себя два фоновых системных процесса:

• AppX Deployment Service (AppXSVC) (служба развертывания AppX) – отвечает за управление развертыванием приложений UWP, которые распространяются в формате .AppX. Процесс активно работает при установке, обновлении и удалении приложений магазина. В диспетчере задач этот процесс появляется при запуске приложения Store (или при выполнении автоматического обновления приложений);
• Client License Service (ClipSVC) (служба лицензий клиента)– отвечает за обеспечение лицензирования платных и ограниченных приложений магазина Windows. Именно этот процесс обрабатывает лицензии платных программ и не позволит запуститься appx-приложению на компьютерах с другой учетной записью Microsoft (даже если получится скачать и установить appx файл универсального приложения).

В консоли служб Windows (services.msc) этим процессам соответствуют две системные службы.

Почему процесс wsappx сильно грузит систему

Итак, как вы поняли процесс wsappx, как правило, может создавать нагрузку на компьютер при установке, обновлении или удалении универсальных приложений. В том случае, если вы устанавливаете или обновляете приложение из магазина Windows, то именно процессом wsappx выполняются все действия (в отличии от классических приложения, которые устанавливаются собственными установщиками или через Windows Installer ). Т.е. высокая загрузка системы процессом wsappx в этом случае вполне допустима. Нужно просто дождаться окончания установки / удаления приложения.

Если же вы не запускали установку или удаления appx приложений, а процесс wsappx активно использует CPU и диск, то скорее всего дело в автоматическом обновлении приложений UWP, которое по умолчанию включено. Откройте Windows Store и проверьте, нет ли в нем выполняющихся заданий автоматического обновления приложений.

Как отключить процесс wsappx

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

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

Возможно также отключить автоматическое обновление приложений магазина Windows. Для этого откройте Microsoft Store и в меню настройке отключите опцию Обновлять приложения автоматически . Здесь же можно отключить живые плитки для всех приложений.

Совет . Не забывайте периодически обновлять используемые приложения вручную

После этого процесс wsappx должен потреблять намного меньше ресурсов системы.

В том случае, если вы не используете Microsoft Store, его можно отключить с помощью политики Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Магазин. Включите политику Отключить приложение Магазин . Либо отключите его через реестр командами:

reg add «HKLMSOFTWAREPoliciesMicrosoftWindowsStore» /v «RemoveWindowsStore» /t «REG_DWORD» /d «1»
reg add «HKLMSOFTWAREPoliciesMicrosoftWindowsStore» /v «DisableStoreApps» /t «REG_DWORD» /d «1»

Источник

Процесс «wsappx»: что за процесс и можно ли его отключить?

Читайте, за что отвечает процесс «wsappx», почему он грузит ПК и возможно ли его отключить . Процесс «wsappx» входит в Windows 8 и 10, и как вы можете видеть, он работает в фоновом режиме и иногда использует значительное количество ресурсов центрального процессора и сильно нагружает жесткий диск. Этот процесс связан с «Windows Store» и новой «универсальной» платформой для приложений из этого магазина.

Так что же такое «wsappx»?

Процесс «wsappx» включает в себя две отдельные фоновые службы. В Windows 8 и 10, «wsappx» запускает службу развертывания «AppX (AppXSVC)» . В Windows 10 также появилась служба лицензий клиентов (ClipSVC). А в Windows 8 вместо неё запущена служба Магазина Windows (WSService).

В «Диспетчере задач» этот процесс можно развернуть, где вы можете видеть каждую из этих служб (в зависимости от используемой версии Windows). Эти службы обрабатывают установку, удаление и обновление приложений из «Microsoft Store» , а также обеспечивают проверку лицензий на их использование.

За что отвечает служба развертывания приложений AppX (AppXSVC)?

Служба развертывания «AppX» именно «развертывает» приложения из «Microsoft Store» . Приложения на основе «Universal Windows Platform» распространяются в пакетах «.AppX» , отсюда и такое название.

Другими словами, этот процесс управляет корректной установкой, удалением и обновлением приложений на этой платформе. ОС Windows обновляет все приложения «Windows Store» в фоновом режиме абсолютно автоматически, в том числе и предустановленные.

Обычное программное обеспечение для ОС Windows использует ресурсы центрального процессора ПК и ресурсы жесткого диска самостоятельно, при установке, удалении или обновлении. Единственное различие заключается в том, что при работе с приложениями «Universal Windows Platform», все эти ресурсы использует один процесс – «AppXSVC» , вместо установщика (setup) отдельной программы.

Если в «Диспетчере задач» вы увидели, что этот процесс использует много ресурсов ПК, когда вы ничего не устанавливаете или не используете какие-либо приложения из «Windows Store» , это значит, что операционная система просто обновляет их в фоновом режиме.

Что такое служба лицензирования клиентов (ClipSVC) и для чего она нужна?

В операционной системе Windows 10 фоновая служба «ClipSVC» обрабатывает «инфраструктурную поддержку» для приложений «Widows Store» . Эта служба запускается по требованию (вручную), и при ее отключении приложения, загруженные или приобретенные в «Windows Store» , будут работать не корректно, или перестанут запускаться вообще.

Эта услуга, скорее всего, выполняет достаточно большое количество различных действий, которые позволяют приложениям «Windows Store» работать должным образом. Согласно его названию, в его обязанности входит управление лицензиями приложений, то есть, если вы не купили программу, то соответственно, не сможете ей воспользоваться. Она была создана для борьбы с пиратством. Помимо этого, компания «Microsoft» умалчивает, какие другие функции выполняет эта служба.

За что отвечает служба Магазина Windows (WSService)?

В Windows 8 фоновая служба «WSService» осуществляет те же функции что и «ClipSVC» в ОС Windows 10. Они имеют фактически идентичные описания в интерфейсе «Службы» . Процесс «WSService» , похоже, в основном такой же, как и «ClipSVC» , он просто называется по-другому.

Почему эти службы используют так много ресурсов ПК и значительно тормозят его работу?

Обычно, служба «wsappx» использует более-менее заметный объем ресурсов центрального процессора, именно когда ваша операционная система устанавливает, удаляет или обновляет приложения «Windows Store» . Чаще всего это происходит при включении ПК, так как автоматическое обновление приложений включено в ОС по умолчанию.

Если вас это действительно раздражает, то проще всего отключить автоматическое обновление. Для этого запустите «Windows Store» , нажмите на «три точки» возле иконки пользователя в правом верхнем углу окна и выберите опцию «Настройки» .

Далее, установите ползунок «Обновлять приложения автоматически» в положение «Выкл.» .

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

На этом экране отображаются все доступные обновления для всех установленных приложений, и вы сможете установить их нажав на кнопку «Получить обновления» .

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

Данное решение не позволит службе «wsappx» использовать ресурсы «CPU» для обновления приложений в фоновом режиме, но в тоже время ваши приложения не будут автоматически получать последние обновления, что может привести к их некорректной работе. Когда же вы вручную обновляете приложения, вы по-прежнему будете использовать ресурсы ПК, такие как «CPU» и «RAM» , но по крайней мере вы сами сможете выбрать время, когда они будут использоваться.

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

Можно ли отключить эти процессы?

Полностью отключить эти процессы не получиться. Они не перезапустятся автоматически в фоновом режиме, они запускаются по мере необходимости и закрываются, когда не нужны. Например, если откроете магазин Windows то служба «AppXSVC» перезапуститься автоматически, если откроете любое приложение из него, то, соответственно – «ClipSVC» . Эти службы появятся в «Диспетчере задач» и можно будет проверить сколько ресурсов ПК они используют в данный момент времени.

Если вы попытаетесь завершить процесс «wsappx» в «Диспетчере задач» , то операционная система предупредит вас о том, что завершение данного процесса приведёт к не стабильной работе ОС или завершению работы. Также, у вас не получится принудительно отключить службу «wsappx» через интерфейс «Службы» , при обращении к магазину Windows они перезапустятся.

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

Возможно это вирусы?

Программное обеспечение «wsappx» является внутренним компонентом Windows 10. На данный момент мы не встречали никаких упоминаний о том, что какая-либо вредоносная программа маскируется под такие процессы как: «wsappx» , «AppXSVC» , «ClipSVC» или «WSService» . Однако, в любом случае, всегда рекомендуется запустить полное сканирование системы с помощью вашго предпочитаемого антивируса .

Источник

Процессом System (Ntoskrnl.exe) сильно грузит CPU в Windows. Что делать?

На одном их компьютеров с только что установленной Windows 10 пользователь стал жаловаться на постоянные зависания и медленную работу ОС. В диспетчере устройств видно, что более 50% ресурсов процессора используется процесс System ( ntoskrnl.exe ). В этой статье я постараюсь описать основные методики диагностики высокой загрузки CPU различными процессами и методы выявления проблемного компонента Windows.

Ситуация, когда процесс System потребляет более половины процессорных ресурсов системы — это не нормально. Сам по себе файл Ntoskrnl.exe представляет собой исполняемый файл ядра ОС. Это базовый процесс системы. В рамках ядра ОС выполняется запуск системных драйверов устройств, которые скорее всего и являются источником проблемы (далеко не все драйверы соответствующим образом тестируются разработчиками оборудования).

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

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

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

В списке запушенных процессов найдите процесс System , щелкните по нему ПКМ и откройте его свойства Properties .

Перейдите на вкладку Threads . Отсортируйте список модулей, загруженных ядром по степени использования процессора (столбец CPU). В строке Start Address указано имя функции или драйвера, вызывающего высокую загрузку (скриншот не с проблемной системы).

Также, чтобы выявить драйвер, который вызывает высокую загрузку CPU, можно воспользоваться бесплатной утилитой Microsoft — kernrate.exe (Kernrate Viewer). Утилита входит в состав WDK (Windows Device Kit). После установки WDK, найти утилиту можно в каталоге …ToolsOtheramd64.

Запустите утилиту kernrate.exe без аргументов и подождите некоторое время, пока идет сбор данных (10-15 минут), после чего прервите работу утилиты сочетанием клавиш Ctrl-C : Посмотрите на список модулей в секции Result for Kernel Mode .

Как вы видите, в нашем примере высокую нагрузку на CPU вызывает модуль b57nd60x . С помощью Google или утилиты sigcheck (смотри пример ) можно определить, что проблему вызывает драйвер сетевой карты Broadcom NetXtream Gigabit Ethernet NDIS6.0 Driver.

Кроме того, проанализировать использование CPU при загрузки системы можно с помощью Windows Performance Toolkit (WPT). Нужно установить компонент и запустить сбор данных с помощью графической консоли Windows Perfomance Recorder (First level triangle + CPU usage -> Start)

xperf -on latency -stackwalk profile -buffersize 1024 -MaxFile 256 -FileMode Circular && timeout -1 && xperf -d cpuusage.etl

Совет . Этот способ удобно использовать, если после загрузки система напрочь зависает и работать в ней просто невозможно. Скорее всего вам также будет полезна статья с методикой диагностики долгой загрузки Windows .
Полученный файл нужно сохранить и открыть в WPA. Разверните стек процесса System. В этом примере видно, что высокую нагрузку на процессор вызывает драйвер athrx.sys (Wi-Fi адаптер Atheros Wireless Network Adapter).

Для решения проблемы нужно попробовать установить более новую (или старую) версию драйвера или же совсем отключить оборудование, если проблема наблюдается со всеми версиями драйвера. Обновленный драйвер можно дополнительно проверить стресс-тестом с помощью Driver Verifier .

Источник