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.

Как записать и найти логи установки драйвера и GeForce Experience NVIDIA.

ID 3171

В случае неполадок при установке драйвера либо утилиты GeForce Experience, мы просим пользователей включить логи, чтобы помочь нам определить причину неполадок при установке. Чтобы включить ведение логов установщика NVIDIA, следуйте шагам ниже:

1. Скачайте на ваш компьютер оба файла реестра, которые находятся в разделе Приложения. Запомните, куда вы скачали эти файлы. (Файл «EnableFullLogging.reg» включает ведение логов. Файл «DisableLogging.reg» отключает ведение логов)

2. Перед установкой, проверьте на наличие следующих файлов в вашей системе, если найдёте, удалите их (если же не найдёте, перейдите к пункту 3):

Для системы Windows 7/Windows 8.1/Windows 10:

3. Включите запись логов открыв файл «EnableFullLogging.reg». Это перенесет ключи реестра в реестр Windows.
4. Нажмите на «Да» для того чтобы добавить файлы в реестр.

5. Попробуйте ещё раз установить драйвера либо GeForce Experience как вы делали это раньше.

7. Когда установка закончится/даст сбои, отключите запись открыв файл «DisableLogging.reg».

8. Когда установки завершится/даст сбой, файлы с логами, содержащие информацию об неудавшейся установке, могут быть найдены:

Для драйвера дисплея NVIDIA:

C:\Windows\INF\Setupapi.*.log (Нам также понадобятся все файлы, имя которых начинается с SetupAPI)

Для NVIDIA GeForce Experience:

Нажмите сочетание клавиш «Windows»+»R», чтобы активировать окно «Выполнить». В поле Открыть, наберите команду, как на скриншоте ниже. Все файлы в папке содержат логи установки GeForce Experience.

%programdata%\NVIDIA Corporation\Geforce Experience\Logs

После установки, приложите файлы логов к обращению в службу поддержки по инструкциям агента Службы поддержки клиентов NVIDIA. Если Вы просто хотите предложить обратную связь, но не нуждаетесь в помощи службы поддержки, вы можете отправить логи установки на почтовый ящик driverfeedback@nvidia.com.

Важно: Убедитесь, что вы отключили запись логов, когда закончили воспроизводить неполадку. Если вы оставите запись логов включенной, это может привести к снижению производительности или другим неполадкам. Два раза нажмите на файл «DisableLogging.reg» чтобы остановить запись.

Информация в логах (для продвинутых пользователей):

Откройте setupapi.dev.log и ищите строки, начинающиеся с . они означают неполадки. К примеру:

. flq: Windows could not copy a boot file ‘C:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe’ due to the presence of an in-use file.
. flq: Error installing file (0x00000005)
. flq: Error 5: Access is denied.
! flq: SourceFile — ‘C:\WINDOWS\System32\DriverStore\FileRepository\nvdmi.inf_amd64_995e5491302e0a85\nvidia-smi.exe’
! flq: TargetFile — ‘C:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.exe’
. flq: SPFQNOTIFY_COPYERROR: returned SPFQOPERATION_ABORT.
. flq: Error 1459: This operation requires an interactive window station.
. flq: FileQueueCommit aborting!
. flq: Error 1459: This operation requires an interactive window station.

Решение 2 самых частых ошибок:

1) Error: This operation requires an interactive window station.

Образец строки файла логов Setup.exe:
ERROR: [NVI2.NVDevicePhase] 1592@CNVDevicePhase::InstallHelper : Device phase failure Exception <0x800705b3 - this operation requires an interactive window station.>.

Образец строки файла логов setupapi.dev.log:
. flq: Error 1459: This operation requires an interactive window station.

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

Для дополнииельной помощи в установки разрешений в ОС, свяжитесь с производителем Вашей операционной системы или со службой технической поддержки Microsoft.

2) Error: SPFQNOTIFY_COPYERROR

Образец строки файла логов setupapi.dev.log
Error installing file (0x00003b01)
. flq: SPFQNOTIFY_COPYERROR: returned SPFQOPERATION_ABORT.

