Windows中是否为应用程序开发人员保留了特定范围的事件ID？
我正在开发一个将错误写入Windows事件日志的.Net应用程序。此应用程序实际上以服务器为目标，并将由偏执的sys管理员作为计划任务运行，他们希望尽可能地将其锁定（包括使用减少的权限维护帐户运行它）。该应用程序将不会正式安装 - 事实上，我甚至没有为此构建安装程序;只是一个包含.exe和app.config文件的zip文件。
这就是诀窍：在Windows中，您需要管理员权限才能在应用程序事件日志中创建源。由于我不能指望这一点，我不想让过度工作的系统管理员需要创建一个，我使用“应用程序错误”（由MS Office使用）作为后备。 （选择一个更好的后备是在我的待办事项清单上，因为办公室不经常安装在服务器上）。
问题在于我仍然希望我的活动能够脱颖而出，而不仅仅是伪装成Office。这样，我的系统管理员可以轻松过滤到事件查看器中的那些事件或他们选择的日志聚合器。我现在知道的最佳解决方案是使用事件ID，但我担心与内部Windows事件冲突，特别是考虑到我的目标受众。
我看了，但我找不到任何关于此的文件。那么，我应该使用特定范围的事件ID，我可以使用任何东西吗，或者我应该在这里看一个完全不同的选项？
答案 0 :(得分：4)
不是真的。在顶层，您有一个事件源。每个事件源都有自己的事件类别。每个事件消息由事件源“拥有”并属于其事件类别之一。如果您要在其他人的事件源下记录您的事件，那么您违反了此约定，很可能会发生事件ID冲突。
另一方面，Event IDs在结构上与HRESULT类似，并且您可以设置一个Customer位。还有一个Facility Code字段，但Microsoft仅为第三方提供了一个工具（其余的是保留的）。即使你搞砸了这些比特，你仍然受到事件源所有者的支配;如果微软曾经在你正在使用的事件源上写东西并设置客户位或设施代码（例如可能是非Windows组件，如Office或其他东西），那么你将会遇到相同的冲突危险。或者，如果其他开发人员决定做同样的事情。真正最安全的方法是定义自己的事件源。
答案 1 :(得分：2)
这似乎是问题的症结所在
我担心与内部Windows事件冲突，特别是考虑到我的目标受众。
我认为您不必担心，因为事件ID对应于特定的事件源，所以除非您使用完全相同的源，否则不会导致管理员感到不安。例如，MS有时会uses the same ID使用不同的来源。
如果您想获取有关已注册发布商和活动ID的信息，可以使用Wevtutil例如，这会列出发布商。
wevtutil ep
从中您可以获得用于发布者的特定事件ID，您可以使用以下内容（此示例中使用了事件日志）
wevtutil gp Microsoft-Windows-EventLog /ge /gm:true
如果你擅长powershell，我相信你可以拿出一个脚本来获取所有注册的活动ID