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

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

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

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

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

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

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

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

Обзор файла

Сведения о разработчике и ПО
Программа:	Beyond Compare 4.2.10.23938
Разработчик:	Scooter Software
Программное обеспечение:	Beyond Compare
Версия ПО:	4.2.10.23938

Сведения о файле
Размер файла (байты):	5560
Дата первоначального файла:	04/24/2017
Дата последнего файла:	12/21/2019

Информация о файле	Описание
Размер файла:	5.4 kB
Дата и время изменения файла:	2019:12:21 06:51:45+00:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beyond Compare 4.2.10.23938

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows Upgrade Troubleshooting Logs

Let’s discuss Windows Upgrade Troubleshooting Logs in this post. I have done several Windows upgrades without any issues. But in the real-world scenario, we are expected to have several Windows 10 deployment issues. Let’s check the Windows 10 Deployment Upgrade Process Logs. These log files are relevant for Windows 11 Upgrade Process as well.

Windows 11 deployment troubleshooting flow will help you to complete Windows 10 migrations. In this post, we will cover the Windows 11 logs related to the upgrading process. All these logs will help SCCM admins to troubleshoot various scenarios.

I have a new blog post about the SCCM Logs or SCCM log files in the following post. I would recommend reading that post to get more details about SCCM Log Files or SCCM Logs. This will surely help you with SCCM troubleshooting.

Windows Upgrade Troubleshooting Logs are spread across different folders. Depending on the deployment or failure scenarios, the Windows upgrade troubleshooting logs are located in different folders. Windows 10 deployment troubleshooting flow will surely help SCCM admins to resolve the most common issues.

Windows 10 Setup Process Flow – Windows Upgrade Troubleshooting Logs

Windows 10 setup scenario begins with completing a Windows setup on a new computer. This scenario is most common when SCCM admins create a golden image or reference image. The critical part of troubleshooting Windows 10 deployment is to understand the process flow.

1. Setup Scenario
2. BIOS
3. Setup (Specialize) – Setupact.log, Setuperr.log, Setupapi.offline.log, Cbs_unattend.log, Sessions.xml, and CBS.log
4. 1st Reboot
5. Setup (OOBE)
6. Windows Welcome (OOBE)
7. 2nd Reboot (Optional)
8. LogonUI
9. OEM First Run
10. Successfully Deployed

Windows 10 Deployment Upgrade Process Logs

C:\Windows\Panther\Setupact.log

Setupact.log provides information about your Windows 10 SKU, OS Version details, License State, Language Id, Processor clock, and end-to-end process about the Windows 10 upgrade process. Windows 10 upgrade processes are tracked primarily through the Setupact.log log file. Below Windows 10 upgrade troubleshooting logs will help SCCM admins to find out the root cause of any errors.

C:\Windows\panther\setuperr.log

Setuperr.log provides a high-level list of errors that occurred during the specialize phase of Windows 10 Setup or Upgrade. Setuperr.log tracks the processes like app inventory, Windows plugin-related errors during the Windows 10 setup.

C:\Windows\inf\setupapi.app.log

The setupapi.app.log file is the application installation text log. The application installation text log (setupapi.app.log) tracks information about application software installations that are associated with device driver installations. This log should analyze along with SetupAPI.dev.log.

I couldn’t find this log on my Windows 10 1709 device. But this is one of the Windows Upgrade Troubleshooting Logs.

C:\Windows\inf\setupapi.dev.log (helps with Windows Upgrade Process Troubleshooting Logs)

The setupapi.dev.log file is driver failures during the OOBE phase of Setup. The device installation text log (setupapi.dev.log) contains information about device and driver installations.

C:\Windows\panther\PreGatherPnPList.log

The PreGatherPnPList.log log file contains information about the initial capture of devices that are on the system during the down level phase.

C:\Windows\panther\miglog.xml

The MigLog.XML file contains information about the user directory structure. This includes security identifiers (SIDs) of Windows 10 devices. Default environment variables of Windows 10 are also listed in MigLog.XML.

Windows 10 Upgrade Failure Logs – BEFORE Restart

The following log files are created when a Windows 10 upgrade fails during installation before the computer restarts for the second (2nd) time. Most of these Windows 10 upgrade failure log files are already explained in the above section.

But if the Windows 10 upgrade failed and you want to troubleshoot then, these files are located in a different directory as you can see below. Below Windows 10 upgrade troubleshooting logs will help SCCM admins get the root cause of the failure. This is applicable for Windows 11 as well.

C:\Windows\setupapi.log

I can’t find this log on my Windows 10 1709 machine. But Microsoft documentation has some mention about this log file. And it seems this log file is used Windows XP and earlier versions. This setupapi.log is used to track the major changes of operating systems like Service Pack and HotFix installation for OS.

C:\Windows\Logs\MoSetup\BlueBox.log

When you use Windows Update/WSUS/SCCM Windows Serving to upgrade Windows 10 version then, BlueBox.log log file would be useful. BlueBox.log file contains information communication between setup.exe and Windows Update. The main use of BlueBox.log is during WSUS and WU down-level failures or for 0xC1900107.

Windows 10 Upgrade Failure Logs – AFTER Restart

