joeware - never stop exploring... :)

So, I am working on this little app to dump all event log ID messages on a specific machine. MS used to offer a database with this info but I can’t seem to find anything newer than the NT4 version. They now have a nice website at

http://www.microsoft.com/technet/support/eventserrors.mspx

which is quite nice, however, if you are working on a monitoring solution or want to see all possible registered messages in one fell swoop, the output isn’t helpful.

So anyway, back to the tool. I have this tool that will enumerate all of the event sources and locate all of the Message ID files specified and then tear through all of the files looking for the Messages. When running it I kept running into error conditions causing all sorts of issues.

ISSUE #1

The registry is a pretty cool mechanism[1], each value has a specific type which tells you how to handle the value. For instance you have the following common types

REG_BINARY - This is binary blob data. No specific format, just a bunch of 0's and 1's.

REG_DWORD - DWORD value - aka double word.

REG_SZ - Zero terminated string, ASCII or UNICODE

REG_EXPAND_SZ - Like REG_SZ but could have variables in the file path specified that need to be resolved (expanded) to get the real file path. Such as %SystemRoot%\System32\dskquota.dll being expanded to e:\windows\system32\dskquota.dll.

So I ran into a couple of entries that were REG_SZ but have strings that need to be expanded… How fun, the official mechanism to tell me to do the expansion isn’t being used… Come on!!!

For posterity and anyone at MS interested in knowing, here are the entries.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ Application\appmgr
EventMessageFile REG_SZ %SystemRoot%\system32\serverappliance\mui\0409\sagenmsg.dll

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ Application\DiskQuota
EventMessageFile REG_SZ %SystemRoot%\System32\dskquota.dll
TypesSupported REG_SZ 0x00000007

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ Application\LicenseService
TypesSupported REG_DWORD 0x7
EventMessageFile REG_SZ %SystemRoot%\System32\llsrpc.dll

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ Application\mnmsrvc
EventMessageFile REG_SZ %SystemRoot%\System32\nmevtmsg.dll
TypeSupported REG_BINARY 07000000

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\ Application\Oakley
EventMessageFile REG_SZ %SystemRoot%\System32\oakley.dll
TypesSupported REG_DWORD 0x7

You will also note the deltas in the TypesSupported… Is it a REG_DWORD, a REG_BINARY, or a REG_SZ? According to the PSDK it is supposed to be REG_DWORD. This is a silly silly thing in my opinion. MS coders really shouldn’t be making mistakes like that. Barring that, it should be caught when someone else QC checks what is there. Stuff like this really frustrates other programmers writing code to utilize MS systems. You end up looking for the special ways to do things that are undocumented because things don’t work the way they were documented to. Then it gets fixed and the special ways figured out by others all break. Anyone who used the early DAO/ADO/OLEDB stuff know what I am talking about here. There was a while back in the late 90’s where you had to rewrite great sections of website code everytime MS issued an update to that stuff.

ISSUE #2

The next thing I ran into were files specified as Message Files or Category Files that simply don’t exist on the machines. This again is silly. How can you specify a file as the message file and then not have the file there? Now this is just going to eat resources when something tries to enumerate the event log entries if indeed there are any entries based on that. If it isn’t needed, stop the bloat, clean up. We don’t need anything slowing machines down; the processor upgrades that were occurring every year have slowed down since about 2001/2002 so there is nothing going to be saving us from poor performing bloated code anymore except well written and probably multithreaded code. Anyway, the software is already bloaty and slow enough.

The output with these errors is below in the next issue.

ISSUE #3

Next I ran into Message/Category files that are specified but don’t actually have MESSAGE_TABLE resources in them. This is worse than files not existing at all for the purposes intended because even more overhead is used as you open the file to find that what you wanted isn’t there.

Here is output of Issue #2 and Issue #3 errors for those interested:

2K
C:\temp>eventiddmp |findstr /i "error:"
ERROR: FindResource(1\MESSAGE_TABLE) in c:\winnt\system32\hostmib.dll: (1813) The specified resource type cannot be found in the image file.
ERROR: +++ Couldn't enumerate resources in c:\winnt\system32\hostmib.dll for Application\HostMIBAgent

ERROR: FindResource(1\MESSAGE_TABLE) in c:\winnt\system32\snmptrap.exe: (1813) The specified resource type cannot be found in the image file.
ERROR: +++ Couldn't enumerate resources in c:\winnt\system32\snmptrap.exe for System\SNMPTRAP

K3
C:\temp>eventiddmp |findstr /i "error:"
ERROR: FindResource(1\MESSAGE_TABLE) in c:\windows\system32\advapi32.dll: (1813) The specified resource type cannot be found in the image file.
ERROR: +++ Couldn't enumerate resources in c:\windows\system32\advapi32.dll for Application\Windows 3.1 Migration

ERROR: Couldn't open - c:\windows\system32\polagent.dll (2) The system cannot find the file specified.
ERROR: +++ Couldn't enumerate resources in c:\windows\system32\polagent.dll for System\PolicyAgent

ISSUE #4

This issue isn’t quite so bad but is pretty annoying. I have run into message files that have multiple embedded “\r” characters. Anyone used to c/c++/perl is aware that “\r” is a Carriage Return, i.e. return to beginning of line. Do you really need multiple “\r” characters in a row? How much more beginning of the line can you get after the first one? Also I have seen some interesting hex values embedded in some Messages that don’t really resolve to anything useful.

.

The tool is still under production, I am still in early alpha phase, it is pretty cool if I don’t say so myself, I can dump all registered messages for a machine in a few seconds to TAB delimited text files. One for each Event Log registered for the machine. Each line looks something like

"3221227973" "ERROR" "The trial period for Active Directory Application Mode (ADAM) trial version %1 %2 has expired. The ADAM service is shutting down." "e:\windows\adam\adammsg.dll" "ADAM (Adam1)\ADAM [Adam1] API;ADAM (Adam1)\ADAM [Adam1] Backup;ADAM (Adam1)\ADAM [Adam1] Database;ADAM (Adam1)\ADAM [Adam1] General;ADAM (Adam1)\ADAM [Adam1] Inter-site Messaging;ADAM (Adam1)\ADAM [Adam1] KCC;ADAM (Adam1)\ADAM [Adam1] LDAP;ADAM (Adam1)\ADAM [Adam1] MAPI;ADAM (Adam1)\ADAM [Adam1] Replication;ADAM (Adam1)\ADAM [Adam1] SAM;ADAM (Adam1)\ADAM [Adam1] Scripting;ADAM (Adam1)\ADAM [Adam1] SDPROP;ADAM (Adam1)\ADAM [Adam1] Security;ADAM (Adam1)\ADAM [Adam1] Setup;ADAM (Adam1)\ADAM [Adam1] XDS"

That is the event id, type of message (INFO, WARN, ERROR, or blank for unknown), message, message file, all sources that use that file for that eventlog.

Here is a security Event Log example

"686" "" "Password of the following user accessed:%n\n%tTarget User Name:%t%1%n\n%tTarget User Domain:%t%t%2%n\nBy user:%n\n%tCaller User Name:%t%3%n\n%tCaller Domain:%t%t%4%n\n%tCaller Logon ID:%t%t%5%n" "e:\windows\system32\msaudite.dll" "Security\Security"

And a system log example

"3221553153" "ERROR" "Not enough memory was available to allocate internal storage needed for the device %1." "e:\windows\system32\drivers\i8042prt.sys" "System\i8042prt"

I am not sure if I will publish this tool publicly or not, not sure whether or not a large number of people would find it useful. We shall see. If you have thoughts, let me know. Maybe it will go into the pay to play section of the website.

joe

[1] Not that I don’t think it is being used wrong currently, I think we more abuse it than use it at the current time. But maybe more on that later in another post. I have made comments about this in other public forums previously.