.net - Windows 事件 ID

Question

Windows 中是否为应用程序开发人员保留了特定范围的事件 ID？

我正在开发一个将错误写入 Windows 事件日志的 .Net 应用程序。这个应用程序实际上以服务器为目标，并且将由偏执的系统管理员作为计划任务运行，他们希望尽可能多地锁定它(包括使用降低权限的维护帐户运行它)。该应用程序不会被正式安装——事实上，我什至没有为此构建安装程序；只是一个包含 .exe 和 app.config 文件的 zip 文件。

技巧如下:在 Windows 中，您需要管理员权限才能在应用程序事件日志中创建源。由于我不能指望这一点，而且我不想让过度劳累的系统管理员需要创建一个，我使用“应用程序错误”(由 MS Office 使用)作为后备。 (选择一个更好的后备方案在我的待办事项列表中，因为 office 并不经常安装在服务器上)。

问题是我仍然希望我的事件突出一点，而不是仅仅伪装成 Office。这样，我的系统管理员可以轻松地过滤到事件查看器或他们选择的日志聚合器中的那些事件。我现在知道的最佳解决方案是使用事件 ID，但我担心与内部 Windows 事件发生冲突，尤其是考虑到我的目标受众。

我看过了，但找不到任何相关文档。那么，我应该使用特定范围的事件 ID 吗？我可以使用任何一种吗？还是我应该在这里查看一个完全不同的选项？

Answer 1

不是真的。在顶层，您有一个事件源。每个事件源都有自己的事件类别。每个事件消息都由一个事件源“拥有”并属于其事件类别之一。如果您打算在其他人的事件源下记录您的事件，那么您就违反了这一约定，很可能会发生事件 ID 冲突。

另一方面，Event IDs在结构上类似于 HRESULT，并且您可以设置一个 Customer 位。还有一个 Facility Code 字段，但是 Microsoft 只为 3rd parties 提供了一个 facility(其余的都是保留的)。即使你弄乱了这些位，你仍然会受到事件源所有者的摆布；如果 Microsoft 曾经向您正在使用的事件源写入某些内容并设置客户位或设施代码(例如，可能是非 Windows 组件，如 Office 或其他东西)，您将再次面临同样的碰撞危险。或者，如果其他开发人员决定做与您正在做的事情相同的事情。真正最安全的方法是定义您自己的事件源。