我正在检测我的 .NET 4.5 应用程序以使用EventSource该类发出 ETW 事件。目标是能够捕获其中一些事件（错误级别事件）以进行错误记录。
在做了一些阅读和测试之后，我担心这种错误记录方法的可靠性，特别是关于丢失或丢失事件的可能性。如果我的错误记录不起作用，我需要关闭应用程序（在我的情况下，它运行未报告的错误是不安全的）。使用 ETW 和EventSource时，如何确定我的错误得到正确记录？
显然，部分答案将取决于监听事件的内容。就我而言，我计划使用最新的 MS 企业库中的“语义日志记录应用程序块”。
以下是 Microsoft 谈论错过事件的可能原因的一个来源： 关于事件跟踪
他们在那里列出了丢失事件的这些可能原因
总事件大小大于 64K。这包括 ETW 标头以及数据或有效负载。由于事件大小由应用程序配置，因此用户无法控制这些丢失的事件。
ETW 缓冲区大小小于总事件大小。用户无法控制这些丢失的事件，因为事件大小是由记录事件的应用程序配置的。
对于实时日志，实时消费者没有足够快地消费事件或完全不存在，然后支持文件被填满。如果在记录事件时停止并启动事件日志服务，则会出现这种情况。用户无法控制这些丢失的事件。
记录到文件时，磁盘速度太慢，无法跟上记录速度。
为了查看使用 EventSource 类是否以某种方式缓解了这些问题（例如，它是否会以某种方式截断大型有效负载），我进行了一些测试。我尝试记录长字符串，但它在 30,000 到 35,000 个字符之间失败（与 64KB 最大事件有效负载一致）。对于太大的字符串，它只是默默地没有做任何事情，在我的语义日志记录应用程序块日志中根本没有任何事件。之前和之后的事件像往常一样写。
所以每当我的有效载荷中有一个字符串时，我必须通过一些截断器传递它？我是否也需要手动避免生成“太快”的事件（这怎么可能）？
Microsoft Patterns and Practices 应该引导我们找到好的......模式和实践......所以也许我只是在这里遗漏了一些东西。
更新：
显然，在消费应用程序中有一些“事件太快”条件的通知。我今天第一次收到这个：
级别：警告，消息：由于缓冲区溢出或跟踪会话中的架构同步延迟，某些事件将丢失：Microsoft-SemanticLogging-Etw-svcRuntime
然后在关闭会话时：
级别：警告，消息：在跟踪会话“Microsoft-SemanticLogging-Etw-svcRuntime”中检测到丢失 1 个事件。
更新2：
Enterprise Library Developers Guide描述了我刚才提到的行为。
您应该监视语义日志记录应用程序块生成的日志消息，以了解缓冲区溢出和丢失消息的任何迹象。例如，事件 id 为 900 和 901 的日志消息表明接收器的内部缓冲区已溢出；在进程外场景中，事件 ID 806 和 807 表示 ETW 缓冲区已溢出。您可以修改接收器的缓冲配置选项，以减少缓冲区因典型工作负载而溢出的可能性。
我的问题仍然存在，我是否可以在使用语义日志记录的同时确保在删除错误时我的应用程序不会运行？可以丢弃正常的跟踪事件...
我目前的想法是使用老式日志记录技术在单独的类中记录“严重”错误，并通过 ETW 管道保留不太严重的错误（以及调试类型事件）。这真的不会太糟糕......如果我找不到更好的建议，我可能会将其作为解决方案发布。
更新 3：
我收到的“丢失事件”警告与缓冲区溢出无关，事实证明这是您将 nullstring作为有效负载值传递时收到的消息。