The following log files are created when a Windows 10 upgrade fails during installation after the computer restarts for the second (2nd) time. Most of these Windows 10 upgrade failure log files are already explained in the above sections. But if the Windows 10 upgrade failed and you want to troubleshoot then, these files are located in a different directory as you can see below. Below Windows 10 upgrade troubleshooting logs will help SCCM admins get the root cause of the failure after the 2nd restart.

• C:\Windows\panther\setupact.log – More details available in the above section
• C:\Windows\panther\miglog.xml – More details available in the above section
• C:\Windows\inf\setupapi.app.log – More details available in the above section
• C:\Windows\inf\setupapi.dev.log – More details available in the above section.
• C:\Windows\panther\PreGatherPnPList.log – More details available in the above section

C:\Windows\panther\PostApplyPnPList.log – I can’t find this log on my Windows 10 1709 machine. I don’t see any traces of this log in Microsoft documentation.

C:\Windows\memory.dmp – Memory.dump file helps to troubleshoot Windows 10 crash issues. The Automatic Memory Dump file is written to %SystemRoot%\Memory.dmp by default.

Windows 10 Upgrade Failure – Restore Logs

The following log files are created when Windows 10 upgrade fails, and then you restore the desktop. Most of these Windows 10 upgrade failure log files are already explained in the above sections. But if the Windows 10 upgrade failed and you want to troubleshoot then, these files are located in a different directory as you can see below. Below Windows 10 upgrade troubleshooting logs will help SCCM admins to have the root cause analysis of the Windows 10 restore failure.

Windows 10 Upgrade Failure – Rollback Logs

The following log files are created when an upgrade fails, and the installation rollback is initiated:

Windows 10 Refresh or Reset Troubleshooting Logs – $SysReset\Logs Folder

C:\$SysReset\Logs – The log files in the following folder “C:\$SysReset\Logs” is the best place to troubleshoot Windows 10 reset or refresh failure scenarios.

Windows 10 Troubleshooting Tool SetupDiag.exe

SetupDiag works by examining Windows Setup log files. It attempts to parse these log files to determine the root cause of a failure to update or upgrade the computer to Windows 10.

SetupDiag can be run on the computer that failed to update, or you can export logs from the computer to another location and run SetupDiag in offline mode.

Author

Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is a blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. E writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc…

6 thoughts on “Windows Upgrade Troubleshooting Logs”

Excellent Read. Very valuable information.

Thank you Manoj

Very helpful article, thank you!

Hi,
i am stuck during in place upgrade where in some machine after the command executioan it stop further process .

some last entry of smsts.log are as follows.

OS upgrade version: 10.0.18362.0 OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
No timeout set for Windows Upgrade Setup OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Setting the client into provisioning mode OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Exiting SetClientProvisioningMode 0x00000000 OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Disabling CCMExec service OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
CcmExec service startup type is set to disabled OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Disabling TSManager service OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
smstsmgr service startup type is set to disabled OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Disabling Remote control service OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
CmRcService service startup type is set to disabled OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Command line of Windows setup upgrade: ‘”E:\_SMSTaskSequence\Packages\AGH000D5\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd” /postrollbackcontext system /DynamicUpdate Disable /compat IgnoreWarning ‘ OSDUpgradeWindows 29-06-2020 13:26 504 (0x01F8)
Starting execution of thread with argument: “E:\_SMSTaskSequence\Packages\AGH000D5\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd” /postrollbackcontext system /DynamicUpdate Disable /compat IgnoreWarning OSDUpgradeWindows 29-06-2020 13:26 11312 (0x2C30)
Command line for extension .EXE is “%1” %* OSDUpgradeWindows 29-06-2020 13:26 11312 (0x2C30)
Set command line: “E:\_SMSTaskSequence\Packages\AGH000D5\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd” /postrollbackcontext system /DynamicUpdate Disable /compat IgnoreWarning OSDUpgradeWindows 29-06-2020 13:26 11312 (0x2C30)
Executing command line: “E:\_SMSTaskSequence\Packages\AGH000D5\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\Windows\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\Windows\SMSTSPostUpgrade\SetupRollback.cmd” /postrollbackcontext system /DynamicUpdate Disable /compat IgnoreWarning with options (0, 0) OSDUpgradeWindows 29-06-2020 13:26 11312 (0x2C30)
Could not open Windows Upgrade Setup progress registry key ‘HKLM\SYSTEM\Setup\MoSetup\Volatile’. Error = 0x80070002. Progress UI will not be updated OSDUpgradeWindows 29-06-2020 13:27 504 (0x01F8)
Waiting for Windows Upgrade Setup process to return … OSDUpgradeWindows 29-06-2020 13:27 504 (0x01F8)
after this last line nothing happen. it didnt even generate Folder “C:\$Windows.

BT\*”. i can upgrade the OS in same model. to clear the doubt i have even install OS Win 10 1809 again but nothing worked. can someone help on this?

Загрузите setupapi.dev.log, чтобы исправить ошибки

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

Файл был разработан 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

Не удалось запустить приложение, так как отсутствует файл setupapi.dev.log. Переустановите приложение, чтобы решить проблему.

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

Как исправить ошибки setupapi.dev.log всего за несколько шагов?

Ошибки файла setupapi.dev.log могут быть вызваны различными причинами, поэтому полезно попытаться исправить их различными способами.

Шаг 1.. Сканирование компьютера на наличие вредоносных программ.

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

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