Windows Setup Log Files and Event Logs

Windows® Setup creates log files for all actions that occur during installation. If you are experiencing problems installing Windows, consult the log files to troubleshoot the installation.

WindowsВ Setup log files are available in the following directories:

Log location before Setup can access the drive.

Log location when Setup rolls back in the event of a fatal error.

Log location of Setup actions after disk configuration.

Used to log Plug and Play device installations.

Location of memory dump from bug checks.

Location of log minidumps from bug checks.

Location of Sysprep logs.

WindowsВ Setup Event Logs

WindowsВ Setup includes the ability to review the WindowsВ Setup performance events in the Windows Event Log viewer. This enables you to more easily review the actions that occurred during WindowsВ Setup and to review the performance statistics for different parts of WindowsВ Setup. You can filter the log so as to view only relevant items that you are interested in. The WindowsВ Setup performance events are saved into a log file that is named Setup.etl, which is available in the %WINDIR%\Panther directory of all installations. To view the logs, you must use the Event Viewer included with the Windows media that corresponds to the version of the customized image that you are building.

To view the logs on a computer that does not include the corresponding kit, you must run a script from the root of the media that installs the Event Trace for Windows (ETW) provider. From the command line, type:

where D is the drive letter of the Windows DVD media.

To view the WindowsВ Setup event logs

Start the Event Viewer, expand the Windows Logs node, and then click System.

In the Actions pane, click Open Saved Log and then locate the Setup.etl file. By default, this file is available in the %WINDIR%\Panther directory.

The log file contents appear in the Event Viewer.

To Export the log to a file

From the command line, use the Wevtutil or Tracerpt commands to save the log to an .xml or text file. For information about how to use these tools, see the command-line Help. The following commands show examples of how to use the tools:

Windows: Логи Выключений/Перезагрузок

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

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

Я также показываю, как просмотреть историю включений/выключений с помощью стандартного приложения «Просмотр событий» (англ. Event Viewer) или из командной строки с помощью PowerShell.

Дельный Совет: Загрузка Windows в безопасном режиме! Читать далее →

Коды Событий Выключения

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

Log file location	Description

Event ID	Описание
41	Система была перезагружена без корректного завершения работы.
1074	Система была корректного выключена пользователем или процессом.
1076	Следует за Event ID 6008 и означает, что первый пользователь (с правом выключения системы) подключившийся к серверу после неожиданной перезагрузки или выключения, указал причину этого события.
6005	Запуск «Журнала событий Windows» (англ. Event Log). Указывает на включение системы.
6006	Остановка «Журнала событий Windows» (англ. Event Log). Указывает на выключение системы.
6008	Предыдущее выключение системы было неожиданным.
6009	Версия операционной системы, зафиксированная при загрузке системы.
6013	Время работы системы (англ. system uptime) в секундах.

«Просмотр событий» — История Выключений

События связанные с выключениями системы (включая дату и время) могут быть просмотрены с помощью программы «Просмотр событий».

Запустить «Просмотр событий» и найти события связанные с выключениями:

1. Нажмите клавишу Win , наберите eventvwr и запустите Просмотр событий
2. В панели слева разверните Журналы Windows и перейдите в Система
3. Щелкните правой кнопкой мыши на Система и выберите Фильтр текущего журнала.
4. Введите следующие коды в поле и нажмите OK :

Дельный Совет: История команд в PowerShell! Читать далее →

Логи Выключений в PowerShell

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

Дельный Совет: Запуск/Остановка служб в Windows из CMD! Читать далее →

Event Logging (Windows Installer)

Windows Events provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. The event-logging service stores events from various sources in a single collection called an event log. Prior to WindowsВ Vista, you would use either Event Tracing for Windows (ETW) or Event Logging to log events. WindowsВ Vista introduced a new eventing model that unifies both ETW and the Windows Event Log API.

The installer also writes entries into the event log. These record events such as following:

• Success or failure of the installation; removal or repair of a product.
• Errors that occur during product configuration.
• Detection of corrupted configuration data.

If a large amount of information is written, the Event Log file can become full and the installer displays the message, «The Application log file is full.»

The installer may write the following entries in the event log. All event log messages have a unique event ID. All general errors authored in the Error table that are returned for an installation that fails are logged in the Application Event Log with a message ID equal to the Error + 10,000. For example, the error number in the Error table for an installation completed successfully is 1707. The successful installation is logged in the Application Event Log with a message ID of 11707 (1707 + 10,000).

For information about how to enable verbose logging on a user’s computer when troubleshooting deployment, see Windows Installer Best Practices.

Windows Event Logs — Event Log FAQ

What is Windows event log?

Event logs are special files that record significant events on your computer, such as when a user logs on to the computer or when a program encounters an error. Whenever these types of events occur, Windows records the event in an event log. Users might find the details in event logs helpful when troubleshooting problems with Windows and other programs.

Unlike UNIX syslog, Microsoft event log is not a text file and it is impossible to view it with simple text editors. Microsoft Windows event log is a binary file that consists of special records – Windows events.