Данные файла setupapi.dev.log также будут отображаться файл(-ы) с вопросом над строкой ошибки. Эта ошибка означает повреждение хранилища драйверов операционной системы в \System32\DriverStore\FileRepository, где файл(-ы) не читаются. Вы можете попробовать выполнить ручную очистку DriverStore по пути, указанному в журнале, однако для этого потребуются права владельца. Выполняйте на свой страх и риск.

Другой подход заключается в использовании PnPUtil, который поставляется вместе с операционной системой, чтобы сначала попытаться удалить пакеты драйверов, а затем повторить попытку установки. Посетите http://msdn.microsoft.com/en-us/library/windows/hardware/ff550423(v=vs.85).aspx для синтаксиса команд, включая пример для удаления пакета драйверов. Если и это не поможет, то возвращение к предыдущей Точке Восстановления Windows это последнее средство, не считая переустановки Операционной системы.

Другие ошибки:
Если ваша ошибка не указана здесь, обратитесь за помощью в службу поддержки клиентов NVIDIA.

How to see detailed log of nVidia driver crash on Windows?

While doing GPU-intensive parallel processing, nVidia driver apparently crashed. Only information in Windows Event log is the following:

The description for Event ID 1 from source NVIDIA OpenGL Driver cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Unable to communicate with the display driver. The application must close.

Source: NVIDIA OpenGL driver

I checked and we have the latest NVIDIA driver installed.

I would like to investigate and/or report the problem to NVIDIA, but this information is clearly not enough for reporting. Is there a place where I can see what could have been the source of the problem? I.e., the error in Windows Event log only shows me that communicating with the driver failed, but it does not give information why the crash happened.

Also, if it is not possible to find the reason of the crash, then I would like to at least know how to increase diagnostics/logging for the future so I can trace the problem if it re-occurs.

PS. 4 processes were doing a similar GPU-intensive task at the same time, and each of them received the same error. PPS. I was not at the computer at the time of the crash. When I came to work at the morning, the screen was completely blank (but the computer was running). Only after restart did everything go back to normal. PPPS. Graphics card was working normally up to that point.

System I am running is: Windows 10

Graphics card: NVIDIA GeForce GTX 750 Ti

Graphics card driver version: 10.18.13.6822

Graphics card driver date: 2016-05-19

(I assume that the nVidia OpenGL driver version = nVidia driver version. If that is not so, please let me know where I can check the nVidia OpenGL driver version).

Перенаправление событий Windows (Event Log) на сервер syslog Linux

Вступление

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

В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.

Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.

Описание

Каждый работающий с серверами знает и ежедневно пользуется системой логов на своих машинах и каждый знает как они устроены — syslog на Linux и Event Log на винде.

До эры Windows Server 2008 Event Log был странной системой созданной как-будто не для серверов — каждый компьютер писал и хранил свои события локально и удобных механизмов для передачи их по сети для централизованного просмотра или хотя бы хранения не было вообще. Ну, впрочем, всем это известно. Просмотр логов для серверов напоминал квест в MMORPG — исследуй несколько локаций и собери несколько предметов в каждой. Начиная с Windows Vista был сделан шаг навстречу людям и создана система форварда локальных событий на другие Windows >Vista компьютеры. Это хорошо и прогрессивно и это именно то чего не хватало, но реальность такова что на данный момент осталось и не устарело много серверов с Windows 2003 для которых таких механизмов так и нет или они есть, но отталкивают своей монстроузной реализацией.

С другой стороны существует простая и надежная система syslog для Linux которая изначально разработана для распределённой передачи и приёма логов и содержит в себе всё что для этого необходимо. Она настолько хорошо делает своё дело что возможность отправлять логи по этому протоколу встраивают и в хардварные роутеры и в кучу разных других устройств и вполне реально сделать в сети сервер который будет собирать все логи со всех устройств в сети: серверов, роутеров, коммутаторов, принт-серверов, кофеварок, кулеров, ой что-то я разошелся… Кроме Windows. Врядли найдётся человек которому не приходила в голову мысль что если бы Windows мог отправлять свои логи в syslog это было бы идеальным решением для централизации логохранилища. Как удобно было бы все иметь в одном месте — можно было бы и хранить годами, архивируя текстовые файлы (они отлично ужимаются), и обрабатывать, разбирая один текстовый файл от нескольких серверов вылавливая одно критическое событие сразу для нескольких машин.

