Setupapi log windows 10 где находится

лог установки программ windows 10

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз я вас научил определять кто именно перезагрузил сервер, это полезный навык при расследовании инцидентов. Бывают ситуации, что на сервер используют большое количество пользователей с одинаковыми правами, и вдруг куда-то пропадает одна из программ, вы видите что ее нет, логично, что нужно выяснить кто именно удалил программу. Вот этим мы и займемся, я вас научу получать информацию, кто установил или удалил программу в Windows.

Как узнать кто установил программу и когда

И так у меня есть тестовый сервер с операционной системой Windows Server 2019 и я на него в качестве демонстрации буду устанавливать Microdoft Edge Chromium, FireFox Mozilla, а так же LogParser. Все события, что генерируются в операционной системе Windows появляются в просмотре событий, это лог файлы разбитые по журналам.

первое это событие с ID 1040 покажет вам начало установки программы:

Далее идет сообщение с кодом ID 10000.

Далее вы увидите событие, где заканчивается установка программы ID 1042

Завершается сеанс событием с кодом ID 10001

И заканчивается установка программы событием с кодом ID 11707

Иногда вы можете увидеть событие с ID 1033.

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

В источниках событий выберите из выпадающего списка пункт MsiInstaller.

В итоге у меня получилось вот так.

Теперь когда события отфильтрованы по источнику MsiInstaller, вам будет еще легче найти кто установил, что установил и когда. В моем примере это сделал ROOT\Администратор.

Так же событие ID 11707 с пользователем «SYSTEM (СИСТЕМА)» вы можете обнаружить, когда люди используют «Software Store» в SCCM

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

Автоматизация оповещения по событиям 11707

Теперь когда вы знаете, как находить события по установке программ в системах семейства Windows, вам нужно автоматизировать данный процесс. Например, получать по почте, кто установил, где и что. В этом нам поможет конечно же PowerSell. Смысл автоматизации состоит в том, что вы на нужном сервере создаете задание в планировщике Windows, где будет запускаться скрипт PowerShell. Я вам приведу два скрипта, первый тот, что гуляет на просторах интернета.

Тут главное заполнить:

В результате вы получите письмо вот такого содержания:

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

Так же вам никто не запрещает просто открыть PowerShell и ввести не сложный код:

Как найти события установки программ не методом MsiInstaller

Как я и писал выше не все инсталляторы программ используют метод MsiInstaller, например при установке Edge Chrome или Mozilla Firefox, вы в журнале «Приложение» не обнаружите события с кодом ID 11707. В таком случае вам нужно перейти в журнал «СИСТЕМА (SYSTEM)» и сразу отфильтровать события по номеру ID 7045.

Выглядит событие ID 7045 вот так:

Имя службы: Mozilla Maintenance Service
Имя файла службы: «C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe»
Тип службы: служба режима пользователя
Тип запуска службы: Вручную
Учетная запись службы: LocalSystem

Имя службы: Microsoft Edge Elevation Service
Имя файла службы: «C:\Program Files (x86)\Microsoft\Edge\Application\80.0.361.111\elevation_service.exe»
Тип службы: служба режима пользователя
Тип запуска службы: Вручную
Учетная запись службы: LocalSystem

Как узнать кто удалил программу с сервера или компьютера

По аналогии с установкой, процесс деинсталляции или как его еще называют удаление, генерирует свои события в журналах Windows. Если мы говорим, про источник MsiInstaller из журнала «Приложение (Application)», то нам нужно фильтровать события по ID 11724 и ID 1034.

Так же вы можете спокойно использовать описанный выше скрипт и команду PowerShell, для автоматизации оповещения, о удалении программы.

Дополнительно

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

Windows Файлы журналов и журналы событий программы установки

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

Windows Файлы журналов установки доступны в следующих каталогах:

Расположение журнала перед тем, как программа установки сможет получить доступ к диску.

Расположение журнала при откате установки в случае неустранимой ошибки.

Расположение журнала действий установки после настройки диска.

Используется для регистрации самонастраивающийся установки устройств.

Расположение дампа памяти при проверке наличия ошибок.

Расположение дампов журнала для проверок ошибок.

