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

Ни для кого уже не секрет, что информация о разного рода активности многочисленных компонентов операционной системы попадает в реестр и файлы в виде записей заданного формата. При этом, информация эта нередко содержит чувствительные пользовательские данные: историю посещенных браузером страниц, кеш данных программ, информацию о подключаемых устройствах и многое многое другое. Во основном журналирование обеспечивается функциональными особенностями пользовательских программ, которые имеют встроенные алгоритмы сохранения истории операций, отчасти это возможно благодаря архитектурным особенностям ядра/HAL операционной системы, которые, производя конфигурирационные действия с устройствами, сохраняют информацию о последних в виде записей в системном реестре. Из всего многообразия подобной информации, в рамках данной статьи нас будет интересовать исключительно история использования USB устройств.

Следы подключения USB устройств, содержащиеся в виде различных данных в файлах/реестре, принято называть артефактами.

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

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

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

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

Перечисление (энумерация) USB устройств

Поскольку я сам в данном вопросе «плаваю», перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:

1. Нумерование устройства;
2. Установка драйвера устройства;

Ядро (?) инициирует к вновь подключенному устройству серию запросов GET_DESCRIPTOR с различными типами запрашиваемых дескрипторов (Device, Configuration, LangID, iProduct). Запросы опрашивают устройство на предмет наличия серии дескрипторов, представляющих собой структуры данных, описывающие возможности USB устройства.

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

Отсюда следует вывод, что любое USB-устройство должно уметь реагировать на запросы от хоста и иные события на шине. В ответ на подобного рода запросы, микрокод устройства возвращает из ПЗУ требуемую информацию. Данные, возвращаемые устройством в ответ на запросы разнообразных дескрипторов, являются важными для операционной системы, поскольку именно часть этих данных представляет собой различного рода идентификаторы, используемые системой в дальнейшем в процессе нумерования устройства. Давайте приведем наиболее значимую информацию:

Наверняка многие из перечисленных в таблице полей Вам уже встречались в составе значений различных параметров в том же Диспетчере устройств либо в разнообразных системных лог-файлах.
Помимо стандартных дескрипторов, существуют еще так называемые Дескрипторы Microsoft (Microsoft OS Descriptors, MOD), которые содержат специфичную для ОС Windows информацию. Для поддержки производителей, чьи устройства из-за функциональных особенностей не подходят под стандартный набор классов, Майкрософт разработала набор специальных классов и собственных дескрипторов. Пользовательское и системное ПО может идентифицировать устройства, принадлежащие к разработанным Майкрософт классам устройств путем опроса устройства на предмет наличия дескрипторов Microsoft. Помимо поддержки описанных классов устройств, дескрипторы Microsoft имеют и иное применение, например при помощи них можно использовать память устройства для хранения файлов помощи, иконок, списков адресов URL, настроек системного реестра и других данных, используемых для обеспечения прозрачности установки и достижения смежных целей. Устройства, поддерживающие дескрипторы Microsoft, должны хранить специальный строковый дескриптор в прошивке с фиксированным индексом 0xEE. Операционные системы Windows XP SP1 и более поздние запрашивают этот строковый дескриптор у устройства при первом его подключении.

Таким образом, каждое USB устройство должно иметь, как минимум: идентификатор производителя (VID, Vendor ID), идентификатор продукта (PID, Product ID), и серийный номер (Serial). На основе этих параметров формируется уникальный идентификатор оборудования, тем самым обеспечивается уникализация USB-устройства в пределах системы и вносятся изменения в конфигурацию оборудования.