Задался таким вопросом и я. Задался я им несколько лет назад и потерпел неприятное фиаско — утилит позволяющих это сделать-то довольно много, но выглядят они все как кошмар профессионального администратора — какие-то ужасные утилиты иногда на C# размеров в 100 мегабайт с тысячей кнопочек и чекбоксов и что самое неприятно — _все платные_. Не знаю в чем прикол, но несколько лет назад Google был переполнен ссылками на коммерческий софт с таким функционалом. При этом софт не высокого качества, судя по стремным сайтам и скриншотам. Переполнен он ими и сейчас, и, по моим собственным наблюдениям, многие отнюдь не ленивые и не тупые администраторы способные с успехом для собственного удобства использовать такой функционал так и не нашли того что им нужно и не знают что такое бывает. По крайней мере за мой совет и ссылку меня не раз благодарили, и теперь я хотел бы поделиться и с вами. А именно некоторое время назад (довольно давно, это статью я решил написать только сейчас), мне удалось найти проект идеально подходящий под мои нужды и требования:

Опишу вкратце его достоинства:
— это системный сервис, т.е. ничего не надо запускать при старте, никаких странных экзешников которые можно случайно по забывчивости убить при очередной чистке хлама на сервере;
— лаконичная поставка — .dll, .exe и краткая, но всеобъемлющая документация;
— открытый исходный код;
— версия 32-bit и 64-bit;
— одинаковая работа и версия на любых версиях Windows имеющих Event Log;
— минимум настроек (настолько минимум что это командная строка при установке сервиса и текстовый файл для работы, который можно не открывать вообще при желании);
— покрывающий максимум функционала — все что должна делать эта программа она делает — умеет отправлять логи в разные facility, умеет исключать определённые события из отправления и так далее, даже получать имя log сервера по dhcp.

Добавлю от себя что во-первых вот уже полгода как эта программа на 8-ми моих серверах и 2003 и 2008 просто работает, после установки я _ни разу_ ни на одном из них не проверял, не перезапускал обвалившийся, не ковырял, не изменял и даже не смотрел в сторону этого сервиса, который так же никак не повлиял ни на одно другое приложение, он просто делает своё дело после установки — безустанно шлёт эвенты туда куда ему сказали. А во-вторых что программа очень динамично развивалась не так давно набирая функционал, после чего стабилизировалась и теперь достаточно регулярно, но не слишком часто, выходят билды которые причесывают функционал и фиксят мелкие редковоспроизводимые баги.

Перейдём к ещё большей конкретике.

Настройка

Настройка syslog на линуксе.
Включите принятие логов из сети, это ключ -r у демона syslogd. По умолчанию он почти всегда не прописан и при запуске без него syslogd сеть не слушает.

Затем вам наверняка не очень понравится если логи линуксов, роутеров и винды будут смешиваться в одном файле и превращаться в трудновоспринимаемую кашу. Для этого в системе syslog есть несколько разделов (facility) и приходящие на отдельные facility сообщения можно писать в разные файлы. Так как логи от винды не особо подходят ни под kernel, ни под mail, специально для этого в syslog есть несколько “безличных” facility которые называются local. Чтобы вынести например local1 в отдельный файл надо добавить в /etc/syslog.conf строку:

ну и запомнить что это local под номером 1. точно так же можно разделить остальные local от local0 до local7.
Обращаю ваше внимание что это простейшая конфигурация syslog которая позволит просто складывать логи от винды в отдельный файл, тонкая конфигурация syslog позволяет довольно замысловато распределить сообщения приходящие к демону, но всё это описано в мануале к syslog и скорее всего известно любому знакомому с линуксом администратору.
Установка evtsys на Windows.

Установка элементарна — скачиваем дистрибутив, в нём .dll и .exe, копируем их в %WINDIR%\System32\
Запускаем .exe с нужными параметрами.

