.NET (Core and Framework)

21-Dec-08 12:12

Hello all, I have some wierdness.

using the very simple code below:

EventLog el = new EventLog("Security");
foreach (EventLogEntry elr in el.Entries)
{
Trace.WriteLine(elr.Message);
}

results with the following message:

The description for Event ID '4647' in Source 'Microsoft-Windows-Security-Auditing' cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them. The following information is part of the event:'S-1-5-21-51003140-4199384537-3980697693-500', 'Administrator', '26L2233A1-06', '0x86377'

As far as I can tell, it's like the .net framework can't find the source dll to resolve the message. I pulled out some old C++ code that did some event log processing and ran it on the same machine and sure enough I couldn't find the message DLL.

I know that Microsoft changed the event log API in vista/2008 but I thought the new API was backwards compatible.

Backwards compatible or not, I need to be able to read the security log on vista/2008.

Any ideas?

thanks,

Gene

Graham Bradshaw21-Dec-08 12:35

Graham Bradshaw

21-Dec-08 12:35

Can you read other logs? Application, System, DNS, FRS etc?

There isn't an API (in the Win32 SDK function sense) to read the text details from the event logs. Your C++ code is probably reading the MessageFile setting from the appropriate place in the registry, and doing a Loadlibrary / FormatMessage dance.

That won't work on Vista / 2K8. The message DLLs are referenced in a different way (look at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers). If the .NET framework only uses the "old" way, you'll have to roll your own.

ByStorm Software21-Dec-08 12:48

21-Dec-08 12:48

Thank you Graham,

I can read the application log correctly but that's probably because they are registering their message dlls in the old NT way instead of the new vista way.

I found the key that you reference, but couldn't find the "GUID" in the event log entry so I couldn't figure out the correct message dll to do the load/format message.

I couldn't find any documentation on all this mess; can you point me some?

thank you again,

gene

ByStorm Software21-Dec-08 14:32

21-Dec-08 14:32

Getting further, maybe the problem is that thre isn't a key for "Microsoft-Windows-Security-Auditing" in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels
hive.

I guess I could just enumerate the all the publishers values and look for the value "Microsoft-Windows-Security-Auditing" to get the message dll name.

I'll try that next. Wink | ;)

ByStorm Software22-Dec-08 16:58

22-Dec-08 16:58

well...I'm getting closer but I can't figure out how to get a "real" event ID for the security log.

for example,

Here is a sample event in C#:
EntryType SuccessAudit
EventID 0x00001210
Source "Microsoft-Windows-Security-Auditing"

now, I've figured out that the REAL event ID that the Vista Event API wants is -1342172656 or 0xB0001210, so the piece that I'm missing is the 0xB000???? path.

according to this http://msdn.microsoft.com/en-us/library/aa385646(VS.85).aspx it says that I'm suppose to shift the EntryType left by 30 but the EVENTLOG_AUDIT_SUCCESS is 8 so shifting it 30 bits slides it right off the DWORD.

Does anyone know how to turn a EventLogEntry into a Message DLL ID? I THINK it's all related that I can't figure out the facility and severity correct.

thank you for any help,

Gene

FXCOP CLSCompliant

#realJSOP19-Dec-08 4:52

19-Dec-08 4:52

How can I be sure that an assembly is CLS-compliant?

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

Lev Danielyan19-Dec-08 5:15

19-Dec-08 5:15

Do you mean, apart from checking if it's got the CLSCompliant(true) attribute?

Regards,
Lev

#realJSOP19-Dec-08 5:25

19-Dec-08 5:25

Yes. FXCOP says I should use the attribute if the assembly is CLSCompliant, but how do I know if it is?

Lev Danielyan19-Dec-08 5:34

19-Dec-08 5:34

I think you have two options:

1. Add the [assembly:CLSCompliant(true)] attribute to the assembly, and see what are the compiler's errors/warnings

2. Or if you need to do it in code, look at the CLS compliance restrictions in the ECMA 335 standard[^] (it's got a lot of info on CLS compliance) and check for these using Microsoft.Cci (the fxcop's backend) or Mono.Cecil

Regards,
Lev

#realJSOP19-Dec-08 5:41

19-Dec-08 5:41

Lev Danielyan wrote:
Add the [assembly:CLSCompliant(true)] attribute to the assembly, and see what are the compiler's errors/warnings

Yep, I did that and didn't get any errors or warnings.

Lev Danielyan19-Dec-08 5:42

19-Dec-08 5:42

Then you are safe to mark it with CLSCompliant attribute Smile | :)

Regards,
Lev

Lev Danielyan19-Dec-08 5:49

19-Dec-08 5:49

BTW, check out this article[^]

Regards,
Lev

Joe DiNatale19-Dec-08 5:37

Joe DiNatale

19-Dec-08 5:37

My understanding is that you should mark the attribute if you intend it to be CLS compliant and then compiler will let you know if it isn't.

Look here for more info.

-Joe.

Lev Danielyan19-Dec-08 5:41

19-Dec-08 5:41

That's what I said in my previous post. But I think it is more challenging to analyze the assembly and figure out if it is CLS compliant.

Regards,
Lev

#realJSOP19-Dec-08 5:42

19-Dec-08 5:42

"More challenging" = "more time-consuming".

Lev Danielyan19-Dec-08 5:45

19-Dec-08 5:45

Right, but it will give more knowledge on the guts of .Net, and eventually you will be writing compliant code right away (of course in those cases when you actually can make your assembly compliant), it can make some time savings as opposed to marking your stuff with attribute and fixing errors (especially for large products).

But this is just IMHO Wink | ;)

Regards,
Lev

I Just Discovered FXCop

#realJSOP19-Dec-08 3:28