990x.top

Простой компьютерный блог для души)

Windows Log files что это?

Всем привет. Сегодня мы поговорим на тему лог-файлов, а вернее о том что такое Windows Log files. Значит сперва немного общей информации так бы сказать. Что такое лог-файлы? Это такие файлы, куда программа записывает свои действия — что у нее получилось сделать, а что нет, где произошла ошибка.. То есть можно сказать что лог-файл это типа отчета. Если вдруг случилась ошибка, то при помощи лог-файла можно попробовать понять где именно она появилась.

Но что такое Windows Log files? Ну логично что это лог-файлы винды. Может вы где-то нашли папку с названием Windows Log files? Если это папка, то удалять.. в принципе можно, но я думаю что не стоит.

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

Название Windows Log files может быть где угодно. Например это может быть папка, как я уже писал, а может быть еще пункт в проге по очистке системы, там может быть где-то галочка Windows Log files. И если эту галочку отметить, то будут в теории удалены лог-файлы.

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

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

Вот давайте для примера я вам покажу лог-файлы. Самые обычные — они есть в каждой винде, я их даже искать не буду, я просто открою папку Windows. Итак, смотрите, зажимаем кнопки Win + R, потом пишем в окошку команду:

Нажали ОК и потом откроется самая важная и самая системная папка Windows, в ней сразу нажимаем на колонку Тип, чтобы отсортировать файлы по типам:

После этого все файлы с расширением log будут рядышком, стоит немного мышкой покрутить и вот они, у меня их тут всего четыре штуки, что-то даже как-то маловато:

Вот видите тут есть WindowsUpdate.log? Это лог-файл обновления винды, то есть в этом файле идет отчет об обновлениях, все ли там нормально, это просто пример, но я файл открыл и вот что внутри:

Вот здесь все как обычно — сначала идет дата, потом время, потом еще что-то.. даже не знаю что.. а потом идет описание события. Для примера я открыл еще файл setupact.log, здесь вот уже нет времени, даты, тут просто указана какая-то инфа:

Но все равно, традиционно лог-файл должен идти с датой и временем вначале каждой строки.

Так, а давайте поищем лог-файлы? Ну вообще посмотрим сколько их, в каких папках.. ребята, зажимаем Win + E, появится окно проводника, вы туда, а вернее в правом верхнем углу есть текстовое поле поиска, вот туда вставляете это:

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

Но видите там есть еще файлы с расширением LOG1? Я думаю что это не лог-файлы, то есть не отчеты, их даже открыть нельзя, типа нет проги которой можно открыть, выскакивает такое окошко:

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

Ибо файл открыт системой для записи, а значит файл занят Но я попробовал другой. Это мы с вами пробовали открыть SYSTEM.LOG1, а я вот нашел другой файл COMPONENTS.LOG1 и его открыть я смог, но содержимое все равно непонятное:

Может это и лог файл, но как видим он идет в другой кодировке. Короче ладно.

Так, вернемся к Windows Log files.. а то я что-то прям очень увлекся лог-файлами. Я решил поискать картинки в интернете на тему Windows Log files, может что-то интересное найду.. вообще мало что есть интересного, но я нашел такую картинку, это чистилка CCleaner и тут как раз упоминается Windows Log files:

То есть на картинке мы видим что CCleaner может чистить комп от лог-файлов Windows Вот еще одна прога, тоже какая-то чистилка, но мне она незнакома, называется Sweepi и тут тоже есть пункт Windows Log files:

Видите, там еще есть Temporary Internet Files — это временные файлы интернета. Вообще везде где видите слово Temp, это все типа временное, поэтому его можно как бэ удалить типа для ускорения системы.

На всякий случай, мало что, я не знаю что там у вас — папка с названием Windows Log files или программа такая, или что-то еще.. Но перед любыми изменениями в винде я рекомендую создавать точку восстановления. И это не требует особых знаний. Вам нужно всего лишь зажать Win + R, вставить туда:

Потом там нужно выбрать системный диск и нажать кнопку Создать (но если нужно наоборот — то есть кнопка выше Восстановление):

Название точки советую задавать простое, например Удаление папки Windows Log files:

