Setupapi dev log где находится windows 10
В случае возникновения ошибки, решение которой не найдено, для скорейшей локализации причины проблемы, нам необходимо собрать логи и системные файлы одним из следующих способов:
Данная утилита собирает все необходимые для изучения проблемы файлы. Сохраните архив на "Рабочий стол", разархивируйте содержимое и запустите файл RD1001.exe.
P.S.: Не забудьте приложить скриншот ошибки!
1) ЖУРНАЛ УСТАНОВКИ ДРАЙВЕРОВ
Начиная с v.4.0.0.0 от 31,08.2015 логирование установки Драйверов Рутокен ведется автоматически без указания каких либо дополнительных параметров, т.е. достаточно просто запустить установку и файлы с логами будут созданы.
Найти логи можно по адресу C:\Users\Пользователь\AppData\Local\Temp (обратите внимание что "по умолчанию" каталог AppData является скрытым)
(Для Windows XP: файл находится по адресу - C:\Documents and Settings\tester\Local Settings\Temp):
- Rutoken_Drivers_20150831110705.log - содержит краткую информацию об установке
- Rutoken_Drivers_20150831110705_000_rtDrivers.x64.msi.log - содержит подробную информацию об установке
- rt_000_rtDrivers.x64.msi_rollback.log - создается в случае невозможности установки (отката)
В конце имен файлов для удобства указаны дата и время установки: ГГГГММДДЧЧММСС
Все найденные в данной папке логи установки Драйверов Рутокен необходимо прикрепить к письму.
2) СИСТЕМНЫЙ ЛОГ
SetupApi.dev.log находится в директории C:\WINDOWS\INF\
(Для Windows XP: файл называется SetupAPI.Log)
3) ИНФОРМАЦИЯ О СИСТЕМЕ
Ф айл c информацией о системе собирается следующим образом: "Пуск" -> "Выполнить" -> msinfo32 -> "Файл" -> "Сохранить"
4) СКРИНШОТ ОШИБКИ
Для сохранения скриншота (картинки) экрана можно воспользоваться клавишей PrintScreen (PrtScr) или инструментом "Ножницы". Подробная инструкция о том, как сделать скриншот есть тут.
5) СПИСОК УСТАНОВЛЕННЫХ ПРИЛОЖЕНИЙ
Файл со списком установленных приложений можно собрать следующим образом:
"Пуск" -> "Выполнить" -> cmd Щелкните правой кнопкой мыши по найденному элементу и выберите в контекстном меню "Запуск от имени администратора"
В открывшемся окне введите последовательно две команды:
product get name, version
Для того чтобы сохранить этот список в текстовый файл, введите следующую команду:
Ни для кого уже не секрет, что информация о разного рода активности многочисленных компонентов операционной системы попадает в реестр и файлы в виде записей заданного формата. При этом, информация эта нередко содержит чувствительные пользовательские данные: историю посещенных браузером страниц, кеш данных программ, информацию о подключаемых устройствах и многое многое другое. Во основном журналирование обеспечивается функциональными особенностями пользовательских программ, которые имеют встроенные алгоритмы сохранения истории операций, отчасти это возможно благодаря архитектурным особенностям ядра/HAL операционной системы, которые, производя конфигурирационные действия с устройствами, сохраняют информацию о последних в виде записей в системном реестре. Из всего многообразия подобной информации, в рамках данной статьи нас будет интересовать исключительно история использования USB устройств.
Следы подключения USB устройств, содержащиеся в виде различных данных в файлах/реестре, принято называть артефактами.Система создает артефакты в момент обнаружения (инициализации) устройства (сменных накопителей, модемов, гаджетов, камер, медиаплееров и прч.) на шине компьютера. Дополнительным плюсом данного материала будет возможность сбора доказательной базы по факту неправомерного использования рабочей станции пользователя в корпоративной среде при помощи незадекларированных USB-устройств.
Не так давно в нашу жизнь вошел интерфейс USB, привнеся в неё довольно существенные изменения. Неожиданно многие вещи стали проще, отпала необходимость инсталляции устройства во внутренний интерфейсный разъем (шина), или внешний интерфейс, требующий перезагрузки станции для корректной инициализации устройства, да и сам процесс конфигурирования устройств стал, во множестве случаев, тривиальнее. На интерфейсе USB появились тысячи разнообразных по назначению устройств, которые достаточно было подключить к разъему на панели корпуса, после чего от момента подключения до состояния "готов к работе", порой проходили считанные минуты. Наряду с очевидными достоинствами: легкостью конфигурирования/использования, компактностью, функциональностью, подобные устройства сразу стали источником проблем как для безопасности персональных данных самого пользователя, так и безопасности корпоративных сред. Компактный, легко маскируемый "брелок" с интерфейсом USB может запросто явиться той ахиллесовой пятой, которая станет причиной "падения" гиганта корпоративной безопасности. Если порты USB в корпоративных рабочих станциях находятся без надлежащего контроля со стороны политик безопасности, то любое приспособление может запросто выступить в качестве средства для обхода периметра безопасности компании. И тут уж насколько хватит фантазии "взломщика", например, достаточно пронести на флешке свежий, не определяемый антивирусами вредоносный код и выполнить его (умышленно или нет), и вот вам уже прецедент, поскольку даже без локальных административных привилегий учетной записи пользователя сохраняется пространство для маневра. Не меньшую опасность представляют и USB-модемы, которые, в случае установки (а при использовании локальных/доменных политик по умолчанию это достигается достаточно просто), могут выступить в роли неконтролируемого канала передачи данных, по которому может осуществляться передача чувствительной корпоративной информации за пределы защищенного внутреннего периметра. При этом, даже декларируемые (заявленные/согласованные) пользовательские устройства (например, телефоны) могут содержать в своих микропрограммах или операционных системах уязвимости, которые, в случае эксплуатации, наносят вред не только владельцу, но и могут выступать в роли средства несанкционированного доступа к служебным данным. Поэтому, в случае возникновения инцидента информационной безопасности, связанного с эксплуатацией USB-устройств,
хронология действий с USB-устройствами может рассматриваться в качестве доказательной базы при возникновении инцидентов в сфере информационной безопасности.В связи со всем перечисленным, достаточно важно не только уметь ограничивать использование устройств, но и иметь доступ к истории USB подключений в системе. Этому вопросу и будет посвящена данная статья. Сразу оговорюсь, что весь список точек создания информации о подключении тех или иных устройство чрезвычайно обширен, поэтому по теме данной статьи мы будем рассматривать лишь историю использования USB устройств.
Перечисление (энумерация) USB устройств
Поскольку я сам в данном вопросе "плаваю", перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:
- Нумерование устройства;
- Установка драйвера устройства;
Ядро (?) инициирует к вновь подключенному устройству серию запросов GET_DESCRIPTOR с различными типами запрашиваемых дескрипторов ( Device , Configuration , LangID , iProduct ). Запросы опрашивают устройство на предмет наличия серии дескрипторов, представляющих собой структуры данных, описывающие возможности USB устройства.
Дескрипторы USB - структуры данных, которые позволяют операционной системе получить информацию об устройстве. Каждый дескриптор содержит информацию о устройстве в целом или отдельном элементе в рамках устройства.Отсюда следует вывод, что любое USB-устройство должно уметь реагировать на запросы от хоста и иные события на шине. В ответ на подобного рода запросы, микрокод устройства возвращает из ПЗУ требуемую информацию. Данные, возвращаемые устройством в ответ на запросы разнообразных дескрипторов, являются важными для операционной системы, поскольку именно часть этих данных представляет собой различного рода идентификаторы, используемые системой в дальнейшем в процессе нумерования устройства. Давайте приведем наиболее значимую информацию:
Название поля | Терминология Windows | Размер (байт) | Комментарий |
---|---|---|---|
idVendor | VID | 2 | Идентификатор производителя устройства. При присвоении идентификатора производителя, соответствующее числовое значение вносится в реестр производителей. |
idProduct | PID | 2 | Идентификатор продукта. Назначается производителем устройства. Product ID используется для дифференциации продуктов в рамках одного производителя. |
bcdDevice | REV | 2 | Идентификатор ревизии. Используется для дифференциации разных аппаратных модификаций в рамках одной модели устройства. Может использоваться при выпуске новой версии платы/контроллера/логики. |
bDeviceClass, bFunctionClass, bInterfaceClass | Class | 1 | Класс устройства. Используется для задания класса схожих устройств с общим набором идентичных свойств. |
bDeviceSubclass, bFunctionSubClass, bInterfaceSubclass | SubClass (SUB) | 1 | Подкласс устройства. Используется для задания подкласса схожих устройств в рамках класса. |
bDeviceProtocol, bFunctionProtocol, bInterfaceProtocol | Protocol (Prot, PROTO) | 1 | Протокол устройства. Используется для задания протокола для устройств в рамках класса и подкласса. |
iProduct | Product | ? | Текстовая строка-описатель продукта. Когда устройство подключено к компьютеру, данная информация отображается в Диспетчере устройств. |
iSerialNumber | Serial | ? | Серийный номер. Используется для уникализации абсолютно одинаковых устройств, например две одинаковых флешки. Назначается и поддерживается производителем устройства. Связанный механизм носит имя Сериализация. Сериализация так же участвует в уникальной идентификации устройства, поскольку добавляет еще один уровень уникальности. |
Наверняка многие из перечисленных в таблице полей Вам уже встречались в составе значений различных параметров в том же Диспетчере устройств либо в разнообразных системных лог-файлах.
Помимо стандартных дескрипторов, существуют еще так называемые Дескрипторы Microsoft (Microsoft OS Descriptors, MOD), которые содержат специфичную для ОС Windows информацию. Для поддержки производителей, чьи устройства из-за функциональных особенностей не подходят под стандартный набор классов, Майкрософт разработала набор специальных классов и собственных дескрипторов. Пользовательское и системное ПО может идентифицировать устройства, принадлежащие к разработанным Майкрософт классам устройств путем опроса устройства на предмет наличия дескрипторов Microsoft. Помимо поддержки описанных классов устройств, дескрипторы Microsoft имеют и иное применение, например при помощи них можно использовать память устройства для хранения файлов помощи, иконок, списков адресов URL, настроек системного реестра и других данных, используемых для обеспечения прозрачности установки и достижения смежных целей. Устройства, поддерживающие дескрипторы Microsoft, должны хранить специальный строковый дескриптор в прошивке с фиксированным индексом 0xEE . Операционные системы Windows XP SP1 и более поздние запрашивают этот строковый дескриптор у устройства при первом его подключении.
Более того, использование пары VID / PID в дескрипторе любого USB-устройства предписывается спецификацией, согласно которой данные параметры должны быть уникальны для каждой модели устройства. Ну это, опять же, все в теории, а на практике пару раз встречались экземпляры устройств, при работе с которыми становилось очевидно, что значения VID/PID взяты произвольно, либо взяты свободные значения (!) из реестра производителей. Понятно кому выгодно подобным заниматься :) Ну это скорее редко встречающаяся ситуация, когда производителю хочется сэкономить на внесении в реестр производителей.
Затем, после того, как у устройства запрошены ключевые параметры, для USB устройства создан уникальный идентификатор HardwareID ( CompatibleID ), однозначно идентифицирующий устройство/класс устройства. Драйвер USB-концентратора уведомляет специализированный модуль ядра под названием Диспетчер Plug-n-Play (PnP Manager) о новом устройстве. Диспетчер PnP получает идентификаторы HardwareID и CompatibleID устройства и пытается обнаружить устройства с аналогичными идентификаторами HardwareID/CompatibleID. В этот момент в системе создается узел устройства (devnode), что является, по сути, первым отпечатком USB устройства в системе. Если похожее устройство найдено, то производится установка соответствующих драйверов в автоматическом режиме, если же не найдено, то Диспетчер PnP получается уведомление о новом устройстве и далее действует по определенным правилам, описание которых выходит за рамки данного материала.
Эксперимент
В Сети много противоречивой информации относительно истории подключения USB, поэтому давайте проведем собственный эксперимент по выявлению всех возможных системных местоположений, формирующих историю USB подключений. С целью выявления следов подключения USB стоит отследить абсолютно все изменения, происходящие в системе в момент подключения USB устройства. С этой целью на просторах Сети была найдена замечательная утилита под названием SysTracer, которая обладает всем необходимым функционалом. Утилита настолько проста и функциональна, что во многих случаях она окажется незаменимым средством в руках специалиста, поскольку предоставляет возможность сделать КРАЙНЕ полезное действие: создать мгновенный снимок (snapshot) состояния ключевых компонентов системы, таких как реестр и файлы. В качестве системы я использовал чистую инсталляцию Windows 7 Professional, при этом главным требованием было отсутствие каких-либо подключений внешних носителей. Итак, делаем снимок чистой системы, затем вставляем тестовую USB-флешку SanDisk Cruzer mini 1.0Gb и через некоторое время делаем второй снимок. Встроенными средствами утилиты SysTracer сравниваем полученные образы с выводом отчета. В итоге у нас получился некий набор системных изменений, среди которых мы попытаемся выбрать именно те, которые могут относиться к следам подключения USB устройств. Выбранный мною метод имеет и свои недостатки, поскольку наблюдения за активностью системы применительно к USB устройствам не проводилось "в динамике", то есть мы не работали с открытыми с подключаемого носителя файлами (.docx/.xlsx) в различных пользовательских приложениях, а это могло привести к тому, что мы можем упустить факты попадания частей информации с USB-носителя в файлы подкачки, различные временные файлы кеша и файлы иного назначения. Поэтому материал, скорее всего, потребует последующей доработки.
Стоит так же учитывать, что в результате "ручной" чистки значений реестра, в некоторых ключах могут образовываться так называемые недействительные ссылки, которые, по идее, не должны вести к фатальным последствиям для работоспособности операционной системы, однако иметь в виду это стоит.История в файлах
После изучения изменений файловой части системных изменений, подтвердился факт того, что в операционной системе Windows 7 все действия над устройствами отражаются в следующих журнальных файлах:
Файл был разработан Microsoft для использования с программным обеспечением Office. Здесь вы найдете подробную информацию о файле и инструкции, как действовать в случае ошибок, связанных с setupapi.dev.log на вашем устройстве. Вы также можете скачать файл setupapi.dev.log, совместимый с устройствами Windows 10, Windows 10, Windows 8.1, Windows 7, Windows 7, Windows Vista, Windows Vista, Windows 8, которые (скорее всего) позволят решить проблему.
Совместим с: Windows 10, Windows 10, Windows 8.1, Windows 7, Windows 7, Windows Vista, Windows Vista, Windows 8
Исправьте ошибки setupapi.dev.log
Информация о файле
Основная информация | |
---|---|
Имя файла | setupapi.dev.log |
Расширение файла | LOG |
Тип | Text |
Описание | Log |
Программного обеспечения | |
---|---|
программа | Office 2010 |
Программного обеспечения | Office |
автор | Microsoft |
Версия программного обеспечения | 2010 |
подробности | |
---|---|
Размер файла | 1206501 |
Самый старый файл | 2017-04-24 |
Последний файл | 2017-05-10 |
Наиболее распространенные проблемы с файлом setupapi.dev.log
- setupapi.dev.log поврежден
- setupapi.dev.log не может быть расположен
- Ошибка выполнения - setupapi.dev.log
- Ошибка файла setupapi.dev.log
- Файл setupapi.dev.log не может быть загружен. Модуль не найден
- невозможно зарегистрировать файл setupapi.dev.log
- Файл setupapi.dev.log не может быть загружен
- Файл setupapi.dev.log не существует
setupapi.dev.log
Не удалось запустить приложение, так как отсутствует файл setupapi.dev.log. Переустановите приложение, чтобы решить проблему.
Проблемы, связанные с setupapi.dev.log, могут решаться различными способами. Некоторые методы предназначены только для опытных пользователей. Если вы не уверены в своих силах, мы советуем обратиться к специалисту. К исправлению ошибок в файле setupapi.dev.log следует подходить с особой осторожностью, поскольку любые ошибки могут привести к нестабильной или некорректно работающей системе. Если у вас есть необходимые навыки, пожалуйста, продолжайте.
Помните, прежде чем предпринимать какие-либо действия, связанные с системными файлами, сделайте резервную копию ваших данных!Шаг 1.. Сканирование компьютера на наличие вредоносных программ.
Файлы Windows обычно подвергаются атаке со стороны вредоносного программного обеспечения, которое не позволяет им работать должным образом. Первым шагом в решении проблем с файлом setupapi.dev.log или любыми другими системными файлами Windows должно быть сканирование системы на наличие вредоносных программ с использованием антивирусного инструмента.
Если по какой-либо причине в вашей системе еще не установлено антивирусное программное обеспечение, вы должны сделать это немедленно. Незащищенная система не только является источником ошибок в файлах, но, что более важно, делает вашу систему уязвимой для многих опасностей. Если вы не знаете, какой антивирусный инструмент выбрать, обратитесь к этой статье Википедии - сравнение антивирусного программного обеспечения.
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.
Цитата Oleno4ka: не может обновится , если открыто много программ, тормозит. » А если не запущено много - то обновляется??)) » |
не может обновится. пишет, мало места.
а если открыто на ноуте много программ, тогда тормозит.
вот это я имела ввиду.
спасибо за ссылку. пойду почитаю.
-------
Если я сказала, что не брала, значит не отдам. )))
Казбек, лог Windows Update получил с помощью команды.
В С:\Windows\panther\ никаких файлов нет, есть setupact.log и setuperr.log(пустой) только во вложенной папке С:\Windows\panther\UnattendGC, только оттуда приложил.
Файла C:\Windows\inf\setupapi.app.log тоже нет, только C:\Windows\inf\setupapi.dev.log.
Этих тоже нет в той папке, как я указал выше: C:\Windows\panther\PreGatherPnPList.log
C:\Windows\panther\PostApplyPnPList.log
C:\Windows\memory.dmp - тоже нет.
с помощью ISО сейчас попробую.
Обновился с ISO. после этого опять попросил кумулятивное обновление, но, что странно, установил его без ребута и без ошибок.
Однако после включения Insider снова как не приходил так и не приходит, сборка 14393.206 теперь. Говорит устройство обновлено.
И ещё Microsoft Solitaire Collection не запускается не помогает никакая его переустановка, сброс магазина и т.д., читал что это как раз в свежей инсайдерской исправили(игры с xbox)
Последний раз редактировалось Aura-AD, 30-10-2016 в 15:23 .
доброго времени суток . ноут с трудом обновился до юбилейной версии виндовс 10 (1607).
на диске С, осталось свободного места чуть больше 2 гиг. очень тормозил. хотела сама удалить виндовс олд, но мне все время виндовс 1607 запрещал это делать.
потом юбилейная версия сама, через день, предложила удалить старую версию виндовса, потому что мало места для новых обновлений.
ну, значит, удалилась старая версия, места свободного на диске С теперь чуть ли не 15 гиг.
и все бы хорошо, но, он теперь таааак медленно думает. запускается около 5 мин. (иногда и дольше), в мой компьютер заходит по 2-3 мин. (пишет, что проводник не отвечает) браузер запускает минут так 10, соответственно вкладки открываться тоже не с первой секунды.
скайп так вообще как бы и не существует первых 20 мин. работы ноута, медиапроигрыватель это вообще отдельная тема, или запускается через 5-7 мин., после нажатии на иконку, или подвисает так, что белеет все , даже диспетчер не помогает (он также не отвечает).
НО, после всех этих мук , по происшествии где-то неполного часа использования ноута, он как бы преображается. начинает вроде бы нормально работать, папочки открываются, музыка не запинается, текст плавно набирается сразу после нажатия клавиш, ничего уже не белеет, даже скайп запускается.
пишу сразу же, я не делаю все то что описывала одновременно. когда включаю ноут, то я либо первым делом захожу в инет, либо же только в скайп (так как сейчас, в виду некоторых обстоятельств, очень часто приходится ним пользоваться ) .
в чем собственно проблема ?
если можно , то по полочкам пожалуйста расскажите, ибо я полный чайник в этих вопросах.
-------
Если я сказала, что не брала, значит не отдам. )))
Есть wsus в локальной сети с хостами, подводных камней по способу доступа к wsus нет, все хосты обновляются нормально.
Но делают это разными путями.
Был парк 7 prof, у части хостов был прописан прокси в ie, а у части нет.
Затем обновили (поверх 7 по акции от M$) несколько машин с обоих частей до win 10, остальные контрольная группа остались на 7.
Теперь имеем:
1) на хостах с win 7 (с прокси в ie и без) и на обновленных машинах с win 10, где как сейчас в edge, так и на момент обновления не был прописан прокси в ie - трафик на wsus ходит мимо прокси, т.е. как надо,
2) на обновленных хостах с win 10, где как сейчас в edge, так и на момент обновления был прописан прокси в ie - трафик на wsus ходит через прокси, что есть факап.
Собственно, вопрос: как заставить группу хостов (2) ходить за обновлениями напрямую мимо прокси? При этом прокси для браузера на них должен быть настроен и работать обычным образом.
Конфигурация компьютера | |
Процессор: IntelCorei3-2100 CPU @ 3.10GHz, 3100 МГц, ядер: 2, логических процессоров: 4 | |
Материнская плата: MSI H61M-P21 (MS-7680) (B3.0) | |
Память: Kingston 99U5471-052.A00LF 8Gb DDR3-1333 DDR3 SDRAM; Samsung M378B5773DH0-CH9 2Gb DDR3-1333 DDR3 SDRAM | |
HDD: WDC Caviar Green WD10EARS-22Y5B1 ATA Device 1Т (1000 Gb), WDC Caviar Blue WD10EZEX-08M2NA0 ATA Device 1Т (1000 Gb) | |
Видеокарта: Sapphire Radeon HD 6570 650Mhz PCI-E 2.1 2048Mb 1600Mhz 128 bit DVI HDMI HDCP | |
Звук: VIA VT1708S VIA High Definition Audio | |
Блок питания: OCZ ZS Series Power Supply 550W 2014 г. | |
CD/DVD: ATAPI iHAS122 ATA Device | |
Монитор: LG FLATRON E2050 1600x900 | |
ОС: Microsoft Windows 7 Home Basic x86, Microsoft Windows 10 Home x64 . | |
Индекс производительности Windows: 5.9 | |
Прочее: Multi Flash Reader USB Device, Logitech HD Webcam C310 |
В настройках Edge есть возможность настраивать прокси.
Посмотрите. Может там что-то осталось-прописалось .
Как вариант, можно попробовать на одной из проблемных машин выставить IE браузером по умолчанию.
-------
Будь джентльменом, если есть удача. А нет удачи, джентльменов нет . Нажми .
Читайте также: