Член группы сообщил мне, что один из наших серверов MSSQL на базе Windows Server 2008 (не 2008 R2) начал генерировать ошибки CAPI2 Event ID 513 в журнале событий приложений:
Application\CAPI2
Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
Details:
AddCoreCsiFiles: BeginFileEnumeration() failed.
System Error: Access is denied.
Небольшой PowerShell показывает, что проблема возникла еще 08.06.14 и в основном возникает после 22:00 ежедневно:
PS C:\Users\Administrator> Get-EventLog -LogName Application | ? { $_.EventID -like "513" -and $_.Source -like "Microsoft-Windows-CAPI2" } | Select -Property TimeGenerated
TimeGenerated
-------------
8/18/2014 10:41:32 AM
8/18/2014 10:25:17 AM
8/18/2014 10:15:20 AM
8/17/2014 10:55:41 PM
8/17/2014 10:55:27 PM
8/17/2014 10:55:26 PM
8/16/2014 10:49:44 PM
8/16/2014 10:49:28 PM
8/16/2014 10:49:28 PM
8/15/2014 10:52:11 PM
8/15/2014 10:51:58 PM
8/15/2014 10:51:57 PM
8/15/2014 1:03:06 AM
8/15/2014 1:02:45 AM
8/15/2014 1:02:45 AM
8/13/2014 10:58:49 PM
8/13/2014 10:58:32 PM
8/13/2014 10:58:31 PM
8/12/2014 10:57:09 PM
8/12/2014 10:56:56 PM
8/12/2014 10:56:56 PM
8/11/2014 10:56:13 PM
8/11/2014 10:55:56 PM
8/11/2014 10:55:55 PM
8/10/2014 10:50:15 PM
8/10/2014 10:50:04 PM
8/10/2014 10:50:03 PM
8/10/2014 7:12:09 AM
8/10/2014 7:11:52 AM
8/10/2014 7:11:51 AM
8/8/2014 10:57:00 PM
8/8/2014 10:56:44 PM
8/8/2014 10:56:43 PM
8/6/2014 9:47:26 PM
8/6/2014 9:47:03 PM
8/6/2014 9:47:02 PM
8/6/2014 10:48:33 AM
Любопытно, нет? Интересно, для чего используется объект System Writer? Теневая копия! Ах да! В этом месяце я начал делать резервные копии этой виртуальной машины с учетом приложений на основе VSS с помощью Veeam. Естественно, процесс резервного копирования начинается в 22:00, что объясняет повторяющуюся частоту, а не ошибку, возникающую в «случайное» время.
Интересно, что Veeam не зарегистрировал это как неудачную попытку резервного копирования, что заставляет меня задуматься о том, что точки восстановления являются на самом деле транзакция согласована. Несмотря на это, я быстро просмотрел журналы резервного копирования Veeam и не нашел ничего явно неправильного, но, вероятно, стоит просмотреть их поближе и подтвердить, что восстановление из этих точек восстановления согласовано с транзакциями.
В Справка по TechNet с кодом события 513 Рекомендуемое разрешение указывает на то, что проблема с разрешениями NTFS может быть связана с C:\Windows\Registration
Папка регистрации COM + имеет соответствующие разрешения.
Идеи?
Матиас Р. Джессен указал мне в правильном направлении, когда-либо известная папка WinSxS. Однако я не видел ни одной из ошибок VSS в журнале событий, из-за чего я немного не решался просто уничтожить все разрешения NTFS, чтобы я не сломал что-то еще.
Я вернулся и прочитал Справка по TechNet с кодом события 513 снова и отметил, что под Проверить раздел, было рекомендовано проверить, чтобы увидеть System Writer
был доступен как писатель VSS с использованием vssadmin list writers
и, конечно же, это НЕ было. Извлеченный урок №1: прочтите весь KB / TechNet / Blog
Проведя немного больше исследований, я наткнулся на Объяснение случая отсутствия системного писателя что, казалось, указывало на то, что проблема возникла с Криптографические услуги. Я обнаружил, что могу воспроизводить CAPI2
ошибка по желанию путем остановки и запуска CryptSVC
служба. Извлеченный урок №2: попробуйте придумать способ воспроизвести вашу ошибку по своему желанию.
В этот момент я в значительной степени следил за сообщения инструкции. Я нашел PID того экземпляра svchost
упаковывал CryptSVC
с помощью Диспетчер задач. В качестве альтернативы вы можете заставить CryptSVC
запустить как собственный процесс, используя sc config если вы можете перезагрузить рассматриваемый сервер. В зависимости от того, насколько глубоко вы вникнете в ProcMon, стоит изолировать сервисы под одним PID, чтобы сократить количество событий, которые вам нужно отсортировать.
Отсюда он вернулся к старому доброму ProcMon. Настройте фильтр, чтобы исключить все PID, которые не используются svchost
процесс, который оборачивается CryptSVC
:
Я применил свой надежный фильтр первого прохода, который исключает все события, которые имеют результаты SUCCESS
. Это уменьшило количество событий с 31 118 до гораздо более управляемых 139, а внизу я обнаружил ACCESS DENIED
событие, которое я искал, что неудивительно в WinSxS
папка (C:\Windows\winsxs\FileMaps\$$.cdf-ms
). Извлеченный урок № 3: научитесь использовать ProcMon и полюбите его
Что теперь? KB2009272 Связанный Матиас имеет решение, но теперь я знаю почему. Извлеченный урок №4: не угадайте, знайте!
Разрешение точно такое, как описано в KB2009272. Возьмите на себя ответственность и сбросьте разрешения для FileMaps
папку, а затем перезапустите CryptSVC
:
Takeown /f %windir%\winsxs\filemaps\* /a
icacls %windir%\winsxs\filemaps\*.* /grant "NT AUTHORITY\SYSTEM:(RX)"
icacls %windir%\winsxs\filemaps\*.* /grant "NT Service\trustedinstaller:(F)"
icacls %windir%\winsxs\filemaps\*.* /grant BUILTIN\Users:(RX)
net stop cryptsvc
net start cryptsvc
и ... мы взлетели! В System Writer
теперь доступен как писатель VSS. Нет необходимости изменять разрешения для PendingRename
папка. Извлеченный урок № 5: Начните с мельчайших изменений и постарайтесь сделать так, чтобы изменения повлияли на большее количество вещей.
C:\Users\administrator>vssadmin list writers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.
Writer name: 'System Writer'
Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
Writer Instance Id: {98c52075-429a-4487-8b77-e42b18767458}
State: [1] Stable
Last error: No error
Перезапуск CryptSVC
по желанию больше не производил CAPI2
ошибка, и через день или два мониторинга она кажется решенной.