Более того, использование пары VID/PID в дескрипторе любого USB-устройства предписывается спецификацией, согласно которой данные параметры должны быть уникальны для каждой модели устройства. Ну это, опять же, все в теории, а на практике пару раз встречались экземпляры устройств, при работе с которыми становилось очевидно, что значения VID/PID взяты произвольно, либо взяты свободные значения (!) из реестра производителей. Понятно кому выгодно подобным заниматься Ну это скорее редко встречающаяся ситуация, когда производителю хочется сэкономить на внесении в реестр производителей.
Затем, после того, как у устройства запрошены ключевые параметры, для USB устройства создан уникальный идентификатор HardwareID (CompatibleID), однозначно идентифицирующий устройство/класс устройства. Драйвер USB-концентратора уведомляет специализированный модуль ядра под названием Диспетчер Plug-n-Play (PnP Manager) о новом устройстве. Диспетчер PnP получает идентификаторы HardwareID и CompatibleID устройства и пытается обнаружить устройства с аналогичными идентификаторами HardwareID/CompatibleID. В этот момент в системе создается узел устройства (devnode), что является, по сути, первым отпечатком USB устройства в системе. Если похожее устройство найдено, то производится установка соответствующих драйверов в автоматическом режиме, если же не найдено, то Диспетчер PnP получается уведомление о новом устройстве и далее действует по определенным правилам, описание которых выходит за рамки данного материала.

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

Эксперимент

В Сети много противоречивой информации относительно истории подключения USB, поэтому давайте проведем собственный эксперимент по выявлению всех возможных системных местоположений, формирующих историю USB подключений. С целью выявления следов подключения USB стоит отследить абсолютно все изменения, происходящие в системе в момент подключения USB устройства. С этой целью на просторах Сети была найдена замечательная утилита под названием SysTracer, которая обладает всем необходимым функционалом. Утилита настолько проста и функциональна, что во многих случаях она окажется незаменимым средством в руках специалиста, поскольку предоставляет возможность сделать КРАЙНЕ полезное действие: создать мгновенный снимок (snapshot) состояния ключевых компонентов системы, таких как реестр и файлы. В качестве системы я использовал чистую инсталляцию Windows 7 Professional, при этом главным требованием было отсутствие каких-либо подключений внешних носителей. Итак, делаем снимок чистой системы, затем вставляем тестовую USB-флешку SanDisk Cruzer mini 1.0Gb и через некоторое время делаем второй снимок. Встроенными средствами утилиты SysTracer сравниваем полученные образы с выводом отчета. В итоге у нас получился некий набор системных изменений, среди которых мы попытаемся выбрать именно те, которые могут относиться к следам подключения USB устройств. Выбранный мною метод имеет и свои недостатки, поскольку наблюдения за активностью системы применительно к USB устройствам не проводилось «в динамике», то есть мы не работали с открытыми с подключаемого носителя файлами (.docx/.xlsx) в различных пользовательских приложениях, а это могло привести к тому, что мы можем упустить факты попадания частей информации с USB-носителя в файлы подкачки, различные временные файлы кеша и файлы иного назначения. Поэтому материал, скорее всего, потребует последующей доработки.

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

История в файлах

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

• %Windir%setupact.log — содержит сообщения отладки от инсталятора драйверов [режима ядра], сопровождающего процесс установки устройства;
• %Windir%infsetupapi.app.log — содержит сообщения процесса инсталляции приложений;
• %Windir%infsetupapi.dev.log — содержит сообщения процесса инсталляции устройств;

Начнем с файла setupapi.dev.log, по информации из которого мы можем отследить всю историю подключения к компьютеру любых устройств (включая USB). Я приведу фрагмент инсталляции упомянутого мной флеш-накопителя SanDisk Cruzer mini. Сразу предупрежу, что в файле setupapi.dev.log очень много информации, поэтому для поиска в ручном режиме можно отрыть его встроенным Блокнотом и при помощи комбинации клавиш Ctrl+F выполнить поиск словосочетания Device Install или USBVID_. Это не самый удобный метод, тем не менее иметь его в арсенале определенно следует. Вот что удалось обнаружить:

Как можно заметить, подключении нового устройства в файле выделено в секцию, которая начинается с ключевой фразы Boot Session. Сессия загрузки, похоже, определяет к какой именно из многочисленных загрузок ОС относятся все входящие в неё действия. Затем, в строке (4), содержащей Device Install, нас может заинтересовать значение USBVID_0781&PID_5150200411009307E9614ADD, определяющее идентификатор устройства. Фактические же дату и время установки устройства мы можем определить по строке, начинающейся со словосочетания Section start YYYY/MM/DD HH:MM:SS.MMM, определяющего начало секции инсталляции устройства.
Далее по тексту мы можем наблюдать не менее интересную информацию:

Тут мы видим, что на начальном этапе инсталляции устройства утилита drvinst.exe создает узел драйвера, о чем красноречиво говорит нам строка Created Driver Node. Я так понимаю, запись об узле устройства создается в реестре. Тут же присутствует поле DevDesc, которое указывает нам на наименование инсталлируемого устройства Запоминающее устройство для USB. Здесь же, в строке 3, мы можем наблюдать HardwareID, содержащий значение USBClass_E0&SubClass_01&Prot_03, которое идентифицирует класс устройства. В этот самый момент в реестре, с использованием строки HardwareID создается уникальный ключ, описывающий устройство.

История в реестре

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

HKLMSOFTWAREMicrosoftWindows Portable DevicesDevices

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

Начиная с Windows XP в систему был включен новый класс устройств — портативные устройства Windows (Windows Portable Devices, WPD), который подразумевал расширение функций взаимодействия с мобильными устройствами, позволял использование программного интерфейса WPD и объектной модели автоматизации WPD.

Подключи и имеют следующую структуру: WPDBUSENUMROOT#UMB#2&37C186B&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#. Как мы видим, подключ однозначно указывает нам на вновь подключенный накопитель от компании SanDisk, содержит в имени название производителя, модели, ревизию, серийный номер устройства.

HKLMSYSTEMCurrentControlSetControlDeviceClasses

В этом ключе находятся все глобальные уникальные идентификаторы (GUID, Globally Unique IDentifier) классов устройств.

Начиная с Windows 2000, с целью структурирования привязок оборудования в системном реестре, были введены так называемые идентификаторы классов устройств (Device Classes GUID).

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

Оказывается при инсталляции одного-единственного USB устройства создается сразу несколько подключей, принадлежащих разным классам. Внутри подключа {53f56307-b6bf-11d0-94f2-00a0c91efb8b} создаются подключи, в имени содержащие путь ##?#USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1#200411009307E9614ADD&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}
Аналогичным образом, подключ {53f5630d-b6bf-11d0-94f2-00a0c91efb8b}, относящийся к классам томов, содержит подключи с именем каждого тома, который в данный момент смонтирован в системе, а USB-накопитель у нас определенно прописывается в системе в качестве тома. Выглядит запись следующим образом: ##?#STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#{53F56307-B6BF-11D0-94F2-00A0C91EFB8B}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
Однако, следует учитывать, что запись в ключе Volume GUID присутствуют в реестре только когда устройство подключено, при отключении том демонтируется, поэтому система записи удаляет!

HKLMSystemCurrentControlSetEnum

Абсолютно все без исключения, когда-либо пронумерованные устройства, подключаемые к компьютеру и конфигурируемые PnP-менеджером, отображаются в ветви реестра HKLMSystemCurrentControlSetEnum
Если же сфокусироваться только лишь на интересующих нас в данном контексте USB-устройствах, то стоит обратить внимание на подключи с именами USB, USBSTOR, STORAGE и WpdBusEnumRoot.

HKLMSystemCurrentControlSetEnumUSB

Подключ USB содержит подключи, описывающие вообще все пронумерованные USB-устройства системы. В нем располагается иерархия вложенности, формируемая на основе параметров устройств, таких как HardwareID и InstanceID. Обычно подобная иерархия имеет вид HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSB<hardware id><instance id>, где InstanceID обычно принимает значение серийного номера устройства, либо других параметров в случае отсутствия последнего. К примеру, тут может располагаться подключ вида VID_15A9&PID_002B, который имеет уже свою собственную вложенную иерархию параметров, однозначно описывающих устройство.

соответственно в подключе 0123456789ABCDEF (серийный номер) мы можем видеть детальную информацию по устройству:

HKLMSystemCurrentControlSetEnumUSBSTOR

В подключе USBSTOR отображаются подключаемые накопители с интерфейсом USB. Формат вложенных подключей может быть близок к следующему: Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1.

HKLMSystemCurrentControlSetEnumSTORAGE

В подключе STORAGE тоже содержатся артефакты по истории подключения USB устройств. В нем содержится подключ Volume, который, в свою очередь, содержит подключи всех накопителей, подключенных в системе в качестве томов. Подключи формируются в форме _??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer_Mini&Rev_0.1#200411009307E9614ADD&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

HKLMSystemCurrentControlSetEnumWpdBusEnumRoot

Подключ WpdBusEnumRoot имеет вложенный подключ UMB, который, в свою очередь, содержит подключ с именем 2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_SANDISK&PROD_CRUZER_MINI&REV_0.1#200411009307E9614ADD&0#

HKLMSYSTEMMountedDevices

В реестре присутствует ключ HKLMSYSTEMMountedDevices, который содержит подключи, описывающие все когда-либо смонтированные в системе накопители. Выглядят они как ??Volume{0db0a220-6908-11e5-9e0b-005056c00008}, имеют тип REG_BINARY и содержат в своем значении информацию (UTF) о пути, наименовании и GUID накопителя. К тому же, в этом же ключе присутствуют такие интересные параметры как DosDevicesX:, где буква (X:) после обратного слеша означает имя тома. Параметров может быть несколько, обычно по количеству подключенных в системе букв дисков. У всех этих параметров значением будет путь к последнему сопоставленного с данной литерой физическому устройству, опять же в вышеприведенном формате.

HKU{SID}SoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2

Куст HKEY_USERS предназначен для хранения данных, специфичных для конкретного пользователя, зарегистрированного в системе. Соответственно, в первом уровне вложенности перечисляются SID пользователей, которые для обычных интерактивных пользователей, традиционно, принимают значения вида S-1-5-21-3284554473-1169922948-3718263881-1000. В ключе HKEY_USERS{SID-пользователя}MicrosoftWindowsCurrentVersionExplorerMountPoints2 располагаются GUID накопителя, что фактически раскрывает факт подключения дискового устройства.

Добрый день! Уважаемые читатели и гости одного из крупнейших 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 Servicemaintenanceservice.exe»
Тип службы: служба режима пользователя
Тип запуска службы: Вручную
Учетная запись службы: LocalSystem

Имя службы: Microsoft Edge Elevation Service
Имя файла службы: «C:Program Files (x86)MicrosoftEdgeApplication80.0.361.111elevation_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. В следующей таблице перечислены важные файлы журналов на этом этапе установки.

BTSourcesPantherPreGatherPnPList.logСодержит сведения о начальном захвате устройств, которые находятся в системе на этапе downlevel.

Вы также можете увидеть файл журнала в 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. Дополнительные сведения об этих программах см. в справке командной строки. В следующих примерах показано, как можно использовать эти программы:

Источник

Adblock
detector

Включения ведения журнала установщика Windows

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

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

Запись реестра в этой статье действительна для всех Windows операционных систем.

Ведение журнала установщика Windows

Windows Установщик может использовать ведение журнала, чтобы помочь в устранении неполадок при установке пакетов программного обеспечения. Этот журнал включен путем добавления ключей и значений в реестр. После того как записи были добавлены и включены, можно повторить установку проблемы и Windows установщик будет отслеживать ход и размещать его в папке Temp. Имя файла нового журнала является случайным. Однако первыми буквами являются Msi, а имя файла имеет расширение журнала. Чтобы найти папку Temp, введите следующую строку в командной строке:

Чтобы включить Windows установки вручную, см. в следующем разделе.

Включить Windows установки вручную

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

Чтобы включить Windows установки самостоятельно, откройте реестр с помощью Regedit.exe, а затем создайте следующий подкай и клавиши:

Буквы в поле значения могут идти в любом порядке. Каждая буква включает отдельный режим ведения журнала. Фактическая функция каждой буквы следующим образом для версии MSI 1.1:

Это изменение должно использоваться только для устранения неполадок и не должно быть оставлено на месте, так как оно будет иметь негативные последствия для производительности системы и дискового пространства. При каждом использовании элемента Добавить или Удалить программы в панели управления создается новый файл Msi*.log. Чтобы отключить ведение журнала, удалите значение реестра журнала.

Включить Windows установки с помощью групповых политик

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

Дважды щелкните журнал журнала и нажмите кнопку Включено. В поле Ведение журнала введите параметры, которые необходимо ввести в журнал. Файл журнала Msi.log отображается в папке Temp тома системы.

Дополнительные сведения о журнале MSI см. в Windows Help. Для этого выберите поиск с помощью журнала msi фразы, а затем выберите параметры управления для компьютеров с помощью групповой политики.

Добавление x-флага доступно в Windows Server 2003 и более поздних операционных системах, в MSI-перераспределяемой версии 3.0 и в более поздних версиях MSI, которые можно перераспределить.

Источник

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. В следующей таблице перечислены важные файлы журналов на этом этапе установки.

BTSourcesPantherPreGatherPnPList.log Содержит сведения о начальном захвате устройств, которые находятся в системе на этапе downlevel.

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

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

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

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

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

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

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

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

Этап отката

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

Источник

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Системный монитор (Sysmon)

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

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

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\.”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

Источник

Вертим логи как хотим ― анализ журналов в системах Windows

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

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

Как зайти в журнал событий в Windows 10

Запуск утилиты осуществляется несколькими способами. Первый подразумевает использование окна «Выполнить». Для этого необходимо:

А второй требует использования панели управления, где требуется:

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

В левой колонке расположены журналы событий. Они уже отсортированы по разделам. Что облегчает работу пользователя. Наибольший интерес представляет раздел «Журналы Windows», состоящий из категорий:

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

Где находится журнал событий Windows

Физически Журнал событий представляет собой набор файлов в формате EVTX, хранящихся в системной папке %SystemRoot%/System32/Winevt/Logs.

Хотя эти файлы содержат текстовые данные, открыть их Блокнотом или другим текстовым редактором не получится, поскольку они имеют бинарный формат. Тогда как посмотреть Журнал событий в Windows 7/10, спросите вы? Очень просто, для этого в системе предусмотрена специальная штатная утилита eventvwr.

Нюансы работы в журнале

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

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

Регистрация сервера DCOM не выполнена за отведенное время ожидания

Поиск описания потребует выхода в интернет и посещения сайта Microsoft. Или иных ресурсов, предоставляющих подобную информацию.

Стоит упомянуть, что наличие ошибок – нормальное явление ОС. Любые, даже самые незначительные сбои вносятся в реестр. Так что не стоит переживать, обнаружив их в журнале.

Что такое Журнал событий и для чего он нужен

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

Как очистить журнал событий в Windows 10

Среди способов, как почистить журнал событий в Windows 10, можно выделить 5 основных.

Вручную

Этот способ весьма прост. Он не требует специальных навыков или дополнительного софта. Все что необходимо, это:

Как вы, наверное, заметили, это самый простой способ. Однако некоторые ситуации требуют прибегнуть к иным методам.

Этот способ также позволяет быстро провести очистку. Для его реализации вам потребуется код:

@echo off FOR /F «tokens=1,2*» %%V IN (‘bcdedit’) DO SET adminTest=%%V IF (%adminTest%)==(Access) goto theEnd for /F «tokens=*» %%G in (‘wevtutil.exe el’) DO (call :do_clear «%%G») goto theEnd :do_clear echo clearing %1 wevtutil.exe cl %1 goto :eof :theEnd

Его необходимо использовать в следующем алгоритме:

После этого все отчеты будут удалены.

Через командную консоль

Очистить журнал событий в Windows 10 можно и при помощи данного инструмента. Для этого потребуется:

for /F “tokens=*” %1 in (‘wevtutil.exe el’) DO wevtutil.exe cl “%1″

Через PowerShell

PowerShell – более продвинутая версия командной строки. Очистка журнала с его помощью проводится аналогичным образом. За исключением вводимой команды. В данном случае она имеет следующий вид:

wevtutil el | Foreach-Object