Расположение журналов Sysprep.

Windows Журналы событий установки

Windows программа установки включает возможность просмотра событий производительности программа установки Windows в средстве просмотра журнала событий Windows. это позволяет упростить проверку действий, произошедших во время программа установки Windows, а также просматривать статистику производительности для различных частей программа установки Windows. Можно отфильтровать журнал так, чтобы просмотреть только нужные элементы. программа установки Windows события производительности сохраняются в файл журнала с именем Setup. etl, который доступен в каталоге% WINDIR% \ пансер всех установок. для просмотра журналов необходимо использовать Просмотр событий, поставляемые с носителем Windows, который соответствует версии создаваемого образа.

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

где D — буква диска Windows DVD-носителя.

просмотр журналов событий программа установки Windows

запустите Просмотр событий, разверните узел журналы Windows и выберите пункт система.

Содержимое файла журнала отображается в Просмотр событий.

Экспорт журнала в файл

Windows Vista, Windows 7, Windows Server 2008 R2, Windows 8.1 и Windows 10 расположения файлов журнала установки

В этой статье описывается, где найти эти файлы журналов и какие файлы журнала наиболее полезны для устранения неполадок на каждом этапе установки Windows 7, Windows Server 2008 R2 и Windows Vista.

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016
Исходный номер КБ: 927521

Введение

Windows файлы журнала установки находятся в разных расположениях на жестком диске. Эти расположения зависят от этапа установки.

Поддержка Windows Vista без установленных пакетов служб завершилась 13 апреля 2010 г. Чтобы продолжить получать обновления безопасности для Windows, убедитесь, что вы Windows Vista с Пакет обновления 2 (SP2). Дополнительные сведения см. в Windows поддержки XP.

Этап down-level

Этап downlevel — это этап Windows установки, запущенный в предыдущей операционной системе. В следующей таблице перечислены важные файлы журналов на этом этапе установки.

Windows Этап среды предварительной оценки

Этап Windows среды предварительной настройки (Windows PE или WinPE) — это фаза установки Windows, которая происходит после перезагрузки в конце этапа downlevel или при запуске компьютера с помощью средства установки Windows. В следующей таблице перечислены важные файлы журналов на этом этапе установки.

Вы также можете увидеть файл журнала в X:\WINDOWS каталоге. Файл Setupact.log в этом каталоге содержит сведения о ходе выполнения начальных параметров, выбранных на экране Windows установки. Экран Windows появляется при запуске компьютера с помощью Windows установки. После выбора Установки теперь с Windows на экране установки запускается Setup.exe, и этот файл журнала больше не используется.

Этап конфигурации в Интернете

Этап конфигурации в Интернете (первый этап загрузки) начинается после получения следующего сообщения:

Подождите минутку, Windows подготовиться к первому запуску.

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

Windows Фаза приветствия

Этап Windows Welcome включает в себя следующие параметры и события:

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

Этап отката

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

Файлы журналов программы установки Windows

Установка Windows® создает файлы журналов для всех действий, выполняемых во время установки. При наличии проблем с установкой Windows просмотрите файлы журналов для поиска и устранения неполадок.

Файлы журналов установки Windows сохраняются в следующих каталогах:

Местоположение журнала перед доступом установки к диску.

Расположение журнала при откате установки в случае неустранимой ошибки.

Расположение журнала действий установки после настройки диска.

Используется для регистрирования установок устройств Plug and Play.

Местоположение дампа памяти для проверки на ошибки.

Местоположение зарегистрированных мини-дампов для проверки на ошибки.

Местоположение журналов программы Sysprep.

Журналы событий установки Windows

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

События производительности установки Windows регистрируются в файле журнала с именем Setup.etl, который находится в каталоге %WINDIR%\Panther всех установок Windows® 7.

Чтобы просмотреть эти журналы, необходимо воспользоваться средством просмотра событий в Windows 7, Windows Vista®, Windows Server® 2008 или Windows Server® 2008 R2.

Чтобы просмотреть эти журналы на компьютере под управлением Windows Vista без Windows AIK 2.0 или Windows OPK 2.0, необходимо из корневого каталога носителя с Windows 7 или Windows Server 2008 R2 запустить сценарий, который устанавливает поставщика отслеживания событий Windows. В командной строке введите:

Просмотр журналов событий установки Windows

Экспорт журнала в файл

Для сохранения журнала в XML- или текстовый файл введите в командной строке команду Wevtutil или Tracerpt. Дополнительные сведения об этих программах см. в справке командной строки. В следующих примерах показано, как можно использовать эти программы:

Setupapi log windows 10 где находится

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

В продуктах «Лаборатории Касперского» лог установки и удаления создается автоматически. Логи помещаются в папку %temp% (обычно С:\Windows\Temp или C:\Documents and Settings\<имя_профиля>\LocalSettings\Temp) и имеют следующие имена:

• kl-install-yyyy-mm-dd-hh-mm-ss.log
• kl-setup-yyyy-mm-dd-hh-mm-ss.log

Как найти файл трассировки установки/удаления

Чтобы найти файл трассировки установки или удаления программы:

1. Нажмите +R на клавиатуре.
2. Введите фразу %TEMP% и нажмите ОК.

1. В диалоговом окне папки %TEMP% найдите файл, например, с именем kl-install-<дата установки>-<время установки>.log

В Windows Vista по умолчанию установлена служба Windows Installer версии 4.0. Если на вашем компьютере используется Windows Vista или Windows Installer версии 4.0, по умолчанию при удалении программы в папке %TEMP% создается лог удаления программы с именем MSI<набор символов>.log (например, файл с именем MSI8ba62.LOG).

Что делать, если лог установки/удаления не был создан автоматически

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

1. Скачайте архив MSI_log.zip.
2. Распакуйте все файлы из архива.
3. Запустите файл MSI_log_on.reg для добавления в реестр необходимого ключа и нажмите Да. В результате появится окно, подтверждающее успешное добавление информации в реестр.

