我已为事件记录器创建了一个类别文件,但类别名称未显示在事件记录器中。
但是,如果我从C:\ Windows \ System32 \ winevt \ Logs打开日志,则会显示类别名称。如果我使用以下PowerShell,则类别名称也会显示。
$eventlog = New-Object System.Diagnostics.EventLog("MyLog")
Write-Host $eventlog.Entries[0].Category
.mc文件如下所示:
MessageIdTypedef = WORD
LanguageNames=(
English=0x0409:MSG00409
Swedish=0x041D:MSG0041D
)
MessageId=1
SymbolicName=CAT_1
Language=English
Category 1
.
Language=Swedish
Kategori 1
.
MessageId=2
SymbolicName=CAT_2
Language=English
Category 2
.
Language=Swedish
Kattegori 2
.
; // Up to 22 categorys
在注册表中,我有以下内容:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\MyLog\MySource]
"CategoryCount"=dword:00000016
"TypesSupported"=dword:00000007
"CategoryMessageFile"="C:\\path\\Messages.dll"
我发现https://social.msdn.microsoft.com/forums/windowsdesktop/en-us/3fed3069-ce0f-4168-8132-4d19d66fdd7e/windows-7eventlog-creating-custom-categories遇到了同样的问题,但没有回答问题。
我在Windows 7,8和Windows Server 2008 R2中都试过这个
修改
我创建了一个测试项目来展示我的成就。下载 here
答案 0 :(得分:2)
尝试将计算机的Authenticated Users
或Users
组添加到邮件文件夹的安全级别。保留默认权限。然后重新启动或尝试重新启动EventLog服务。
在管理员命令提示符下:net stop eventlog
您可能会被提示关闭其他服务。您必须输入Y
才能继续。关闭的服务通常会自行重启,因此您只需等待几秒钟。事件日志服务可能无法关闭,因为另一个服务已重新启动,可能需要几次尝试才能解决所有问题。仔细观察生成的文本状态。
我在将源注册表信息指向我的VS项目中的消息文件夹时遇到了同样的问题。我发现它在我创建了一个带有管理员用户的C:\Test
文件夹并开始引用之后就开始工作了。这和项目文件夹之间的唯一区别是两组。添加两个组中的任何一个都可以解决问题。将它们从两个文件夹中取出都会使它停止。
我还发现,如果我在CategoryMessageFile
和我的EventMessageFile
中匹配了MessageId,则会忽略CategoryMessageFile
。
答案 1 :(得分:0)
显示EventMessageFile
和CategoryMessageFile
重叠的MessageId
时,出现相似症状的另一种可能性(虽然显然不是OP的问题(或语言))。我认为这是查看“实时”源时事件日志查看器实用程序中的错误,因为使用Powershell,.NET或直接在事件查看器中打开事件日志文件以解析事件日志时,症状不存在
在我的情况下,我有一个.NET应用程序,并且正在使用.NET API通过EventSourceCreationData
指定CategoryResourceFile
和CategoryCount
来创建事件源。默认情况下,MessageResourceFile
将设置为C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll
。这些API的作用导致创建appropriate registry keys CategoryMessageFile
,CategoryCount
和EventMessageFile
。这里要注意的重要一点是.NET的消息文件有助于将0x0到0x000FFFF的消息全部定义为%1\r\n\x00
-本质上意味着在使用EventLog.WriteEntry以默认方式创建事件消息时,会看到与事件ID无关的已记录的字符串消息。如果改为使用EventLog.WriteEvent,则非常需要使用专门的消息文件(请参阅EventInstance类上的文档)。 More Info
症状是,当查看实时事件查看器时,传递给事件日志的MessageId定义的类别显示为整数而不是资源文件中的字符串。请注意,这与您错误配置类别资源文件,权限问题等不同,在“任务类别”中看到的是“整数”但括号中的内容。
例如,如果您指定类别ID 8,并且期望本地化的类别名称“我的类别”,则事件查看器可以显示以下三项之一:(8)
表示CategoryMessageFile
或{{1 }}注册表项配置错误或dll有问题。 CategoryCount
,如果一切正常。 My Category
,如果您遇到我要描述的问题。
感谢Rich Shealer对指针的回答。问题不是像从人们期望的那样从8
获取Category字符串,而是从CategoryMessageFile
获取它,并且由于.NET资源文件仅仅是一个返回第一个元素的格式字符串源数据中将生成数字类别ID。
没有“好的”解决方法,但是在我的使用案例中,使用通过日志记录框架提供的元数据来记录消息,并进行一些过滤,消息中的类别和事件ID通常为零,但我要特别设置的地方除外当记录一小部分日志消息时记录一个。这意味着日志记录框架正在调用API来写入日志条目。一种解决方法是在.mc文件中将Messagex的0x0声明为MessageResourceFile
,并且仅以比您期望的类别数更高的数字来启动事件ID。然后在注册表中或通过属性%1
配置EventMessageFile
,以首先指定类别文件,分号分隔符,然后指定.NET默认资源文件。这将正确显示事件ID和类别ID,并且事件ID大于类别文件的事件具有与以前相同的行为,并且消息记录为0。但是,任何定义了数字的eventid都会与类别冲突-好吧,您将获得类别名称作为日志消息。您也可以删除消息资源文件,但随后会收到烦人的“找不到资源”消息。我在这里确认了行为,但拒绝这样做-将与丢失的文本一起使用,因为我主要使用API进行分析,并且在此处是正确的。
可悲的是,我找不到Windows事件查看器的任何未解决的问题-我发现它在Windows 10 build 1909中已损坏。