Вертим логи как хотим ― анализ журналов в системах Windows

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

findstr «Fail» *.log >> fail.txt

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

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Для получения списка доступных системных журналов можно выполнить следующую команду:

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

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

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

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

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

SELECT extract_token(text, 0, ‘ ‘) as date, extract_token(text, 1, ‘ ‘) as time, extract_token(text, 2, ‘ ‘) as action, extract_token(text, 4, ‘ ‘) as src-ip, extract_token(text, 7, ‘ ‘) as port FROM ‘C:WindowsSystem32LogFilesFirewallpfirewall.log’ WHERE action=’DROP’ AND port=’3389′ ORDER BY date,time DESC

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

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManagerOperational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%System32WinevtLogsMicrosoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%test.evtx.

Данные будем получать таким запросом:

SELECT timegenerated as Date, extract_token(strings, 0, ‘|’) as user, extract_token(strings, 2, ‘|’) as sourceip FROM ‘%temp%test.evtx’ WHERE EventID = 21 ORDER BY Date DESC

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

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

SELECT TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,’T’), ‘yyyy-MM-dd’)) AS Date, COUNT(*) AS FROM ‘C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsMessageTracking*.LOG’ WHERE (event-id=’RECEIVE’) GROUP BY Date ORDER BY Date ASC

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.

Свойства событий

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

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

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

Как открыть

Для запуска нажмите «Win+R», пропишите «control». Далее:

Другой способ

Нажмите (Win+R), пропишите «eventvwr.msc».

Откроется окно утилиты. Слева расположены журналы:

Средняя колонка отображает события. Правая — действия. Ниже — сведения о выбранной записи.

Работа происходит с разделом «Журналы», в который входят такие категории:

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

Отметьте пункты как на скриншоте:

Утилита отфильтрует записи.

Просмотрите сообщение:

Как использовать просмотр событий Windows для решения проблем с компьютером

05.06.2014 windows | для начинающих
Тема этой статьи — использование малознакомого большинству пользователей инструмента Windows: Просмотр событий или Event Viewer.

Для чего это может пригодиться? Прежде всего, если вы хотите сами разобраться что происходит с компьютером и решить различного рода проблемы в работе ОС и программ— данная утилита способна вам помочь, при условии, что вы знаете, как ее использовать.

Дополнительно на тему администрирования Windows

Как запустить программу Просмотра событий

Чтобы осуществить запуск программы Просмотр событий нужно:

Также данная программа открывается через папку Администрирование в меню Пуск.

Важно знать, что все события распределены по категориям – к примеру, в категории Приложения размещены события приложений, в категории Система находятся системные новости. Если же на ПК настроен анализ событий безопасности (аудит событий входа в систему), то сообщения аудита поступают в категорию Безопасность.

Получить дополнительную информацию о событиях

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

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

Источник

USB device history is a great source of evidence during forensics analysis. In windows, there are more specific locations where reveal USB device history and various data related to USB devices. In most of these locations, we can see either a Windows registry key or a bunch of windows registry keys or a log file. SetupAPI files are great example log files to this.

The SetupAPI log files mainly split into two types based on log entries.

1. setupapi.dev.log:

This log file contains log entries related to the device and device driver installations

2. setupapi.app.log:

This log file contains log entries related to the application installations.

The first log file, setupapi.dev.log, can be used to determine the temporal usage of specific USB devices connected to a Windows Machine. They store all events related to drivers and devices loaded on to the system with timestamps and driver information.

You can see this log file in the below-mentioned paths in your windows machines.

In Windows XP machines,

C:Windowssetupapi.dev.log

In Windows 7/8/10,

C:Windowsinfsetupapi.dev.log

After analyzing this setupapi.dev.log file, you can extract some great artifacts related to your windows machine and USB devices you or someone else plugged into your machine. Briefly following artifacts can be extracted from this log file.

1. OS version:
The current version of your windows operating system installed on your machine.

2. Service Pack:
Windows operating system service pack or the windows update, often combining previously released updates.

3. Suite:

4. Product type:

5. Architecture:

6. Boot sessions:
this is a timestamp data related to system boot time.

all of the above artifacts are formated as follows in the setupapi.dev.log file.

[Device Install Log]
     OS Version = 6.1.7601
     Service Pack = 1.0
     Suite = 0x0100
     ProductType = 1
     Architecture = amd64

[Boot Session: 2020/12/29 21:47:17.453]

7. USB vendor Ids:

using these artifacts, you have access to determine,

1. the external devices were plugged in for the first time
2. a malicious driver was loaded onto the system
3. what drivers were loaded for an unknown device and its functionality.
4. providing a device was successfully installed and accessible.

Basically, the full log entry is based on three sections. First, it has a section header, then the body of the log entry, lastly, the foot of the log entry. With these three sections, we have a complete log entry about what happened after we plugged a USB device into our windows machine and we have a lot of data about behind the scenes.

we can visually represent this as below,

>> [Header section]
>>  [body]
>> [Foot]

The section header is a combination of three fields.
1. section_title = all header sections have a section title and it provides a title for the operation that is associated with the section.

2. instance_identifier = provides an identifier that, ideally, uniquely, identifies the instance of the operation.

3. timestamp subfields = provides the time data related to the start of the section.
the timestamp format they used to enter the log is as follows.
yyyy/mm/dd/ hh:mm:ss.sss

yyyy = year as a four-digit number
mm = month as a two-digit number
dd = day as a two-digit number
hh = hour as a two-digit number
ss = seconds as a two-digit number
sss = milliseconds as a three-digit number.

We can represent the format of the section header as follows.

>> [section_title instance_identifier]
>> [start timestamp field]

If we provide some examples for this section header, it looks like follows,

>>>  [Device Install (Hardware initiated) - STORAGEVolumeSnapshotHarddiskVolumeSnapshot19]
>>>  Section start 2020/12/30 20:04:13.174

>>>  [Import Driver Package - C:Program FilesMicrosoft OfficeOffice15OneNote\prnSendToOneNote15_Win7.inf]
>>>  Section start 2020/12/30 19:56:51.549

>>>  [SetupCopyOEMInf - C:WindowsSystem32DriverStoreFileRepositorywdcsam.inf_amd64_neutral_2efd3a3b82aeb664wdcsam.inf]
>>>  Section start 2020/12/29 23:25:47.511

In this scenario, it’s worth mentioning that I analyzed Alan’s(older pc running windows 7. I named it Alan.) setupapi.dev.log file with Windows 10 setupapi.dev.log file and the basic structure of the log entries are very similar.

Body:

you can see either zero or more log entries in this section. entry_prefix, time_stamp, event_ category, indentation, formatted_message fields are contained in the basic structure of the body section. This can be represented as follows.

>> [entry_prefix time_stamp event_category indentation formatted_message]

Especially note that the maximum length, in characters, of a section body log entry is 336.

There are a lot of signs and symbols to know in this section. To read and understand the log entries in a meaningful way, you need to know about those signs and symbols and their meanings.

In the entry_prefix field, you can see the following symbols and this field is used to identify the type of the message. This field is always present.

!!! = An error message
! = A warning message
= An information message

time_stamp field indicates the system time when the logged event occurred and it is very similar to the timestamp field you saw in the header section. in the body section, the timestamp field is an optional field. by default, in a lot of log entries, you won’t see a timestamp field. In the following two examples, you can see a message without the timestamp and another message with the timestamp. A function called SetupWriteTextLog has the responsibility to write the time_stamp field in the log entries. In another post, I will cover the SetupWriteTextLog function.

time_stamp = 21:48:11.429

     ndv: Waiting for previous device install to complete. 21:48:11.429

no time_stamp field.

!!!  inf:                          Failed to load the OLE Control 'C:Windowssystem32igdumd32.dll'.

event_category field indicates the category of operation that made the log entry. this field is usually present but some log entries haven’t an event_category field. To identify the event_category field in a meaningful way, we have to know below strings and symbols and their meanings.

...: = vendor-supplied operation

bak: = backup data