1. Запустите установку или удаление программы.
2. Воспроизведите проблему.
3. В результате сгенерируется текстовый файл — лог работы инсталлятора с именем MSI*.log (где * — произвольный набор из алфавитно-цифровых символов. Этот файл находится в системной папке Temp. По умолчанию папка Temp располагается:
   • Для Windows Vista, 7, 8, 8.1, 10, 11 в папке \Users\%USERPROFILE%\AppData\Local\Temp
   • Для Windows XP в папке \Documents and Settings\%USERPROFILE%\Local Settings\Temp
4. Запустите файл MSI_log_off.reg и нажмите Да. Лог трассировки установки или удаления будет отключен.

Лог работы установщика создается при установке и удалении программы, каждый раз под уникальным именем. Если в папке Temp уже были логи предыдущих установок, выберите логи с самым поздним временем создания.

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

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

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

Так-что оставим этот инструментарий для сис-админов (хотя не факт, что большая часть из них в полной мере знакомы с ним), а мы попробуем собрать инфу об устройствах с подручными средствами, для чего воспользуемся услугами специально предназначенным для этого набором функций под общим названием setupAPI . Этот набор живёт в одноимённой системной библиотеке setupapi.dll, которая выдаёт на экспорт без малого 600-функций. Жалко, что fasm о них ничего не знает и не имеет служебных структур для работы с ней, но это дело поправимое (см.скрепку в конце статьи). Ознакомиться с кол-вом функций и их именами можно в дизассемблере\отладчике W32Dasm, что демонстрирует скрин ниже:

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

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

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

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

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

Информационной базой всех устройств является системный реестр, где для каждого класса-устройств выделена своя ветвь. Все классы собраны в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Class. В этой папке мы найдём зарегистрированные когда-либо в системе 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 текущего индекса. Третий аргумент не используется и должен быть установлен в нуль.

2. Чтобы привести полученный GUID в читабельную строку (его мы получим в виде hex-значения), задействуем специально предназначенную для этого функцию из библиотеки ole32.dll StringFromGUID2() . Всё-что ей нужно, это указатель на 16-тиричный GUID для преобразования, и указатель на приёмный буфер, куда она сбросит результирующую строку. В случае успеха, fn. возвращает длину записанной в буфер строки. Если получим нуль, значит приёмный буф слишком мал и в аргумент cchMax вернётся трубуемая длинна. Вот её прототип:

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

3. На заключительном этапе, чтобы наша GUID-строка несла в себе хоть какую-то информацию, нужно будет по GUID получить строку с именем класса-устройства (см.зелёный блок на рисунке выше). В этом нам поможет функция из setupapi.dll с говорящим за себя названием SetupDiGetClassDescription() . Как и предыдущая, эта функция требует на входе указатель на 16-тиричный GUID, а из своей выхлопной трубы со-свистом выдаёт строковое представление данного класса-устройств (обе функции сами вставляют терминальный нуль в конце):

Из рисунка выше видно, что эта функция возвращает строку в кодировке cp-1251 (зелёный блок), т.е. кириллицей. Если мы планируем выводить информацию в виндовую консоль, то в своём пространстве консоль воспринимает только дос-кодировку OEM-866 . Соответственно если не перекодировать этот выхлоп, то вместо текста, на экране получим инопланетные крякозябры. Для этого воспользуемся функцией из user32.dll под названием CharToOem() , которая изменит кодировку прямо не отходя от кассы, в том-же буфере.

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

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

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

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

Получив GUID’ы классов всех устройств проследуем дальше, и попробуем отфильтровать лог по конкретному классу-устройств, например собрать информацию только об устройствах USB или тех, что повесились на шине PCI и т.п. Такую задачу решает аккорд всего из трёх функций, и все они прописаны в библиотеке setupapi.dll. Обычно эти функции имеют приоритет друг перед другом, т.е. их нужно вызывать в определённой последовательности – рассмотрим её..

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

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

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

Из все этой братии аргументов, нам интересен лишь третий, под кличкой ‘Property’. Он спрашивает у нас, информацию какого характера мы хотим получить? Вот где можно разгуляться с баяном в руках, подставляя в него одну из 37-ми констант (см.инклуд setupapi.inc в скрепке). Эта константа известна как SPDRP – Setup Device Registry Property , или выбор свойства из куста реестра. К сожалению аргумент не позволяет инструкцией OR задавать сразу несколько констант, поэтому если мы хотим за один подход вытянуть несколько строк различной инфы, нужно вызывать эту функцию N-ное количество раз, подставляя в этот аргумент соответствующие значения.

Здесь нужно учитывать, что если нам нужно имя устройства, то оно может хранится в одном из двух полей информационной базы – это Description и Name (зависит от типа устройства). Поэтому чтобы не попасть в просак, для надёжности нужно запрашивать имя сразу два раза – первый раз с аргументом SPDRP_DEVICEDESC , и если функция SetupDiGetDeviceRegistryProperty() вернёт ошибку (или пустую строку в буфере), то второй раз подставить SPDRP_FRIENDLYNAME . Не сбрасывайте это со-счетов..

Без практики, понять эту теоритическую муть довольно сложно, так-что соберём всё сказанное под один колпак и напишем небольшое приложение. Здесь я запрашиваю у системы информацию по GUID’у класса "Контролёры жёстких дисков". В инклуде эта переменная значится как GUID_DEVCLASS_HDC . Дальше, подставив в SPDRP-константу соответствующие значения, получаю: имя, адрес на шине PCI, и вендора обнаруженных устройств. Поиграйтесь с этой константой и получите информацию различного рода:

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

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

Устранение проблем с Setupapi.app.log — как скачать и исправить

Файлы Log, такие как setupapi.app.log, считаются разновидностью файла Текст (Журнал). Они соотносятся с расширением LOG, разработанным компанией Scooter Software для Beyond Compare 4.2.10.23938.

Файл setupapi.app.log впервые был выпущен для ОС Windows Vista 11/08/2006 с Windows Vista. Датой самого последнего выпуска файла для Beyond Compare 4.2.10.23938 является 05/31/2019 [версия 4.2.10.23938]. Файл setupapi.app.log включен в пакет ПО в Windows 10, Windows 7 и Windows Vista.

Ниже приведены исчерпывающие сведения о файле, инструкции для простого устранения неполадок, возникших с файлом LOG, и список бесплатных загрузок setupapi.app.log для каждой из имеющихся версий файла.

Рекомендуемая загрузка: исправить ошибки реестра в WinThruster, связанные с setupapi.app.log и (или) Beyond Compare.

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Обзор файла

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Что такое сообщения об ошибках setupapi.app.log?

Общие ошибки выполнения setupapi.app.log

Ошибки файла setupapi.app.log часто возникают на этапе запуска Beyond Compare, но также могут возникать во время работы программы. Эти типы ошибок LOG также известны как «ошибки выполнения», поскольку они возникают во время выполнения Beyond Compare. К числу наиболее распространенных ошибок выполнения setupapi.app.log относятся:

• Не удается найти setupapi.app.log.
• setupapi.app.log — ошибка.
• Не удалось загрузить setupapi.app.log.
• Ошибка при загрузке setupapi.app.log.
• Не удалось зарегистрировать setupapi.app.log / Не удается зарегистрировать setupapi.app.log.
• Ошибка выполнения — setupapi.app.log.
• Файл setupapi.app.log отсутствует или поврежден.

Программа: C:\Windows\inf\setupapi.app.log

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

В большинстве случаев причинами ошибок в LOG являются отсутствующие или поврежденные файлы. Файл setupapi.app.log может отсутствовать из-за случайного удаления, быть удаленным другой программой как общий файл (общий с Beyond Compare) или быть удаленным в результате заражения вредоносным программным обеспечением. Кроме того, повреждение файла setupapi.app.log может быть вызвано отключением питания при загрузке Beyond Compare, сбоем системы при загрузке или сохранении setupapi.app.log, наличием плохих секторов на запоминающем устройстве (обычно это основной жесткий диск) или заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

Как исправить ошибки setupapi.app.log — 3-шаговое руководство (время выполнения:

Если вы столкнулись с одним из вышеуказанных сообщений об ошибке, выполните следующие действия по устранению неполадок, чтобы решить проблему setupapi.app.log. Эти шаги по устранению неполадок перечислены в рекомендуемом порядке выполнения.

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Восстановление системы» и нажмите ENTER.
3. В результатах поиска найдите и нажмите «Восстановление системы»
4. Введите пароль администратора (при необходимости).
5. Следуйте инструкциям мастера восстановления системы, чтобы выбрать соответствующую точку восстановления.
6. Восстановите компьютер к этому образу резервной копии.

Если на этапе 1 не удается устранить ошибку setupapi.app.log, перейдите к шагу 2 ниже.

Шаг 2. Если вы недавно установили приложение Beyond Compare (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Beyond Compare.

Чтобы удалить программное обеспечение Beyond Compare, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Удалить» и нажмите ENTER.
3. В результатах поиска найдите и нажмите «Установка и удаление программ»
4. Найдите запись для Beyond Compare 4.2.10.23938 и нажмите «Удалить»
5. Следуйте указаниям по удалению.

После полного удаления приложения следует перезагрузить ПК и заново установить Beyond Compare.

Если на этапе 2 также не удается устранить ошибку setupapi.app.log, перейдите к шагу 3 ниже.

Beyond Compare 4.2.10.23938

Шаг 3. Выполните обновление Windows.

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

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Обновить» и нажмите ENTER.
3. В диалоговом окне Центра обновления Windows нажмите «Проверить наличие обновлений» (или аналогичную кнопку в зависимости от версии Windows)
4. Если обновления доступны для загрузки, нажмите «Установить обновления».
5. После завершения обновления следует перезагрузить ПК.

Если Центр обновления Windows не смог устранить сообщение об ошибке setupapi.app.log, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.

Если эти шаги не принесут результата: скачайте и замените файл setupapi.app.log (внимание: для опытных пользователей)

Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла setupapi.app.log. Мы храним полную базу данных файлов setupapi.app.log со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Beyond Compare . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

1. Найдите версию операционной системы Windows в нижеприведенном списке «Загрузить файлы setupapi.app.log».
2. Нажмите соответствующую кнопку «Скачать», чтобы скачать версию файла Windows.
3. Скопируйте этот файл в соответствующее расположение папки Beyond Compare:

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