Параметры evtsys.exe:
-i Установить сервис
-u Удалить сервис
-d Дебаг. Запуститься как консольная программа
-h host Имя хоста куда отправлять логи
-b host Имя второго хоста кому дублировать логи
-f facility Facility логов
-l level Минимальный уровень отсылаемых сообщений
0=Всё, 1=Критические, 2=Ошибки, 3=Предупреждение, 4=Информация
-n Отправлять только эвенты включенные в конфиге
-p port Номер порта syslog
-q bool Опросить DHCP чтобы получить имя хоста syslog и порт
(0/1 = включить/выключить)
-s minutes Интервал между сообщениями. 0 = Отключить

Необходимым является всего один параметр: -h хост. Чтобы установить evtsys как сервис надо указать и параметр -i. А так же нас интересует параметр -f, чтобы сменить facility по умолчанию (system daemons) на local1.
Evtsys использует цифровое обозначение facility, вот список:

0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslogd
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)

выберите тот который вам нужен, в нашем случае это 17 (local1) и вперед, целиком команда будет выглядеть так:
%WINDIR%\System32\evtsys.exe -i -h [адрес вашего линукса с syslog] -f 17

Если вы хотите исключить какое-то событие из отправки в syslog, например огромную кучу мусора появляющуюся по поводу каждого подключения к компьтеру по сети в разделе Security, можете создать файл (или открыть, если уже запустили сервис) %WINDIR%\System32\evtsys.cfg и забить в него события которые вас не интересуют в формате EventSource:EventID. Например строка “Security-Auditing:*” полностью отключит отправку раздела Security на Windows >Vista, строка “Security-Auditing:4624” отключит отправку только события с кодом 4624 (интерактивный доступ из сети к компьютеру, браузинг его кем-то из сети). Грустная ирония такова что при разработке нового Event Log’а для нового поколения серверных ОС Микрософт полностью сменила названия разделов и коды, а так же переписала и стандартные сообщения и вообще все события, так что на поколении Windows 2003 и поколении Windows 2008 названия разделов и номера событий будут кардинально различаться. Впрочем зачастую у них будет одинаковый смысл. Какое событие что значит и какие у них названия и номера удобно узнавать с сайта http://www.eventid.net/.

После чего можно открывать список сервисов Windows и запускать сервис под названием “Eventlog to Syslog” и логи начнут появляться в файле на сервере с syslogd примерно в таком виде:

# head -n 1 /var/log/local1.log
Jun 20 09:13:30 srv SRV Security-Auditing: 4634: An account was logged off. Subject: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-2304319227-3176 Account Name: XXXXXX$ Account Domain: XXX Logon ID: 0x325f90ec Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.

Заключение

Что ещё сделал лично я и что сможет повторить любой знакомый с регулярными выражениями администратор.

Для себя я написал на perl зацикленный парсер идущего лога который из всё-таки не совсем удобочитаемой простыни лога:
а) выкусывает события которые меня не интересуют: например всё те же обращения к компьютеру из сети (любой браузинг в сети одного компа вызывает на всех компах которые он у себя в сетевом окружении увидит сообщение об этом, а это реально большая куча сообщений на серверах, особенно если сразу с нескольких). У меня ушёл всего один день на то чтобы создать список таких “не интересующих меня” событий.
б) подкрашивает события которые меня интересуют и переводит их из технического вида в человеческий, например логин на сервер по RDP окрашивается синим и пишется не полная строка из лога, навроде той что я привёл выше из которой ещё надо понять кто на ком стоял, а в виде “Remote login by ‘xxx’ (ip: x.x.x.x) to ‘XXX’”.

В результате чего я получил консольную утилиту в которой то что меня интересует всегда выделенно, а всё что произошло кроме этого будет написано так что это реально разобрать, понять и быстро отреагировать. Можно просто изредка посматривать на протяжении дня на консоль в которой довольно редко появляется текст, зато если что-то пойдёт — это сразу можно поймать. Например недавно у меня начал подходить к концу пул DHCP, и я сразу узнал об этом увидев в консоли сообщение от DHCP (стоящем на домен контроллере) о том что DHCP-pool is 90% full, а не придя на работу через два-три дня и узнав что кто-то не может попасть в сеть.

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

— кто распечатал (логин)
— имя документа

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

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