Процесс создания будет недолгим:

И все, потом будет написано что успешно:

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

На этом все друзья, надеюсь представленная информация для кого-то все таки оказалась полезной. Удачи вам и суперского настроения!

Useful log files for troubleshooting RDS issues

This article describes the logs that you must collect when you troubleshoot RDS issues.

Original product version: В Windows Server 2012 R2
Original KB number: В 2747656

Introduction

Remote Desktop Management Service (RDMS) is a new feature that is introduced in Windows Server 2012. RDMS simplifies administrative tasks in Remote Desktop and provides a centralized management solution for all Remote Desktop Services (RDS) role services and scenarios.

This article introduces the logs that you have to collect when you troubleshoot issues during one of the following operations:

• RDS installation
• Collection creation
• Virtual machine provisioning

How to enable logs

Before you collect the logs, you must enable the RDMSDeploymentUI and RDMSUI-trace logs. To do this, follow these steps:

On the Remote Desktop (RD) Connection Broker server, create the following registry key:

Create the following two registry entries under the registry key:

• Entry: EnableDeploymentUILog
• Data type: REG_DWORD
• Value: 1

How to collect logs

To troubleshoot issues during RDS installation and deployment, collect the following RDMS UI log files on the RD Connection Broker server:

This file is located in the %windir%\Logs folder.

This file is located in the %temp% folder. Usually, the path of the %temp% folder is as follows:

To troubleshoot issues during collection creation and virtual machine provisioning, follow these steps:

On the RD Connection Broker server, follow these steps:

1. Collect the RDMSDeploymentUI.txt and RDMSUI-trace.log files.
2. Collect the contents of the %windir%\system32\tssesdir\*.xml folder. The files in this folder are the VM provisioning job reports.
3. In Event Viewer, enable the Analytic and Debug logs, expand Custom Views, click Administrative Events, and then export the event logs.
4. Expand Applications and Services Logs, expand Microsoft, expand Windows, expand TerminalServices-SessionBroker, and then export the event logs.
5. Expand Applications and Services Logs, expand Microsoft, expand Windows, expand Rdms-UI, and then export the event logs.

On the Remote Desktop Virtualization Host server, follow these steps:

1. In Event Viewer, enable the Analytic and Debug logs, expand Custom Views, click Administrative Events, and then export the event logs.
2. Expand Applications and Services Logs, expand Microsoft, expand Windows, expand TerminalServices-TSV-VmHostAgent, and then export the event logs.
3. Expand Applications and Services Logs, expand Microsoft, expand Windows, expand the Hyper-V-related nodes, and then export the event logs.

—>

Deployment Troubleshooting and Log Files

The following section describes the relationship between common deployment scenarios and their associated log files. WindowsВ® deployment is a highly customizable process, which has the potential for many points of failure. Identifying the specific point of failure you have encountered begins with understanding how the underlying technologies work.

Windows Setup Scenario

This scenario begins with completing Windows Setup on a new computer, so that you arrive at the desktop. This scenario is most common when you are creating a reference image. This process is also known as the first user experience.

As shown in the following illustration, the key to solving failures is identifying where you are in the installation process and when a failure occurs. Because you are creating a new installation, the hard drive is not initially available, so Windows Setup writes logs into memory, specifically in a Windows PE session (X:\Windows). After the hard drive is formatted, Setup continues logging directly onto the new hard drive (C:\Windows). Log files created during the Windows PE session are temporary.

When a failure occurs in Windows Setup, review the entries in the Setuperr.log file first, then the Setupact.log file second, and then other log files as needed.

Windows Setup-Related Log Files

Primary log file for most errors that occur during the Windows installation process. There are several instances of the Setupact.log file, depending on what point in the installation process the failure occurs. It is important to know which version of the Setupact.log file to look at, based on the phase you are in.

Setup (specialize): X:\Windows\panther

Setup (OOBE), LogonUI, OEM First Run:%windir%\panther

Out-Of-Box Experience (OOBE): %windir%\panther\unattendGC

High-level list of errors that occurred during the specialize phase of Setup. The Setuperr.log file does not provide any specific details.

