问题标签 [etw-eventsource]

正如问题所述，如果我的服务中发生异常，我希望它显示在管理通道中，这样我们就不必打开诊断来在调试通道中看到它。例如，如果未打开日志，我们可能会错过该事件。但是，很高兴在跟踪的上下文中看到调试通道中的错误。为了实现这一点，我需要在两个频道中都显示它。

使用 ETW 实现这一目标的最佳方法是什么？

我正在尝试使用新的 EventSource（来自 nuget 的 Microsoft.Diagnostics.Tracing.EventSource）及其对 ETW 通道的新支持，以便写入 Windows 事件日志。代码就位，它正确地写入了我的工作站事件日志。我很激动。

现在是困难的部分。利用此功能的应用程序是 Web 服务，我们使用 webdeploy 将其部署为构建-部署-测试系统的一部分。因为使用 ETW 通道需要通过 wevtutil.exe 静态注册提供程序清单。EventSource 文档指出，这最好作为安装程序的一部分来完成，但这似乎有点超出了 webdeploy 的能力。

我们的目标是能够在执行 webdeploy 包之前立即自动卸载驻留在目标服务器上的清单，然后在 webdeploy 同步完成后导入新的清单。我们不打算这样做，但这似乎是最明智的方式。

出于这个原因，这似乎是 powershell 远程处理可能能够解决的问题，但这不是我很了解的领域。

有没有人做过这样的事情？有没有更好或更简单的方法？

我们正在使用 EventSource nuget 包，但我们遇到了构建错误：

我们可以通过在 Machine.Config（1.0.0.0 到 2.2.0.0）中转发程序集来解决这个问题，但这感觉像是一个糟糕的“修复”。我根本不明白为什么 EventRegister 应用程序应该加载 Azure 服务运行时，这对我来说没有意义。

我刚刚升级了我的服务以使用最新的 NuGet ETW 包，之前使用的是 beta 版本。但是，似乎通道支持已从事件源中删除。

有谁知道这里发生了什么？

对于当前使用 Castle 的Logging Facility和 log4net的应用程序，开始使用新的 .NET 4.5 EventSource类进行日志记录的最佳方式是什么。

最初我认为可能扩展 Castle 的 ILogger 接口以支持 EventSource 促进的更丰富的语义式日志记录（引发的问题），但现在我不太确定它们是否真的可以很好地协同工作。

我注意到语义日志记录应用程序块提供了一种使用 EventSource 的实现，但这当然不是使用 ILogger。

我在我的一台服务器上收到此错误：

我有另一台服务器，我认为它的设置相同。但是，当我运行 ETW SLAB 服务以侦听从我的事件源发出的 ETW 事件时，我收到上述警告，但在其他服务器上没有。什么会导致这个？

我正在使用新的 EventSource 类从我的应用程序写入 Windows 事件日志，到目前为止它很棒。但是，我观察到有两件事会导致可能相关的问题：传递给 Event 属性的格式字符串在写入事件日志之前似乎没有经过正常的 string.Format 处理。

考虑这个块：

会发生一些事情：

• 如果我尝试在消息的格式字符串中插入 \n，则事件日志中不会打印换行符。
• 如果签名字符串包含换行符，则换行符会自然地打印在事件日志中。
• 如果签名或 homepageAddress 字符串包含类似 ETW 的标记（%1、%2 或 %3），则 ETW 开始将这些伪标记替换为变量本身，并且最终得到嵌套在它们自身中的变量。

我假设如果 ETW 有一个转义字符，它可以用来在格式字符串中放置换行符，并且还允许我预处理我的字符串值以防止这些 sql 注入样式错误。

这样的转义字符是否存在？这通常是怎么做的？

我在使用 .NET 4.5 System.Diagnostic.Tracing.EventSource 时遇到了一些问题。您可以在本文末尾找到完整的 EventSource 实现。

当我为此 EventSource 创建一个侦听器时，它永远不会收到事件。所有提示或问题将不胜感激。

编辑1：-尝试了Microsoft.Practices.EnterpriseLibrary.SemanticLogging.ObservableLog->不行。- 将 EventLevel 设置为详细的侦听器。- 我可以使用 PerfView.exe 捕获事件

我如何激活我的听众：

我的听众：

事件来源：

}

我正在使用来自 nuget的新 .NETEventSource API 。我已经构建了我的应用程序，并使用wevtutil.exe. 当我在事件查看器中查看它们时，我的事件日志条目包括以下文本：

消息的最后一部分似乎特别值得注意：“消息资源存在，但在字符串/消息表中找不到消息。”

为什么我的资源 DLL 不起作用？

使用Microsoft TraceEvent 库，可以解析由xperf、WPR或PerfView生成的 ETL 文件。

我发现 TracEvent 中的 Event ImageIDFileVersion 向我显示了文件版本，而 Event ImageGroup 向我显示了文件的文件路径。现在我需要将两个事件映射在一起，并且需要一种方法来确保两个事件都指向 ETL 跟踪文件中的同一个文件。