Application \ CAPI2事件513 – 处理System Writer对象中的OnIdentity（）调用时encryption服务失败

一个小组成员告诉我，我们的一个Windows Server 2008（不是2008 R2）的MSSQL服务器已经开始在应用程序事件日志中生成CAPI2事件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

好奇不？我不知道什么是系统编写器对象用于？影复制！噢！我本月开始使用Veeam进行这个虚拟机的基于VSS的Application Aware备份。自然地，备份过程从22:00开始，这解释了重复的频率，而不是刚刚在“随机”时间发生的错误。

有趣的是，Veeam没有注册这是一个失败的备份尝试，这让我怀疑还原点是否实际上是交易一致的。无论如何，我通过Veeam备份日志进行了快速search，没有发现任何明显的错误，但可能值得仔细检查它们，并确认从这些还原点进行恢复是事务一致的。

事件ID 513 TechNet参考推荐解决scheme表示NTFS权限问题可能是错误的，但是C:\Windows\Registration COM +注册文件夹具有适当的权限。

想法？

Mathias R. Jessen让我指出了正确的方向，即着名的WinSxS文件夹。然而，我没有看到事件日志中的任何VSS错误，这使得我有点犹豫，只是努力所有的NTFS权限，以免我打破别的东西。

第一课：阅读

我又回过头去阅读了事件ID 513的TechNet参考资料，并注意到在Verify部分下，build议我查看System Writer作为VSS编写者使用vssadmin list writers ，当然这不是。 经验教训＃1：阅读整个KB / TechNet /博客

第2课：重现

做了一些更多的研究，我遇到了Missing System Writer Case Explained ，这似乎表明这个问题是由Cryptographic Services发起的。我发现我可以通过停止和启动CryptSVC服务CryptSVC复制CAPI2错误。 经验教训＃2：尝试找出一种方法来随意复制你的错误。

使用ProcMon

在这一点上，我几乎遵循了这个职位的指示。我find哪个svchost实例使用任务pipe理器包装CryptSVC的PID。如果可以重新启动服务器，则可以使用sc config强制CryptSVC作为自己的进程运行。根据您进入ProcMon的深度，在单个PID下分离服务是值得的，以减less您必须sorting的事件数量。

从这里回到了古老的ProcMon。设置一个filter，以排除所有CryptSVC的svchost进程所使用的PID：

ProcMon排除过滤器

第三课：爱情亲爱的

我申请了我的可靠的第一次通过filter，这是排除所有事件的成果的SUCCESS 。这使事件从31,118减less到更易于pipe理的139，并且在底部我发现了我正在寻找的ACCESS DENIED事件，在WinSxS文件夹（ C:\Windows\winsxs\FileMaps\$$.cdf-ms ）。 经验教训＃3：学习使用和爱ProcMon

$ProcMon ACCESS DENIED在C：\ Windows \ winsxs \ FileMaps \ $$。cdf-ms$

第四课：validation

怎么办？ Mathias链接的KB2009272有解决scheme，但现在我知道为什么 。 经验教训＃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 System Writer器。无需更改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错误，经过一两天的监控，看起来已经解决了。