Microsoft Windows runs Event Log Service to manage event logs, configure event publishing, and perform operations on the logs. Windows Event Log service exposes a special API, which allows applications to maintain and manage event logs.

Windows event logging was introduced in Windows NT operating system (version 3.1) in 1993. This Windows edition came with three Windows logs: Application event log, System event log and Security event log. Modern versions of Windows come with more than a hundred of Windows eventlogs, and third party applications can create and integrate into Windows logging their own event logs.

How to view event logs?

You can view eventlogs using Event Viewer (comes with Windows operating system) or third-party Windows event viewers. We recommend using our Event Log Explorer software – it provides a lot of advanced features for event log management.

What is Windows Event Log Service?

Windows Event Log Service is a Windows service that manages events and event logs. It supports logging events, querying events, subscribing to events, archiving event logs, and managing event metadata. It helps to display events in both XML and plain text format. This service is enabled and starts automatically by default. You should not stop or disable this service. Stopping Windows Event Log service may compromise security and reliability of the system.

What are Windows event log files?

Windows Event Log Service lets users to save (backup) event logs to files. Windows NT, 2000 and XP/2003 save event logs to EVT format. Windows Vista/2008 and better save logs to EVTX format. Having backup event files are essential for incident investigation.

Windows event logs are also files, but they are commonly locked by Windows (Event Log Service) and it is impossible to open these files on «live» system. But if the computer is started from another disk or the system drive from the analyzed machine is connected to another computer, you can read event logs as files. The default location of event logs on Vista/2008 and better is «C:\Windows\System32\winevt\Logs\». Windows Event Viewer allows you to open event file as follows:

Click Open Saved Log in Actions pane of Event Viewer.

Select your event log file and it will appear in Windows Event Viewer as a log.

Our Event Log Explorer software also works with event files and does it even better than Event Viewer, e.g. it lets you read even damaged event files.

What is Windows Application event log?

The Application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. Program developers decide which events should be logged. E.g. Microsoft SQL Server logs details about important events linked with SQL server, e.g. «out of memory», «backup failure» etc. One application log commonly contains events logged from different sources (applications), so it is incorrect to rely solely on event ID when analyzing the Application log. You should always rely on event ID along with event source. Some applications, such as Internet Explorer, Power Shell create own event log instead of using Windows application event log. Such logs look exactly like standard Windows event logs and Event Viewer (as well as Event Log Explorer) can read these event logs. Application logs are commonly useful for application support teams.

What is Windows System event log?

The System log contains events logged by Windows system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. The event types logged by system components are predetermined by Windows. Similarly to Application log, System event log lists events from different sources (system components) so you should not rely only on event ID when analyzing System log, instead you should rely on event ID along with event source. System logs are essential for system administrators and technicians.

Windows event log database

I’m currently in the process of planning for an AppLocker rollout to all my PCs (about 7,500 of them) due to an increasing amount of malware. You should probably be doing this too. Anyway, a sensible first step is to identify which paths things are running from, which is pretty easy – you just turn AppLocker on in Audit mode. This makes it write messages into its event log telling what has been allowed to run, and what would be blocked from running were it in enforce mode rather than audit mode.

You now have your PCs collecting all this useful info in their event logs. Now you need to collate it centrally and process it. “Aha”, I thought, “this will be a great time to try out using the built in Windows Event Forwarding“. I followed some instructions, and it worked fine on my Windows 8.1 PC, and also on a colleague’s Windows 10 PC. Sadly, it failed on the other 7498 Windows 7 PCs. After a few days of trying to get it to work on them, I gave up and wrote my own version in PowerShell.

I think my version is better, because it allows you to query events in SQL, which is easier for me than trying to extract sensible information directly out of an event log – especially if the info you’re after is in the Messages field. You could of course modify the script and the SQL table to collect whatever fields you want. This is also not restricted to the AppLocker event log, you can collect events from any Windows Event Log.

This is going to be a big post with multiple sections, sorry about that, but it is pretty straightforward.

• You need an SQL server to store the events that you’re going to collect from the PCs. Maybe use SQL Server 2014 Express – which is free.
• The PCs push the events to the SQL server using an SQL bulk copy, which is pretty efficient.
• The event collection script is written in PowerShell, you should probably have at least version 3 of this on your PCs, and .Net 3.5, ideally PowerShell 4 and .Net 4.5 (at time of writing).
• The collection script is launched via a scheduled task, runs as the Network Service account, does not show on the user’s desktop whilst running, and only requires the Domain Computers group to have access to the SQL database. I’ve configured the scheduled task via a Group Policy Preference.
• The script writes a registry marker when it runs, and on subsequent runs only uploads events that have occurred since its last run. This means you can run it as often as you like an not get duplicate events in your SQL table.
• The script takes two parameters, the event log name to collect from, and the SQL server to send the events to.

PowerShell Script

A few points to note on the script:

• Pass it the name of the event log to collect events from, e.g. Microsoft-Windows-AppLocker/EXE and DLL
• If the upload to SQL Server fails, the timestamp marker is not written to the registry and thus the events in the event log will try to be uploaded again on the next run of the script. i.e. you will not be missing events in the SQL table if the SQL server is unavailable when the script runs.
• The log name is simplified to a form that SQL Server is happy with by removing spaces and hyphens, and converting forward slashes to underscores.
• The script assumes the database name of EventCollection
• The script requires you to create a table within this database for each log that you want to collect from, the table name needs to be the simplified version of the log name passed to the script, e.g.
  Microsoft-Windows-AppLocker/EXE and DLL becomes
  MicrosoftWindowsAppLocker_EXEandDLL
• See below for SQL script to create the database and table
• ALWAYS use ISO 8601 format datetime with PowerShell! (especially if you live outside USA)
• I have created a GP Pref to copy the script onto the C drive of all my PCs
• Storing the event data in a DataTable is bit more fiddly than using a simple array of objects, but it makes the bulk copy into SQL Server much easier – you just dump the whole thing across.
• The UserId returned from the event log in in the form of a SID, which is not terribly useful to me, so I wrote the Get-UserFromSID function to change this into a username.

SQL Database and Table Creation

Here’s the SQL Server code, paste into SQL Management Studio and run it.

You also need to grant the Domain Computers group permission to bulk copy into the table.

From SQL Management Studio:

1. Go to Security – Logins
2. Create a new Login for the Domain Computers group, on the User Mapping page tick the EventCollection database.
3. Go to Databases – EventCollection – Security – Users
4. Double-click the Domain Computers group, go to the Securables page
5. Click Search… – All objects of the types… – OK
6. Tick Tables – OK
7. Ensure the table is selected in the Securables section, then in the Explicit permission tab tick:
   1. Insert: Grant
   2. Select: Grant
8. Click OK.

Note that I am not a SQL Server expert, so whilst this all works it may be missing many optimisations. I believe SQL bulk copies do not cause much transaction log activity, but you could always set your database to simple recovery mode anyway.

Scheduled Task Configuration

I’ve configured this via a Group Policy Preference. Here’s what I did.

1. Create a new GPO, or edit an existing one. In the Group Policy Management Editor go to Computer Configuration, Preferences, Control Panel Settings, Scheduled Tasks.
2. Right-click, New – Scheduled Task (At least Windows 7). Leave the settings at their defaults except as detailed below.
3. General tab
   1. Action: Replace
   2. Name: Collect AppLocker Events EXE DLL
   3. When running the task, use the following user account: NT AUTHORITY\Network Service
4. Triggers tab – you can use any trigger you like, personally I’m doing it once a day based on time and day of the week
   1. Click New…
   2. Begin the task: On a schedule
   3. Settings: Weekly
   4. Start: 15:00:00
   5. Recur every: 1 weeks on: Monday Tuesday Wednesday Thursday Friday
   6. Delay task for up to (random delay): 1 hour (stops your SQL server being overwhelmed with all the collections happening at once)
   7. Stop task if it runs longer than: 30 minutes (this is just a safety net in case the script errors badly/hangs)
   8. Enabled needs to be ticked
5. Actions tab
   1. Click New…
   2. Action: Start a program
   3. Program/script: %WindowsDir%\System32\WindowsPowerShell\v1.0\powershell.exe (note that GPPrefs use their own “environment variables, hence %WindowsDir% and not %WinDir%. Hit F3 to view & insert GPPref variables)
   4. Add arguments(optional): -ExecutionPolicy Bypass -File “C:\Program Files\RCMTech\CollectEvents.ps1” (see my note earlier about using a GPPref to copy the script locally onto the PCs)
6. Settings tab
   1. Allow task to be run on demand: ticked (useful for testing, and why not anyway)
   2. Run task as soon as possible after a scheduled start is missed: ticked (in case the PC is switched off when the task is scheduled to run)
7. Common tab
   1. Remove this item when it is no longer applied: ticked

Note that running a scheduled task as a specific user is no longer possible via GPPref due a security flaw. Network Service is a good choice in this situation anyway. It causes the connection to the SQL server to be using the credentials of the computer’s own Active Directory account, e.g. RCMTech\MYPC$ which means you don’t need to give your users access to the database. This is good from a data protection point of view as the resulting database contains personally identifiable information.

Group Policy Preference to copy script onto target machines

1. Computer Configuration, Preferences, Windows Settings, Files.
2. Right-click, New – File
3. General tab
   1. Source File(s): \\rcmtech.co.uk\NETLOGON\LocalScripts\*.*
   2. Destination Folder: %ProgramFilesDir%\RCMTech
   3. Suppress errors on individual file actions: ticked
4. Common tab
   1. Remove this item when it is not longer needed: ticked
   2. Item-level targeting:
      1. the folder \\rcmtech.co.uk\NETLOGON\LocalScripts exists

All done

Once all the above is in place, you’re good to go. Now you just need to do something with all that event data sat in your SQL database.