Setup (specialize): %windir%\panther

Setup (specialize): %windir%\panther

Setup (OOBE), LogonUI, OEM First Run: %windir%\panther

Driver failures during the Component Specialization sub-phase of the Setup specialize phase.

Unattended-setup servicing failures.

Driver failures during the oobe phase of Setup.

An XML-based transaction log file that tracks all servicing activity, based on session id, client, status, tasks, and actions. If necessary, the Sessions.log file will point to the DISM.log and CBS.log files for more details.

Servicing log file that provides more details about offline-servicing failures.

Offline Servicing Scenario

This scenario involves adding and removing updates, drivers, and language packs, and configuring other settings, without booting Windows. Offline servicing is an efficient way to manage existing images that are stored on a server, because it eliminates the need for recreating updated images. You can perform offline servicing on an image that is mounted or applied to a drive or directory.

The Deployment Image Servicing and Management (DISM) tool is the primary tool for all offline-servicing tasks. DISM runs from a command prompt from Windows PE or a running Windows operating system. If a failure occurs when executing a DISM command, the tool will provide an immediate response, and log the issue in the DISM.log file. The Session.xml file is a transaction log file that captures all servicing activities on the target operating system. The Session.xml file can be used in conjunction with the DISM.log file to determine points of failures and the required servicing activity.

When a failure occurs in offline servicing, look at the DISM.log file first for specific errors. If the DISM.log file doesn’t contain any errors, review the Sessions.xml log file second, and then the CBS.log file.

Offline Servicing Related Log Files

Primary log file for all offline actions using DISM.

You can also create the DISM log file in a different location by using the /LogPath option. The level of data written to the log file can also be controlled by using the /LogLevel option.

An XML-based transaction log that tracks all servicing activity, based on session id, client, status, tasks, and actions. If necessary, the Sessions.log file will point to the DISM.log and CBS.log files for more details.

To learn more about offline servicing, see Understanding Servicing Strategies.

Online Servicing Scenario

This scenario is servicing a running operating system. This scenario involves booting the computer to audit mode to add drivers, applications, and other packages. Online servicing is ideal for drivers if the driver packages have co-installers or application dependencies. It is also efficient when the majority of your servicing packages have installers, the updates are in either .msi or KB.exe file formats, or the applications rely on Windows-installed services and technologies (such as the .NET Framework or full plug and play support).

Like offline servicing, all logging is captured in the DISM.log, CBS.log, and Sessions.xml files. If a failure occurs when executing a DISM command, the tool will provide immediate response as well as log the issue in the DISM.log file. The Session.xml file is a transaction log file that captures all servicing activities on the target operating system. The Session.xml file can be used in conjunction with the DISM.log file to determine points of failures and the required servicing activities.

When a failure occurs in offline servicing, look at the DISM.log file for specific errors. If the DISM.log file doesn’t contain any errors, review the Sessions.xml log file and then the CBS.log file.

Online Servicing-Related Log Files

Primary log file for all online actions using DISM. If necessary, DISM.log will point to CBS.log for more details.

You can also point DISM log file to a different location by using the /LogPath command option. The log data can also be controlled by using the /LogLevel command option.

Secondary log file that provides more details about an online servicing failure. DISM.log will reference CBS.log for more details.

An xml based transaction log that tracks all servicing activity based on session id, client, status, tasks, and actions. If necessary, Sessions.log will point to DISM.log and CBS.log for more details.

To learn more about offline servicing, see Understanding Servicing Strategies.

Diagnosing Online Servicing-Related Log Files

SetupDiag is a standalone diagnostic tool that can be used to obtain details about why a Windows 10 upgrade was unsuccessful. 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. Starting in Windows 10, version 2004, Windows Setup includes and executes SetupDiag. When Windows 10 Setup launches setupdiag.exe, the following parameters are used:

/ZipLogs:False
/Format:xml
/Output:%windir%\logs\SetupDiag\SetupDiagResults.xml
/RegPath:HKEY_LOCAL_MACHINE\SYSTEM\Setup\SetupDiag\Results

To learn more about SetupDiag, see SetupDiag.