cci: = class installer or co-installer operation.
Eg:

     cci:                NdisCoinst: Connection name is Local Area Connection

cpy: = copy files
Eg:

     cpy:      Policy is set to make all digital signatures equal.

dvi: = Device installation
Eg:

     dvi:      Searching for hardware ID(s):

flq: = Manage file queues
Eg:

     flq:                          CopyFiles from an inbox inf.

inf: = Manage INF files
Eg:

     inf:                     {Install Inf Section [atapi_Inst] exit (0x00000000)}

ndv: = New device wizard
Eg:

     ndv:      Pruning file queue...

prp: = Manage device and driver propertises
reg: = Manage registry settings

set: = General setup
Eg:

     set: DIF_FIRSTTIMESETUP failed with 0xE000020E for class {25dbce51-6c8f-4a72-8a6d-b54c2b4fc835} (Mobile devices)

sig: = Verify digital signatures
Eg:

     sig:           FilePath = C:Windowsinfnetrasa.inf

sto: = Manage the driver store
Eg:

     sto:      Importing driver package into Driver Store:

ui: = Manage user interface dialog boxes

ump: = User-mode PnP manager
Eg:

     ump:      Server install process exited with code 0x00000000 21:59:40.489

indentation field is a sequence of zero or more indentation units(monospace strings). This is an optional field and in an indentation unit, we can see five spaces. As I mentioned earlier, SetupWriteTextLog supports changing the number of indentation units that are included in a log entry.

formatted_message field contains specific information about the log entry like what happened in that specific current time.

It is also worth mentioning that the log entries we can saw in the body section depend on two levels, event-level is the first one and category level is the second one. In a later post, I will cover more details about these settings. Also, indentations are applied to log entries in the body section to notify subsections from main sections.

As an example, we can see below log entries.

     inf: {SetupCopyOEMInf: C:WindowsINFoem14.inf} 21:59:38.975
     inf:      Driver Store location: C:WindowsSystem32DriverStoreFileRepositoryich78id2.inf_amd64_neutral_64bf4c4608ae7e8aich78id2.inf
     inf:      Published Inf Path: C:WindowsINFoem14.inf
     inf:      Opened INF: 'C:WindowsINFoem14.inf' ([strings])
     inf:      Saved PNF: 'C:WindowsINFoem14.PNF' (Language = 0409)
     inf:      Installing catalog ich78id2.cat as: oem14.CAT
!    inf:      Failed to install catalog - error ignored
!    inf:      Error 2: The system cannot find the file specified.
     inf:      OEM source media location: C:WindowsINF
     inf: {SetupCopyOEMInf exit (0x00000000)} 21:59:39.178

The Footer section is the closing section of a complete log entry. The footer section can represent in the following way with its fields. we can identify a footer section in an easy way because it started with the prefix <<<.

<<< [time_stamp Section end] or <<< [Section end time_stamp]
<<< [Exit Status(status)]           [Exit Status(status)]

The format of the status field is 0xhhhhhhhh where hhhhhhhh is an 8-digit hexadecimal number.

sometimes we can see the status field has clear meaningful words like SUCCESS. For example;
<<< [Exit status: SUCCESS]

The above mentioned, hexadecimal status field appear due to some failures or errors. for example,
<<< [Exit status: FAILURE(0xe0000203)]

0xe0000203 is the error code and it represents the error that occurred during the process. Also, note that above mentioned, [time_stamp Section end] format used in older windows machines like XP.

There are lots of information to tell you about these log files and how to read these log entries. I will cover more depth information about reading these logfiles because a lot more log entries aren’t reader-friendly.

Finally, why we need this data and informations and how to use this for real-world applications. We can easily identify issues, their type, what is the reason for those issues or a particular issue related to our windows machines by analyzing and convert these log files into a more reader-friendly way. creating a firmware like software or a program and apply that to a USB device to automatically diagnose the entire windows system to identify the errors and automatically provide the solutions for those errors. Analyzing and identifying these log files give you special benefits for creating applications like mentioned above.

I hope you enjoyed the post and Thank you for reading.