我一直在脚本中的PowerShell的程序来从我的Windows 2012r2服务器拉取安全事件日志。 调查我的过程中的一个错误，以parsing事件到XML我发现了4656事件的“访问原因”属性中的一个非常奇怪的问题：
%%4423: %%1801 D:(A;ID;FA;;;S-1-5-21-527573203-644103923-227697207-2229)
%%4424: %%1801 D:(A;ID;FA;;;S-1-5-21-527573203-644103923-22769蹂ᢻ翼
事件日志剪辑
请注意，在DACL的最终ACE的事件分析结束时，由于某种原因，将最后的10个字符转换为中文unicode字符。 在eventvwr甚至改变了事件的其余部分的字体。 这发生在服务器上的随机文件和随机受托人SID的
我将在今天下午识别这些文件，而不用分析XML来尝试检测任何模式，任何人都会对这个奇怪的模式提出build议？ 我假设它与Microsoft安全事件日志logging的错误，但事情是相同的Unicodestringreplace不同的ANSIstring值，并在ACE的不同位置。 连接因素是它始终是最后一个ACE，但这就是我所得到的。
所以很明显，我发现自从我出生以来Windows已经存在的“IsTextUnicode”/“Bush Hid The Facts”错误…定义ACE的SDDL语言是一个以空字符结尾的string。 在不同的编码中处理空值的方式是导致ConvertSecurityDescriptorToStringSecurityDescriptor函数做这个奇妙的魔术。 请注意， IsTextUnicode函数和ConvertSecurityDescriptorToStringSecurityDescriptor函数共享相同的库：Advapi32。
以上假设logging在审计写入时被损坏。 我也假设它不是parsing上述函数输出的AuthzReportSecurityEvent函数中的一个错误。 我在MSDN上阅读的所有文档都涉及到server 2003的枚举，结构和function。 所以所有这些function和结构都可能与我在MSDN上读到的不同。
这个问题也可能在日志的读取时间; 有问题的函数是ReadEventLog （也分享Advapi32）和FormatMessage 。
我确信，“访问原因”属性已于2012年作为“dynamic访问控制”的一部分添加到文件审计结构中。 在那里。 上述任何function问题都可以应用于现在增加的事件消息的大小。
https://en.wikipedia.org/wiki/Bush_hid_the_facts https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656
编辑：微软声称已经解决了这个bug在Vista中，但正如你可以看到有一个Unicode发生转换问题在这里发生。 错误是一样的。 我将扩大说，函数IsTextUnicode是被传递给函数的string的统计分析。 虽然它永远不会是完美的，但这个问题是关于包含在事件消息的一个子部分中的行的终止。 事件消息的每个部分还包含一个结束符字节，所以我假设两个终止字节在unicode / ansi转换函数的逻辑中导致parsing问题，无论是读取还是写入。