At last! Something to write about!

There have been various reports of the logging in MSS 2004 going mysteriously silent. I got to investigate one of these issues for the first time yesterday. The symptoms were that only TimLogger was writing anything to the ETL file. (I.e. the only events showing up were CallStartedEvent, AnswerCallLatencyEvent, etc.) Footling with MssLogConfig.vbs made no difference. The logging config file TasInstrumentation.config seemed correct. (SES was running on different machines, so only TAS events were expected.) No errors or warnings were reported in the NT Event Log.

It turns out the issue was that the customer was not running TAS as NetworkService, but as a special user MSS_USER. When I tried this myself I found I got this warning in the Event Log:

The first thing I did was give MSS_USER write access to the directory with the ETL logs in it. In theory this is all you need to do but no dice. Next I tried adding MSS_USER to the "Performance Log Users" Group. Success! The warning diappeared and TAS events started appearing in the ETL file. So what is going one here? According to MSDN you only need to be in that group to "control" ETW sessions (i.e. start and stop collection to an ETL file.) Writing events to a session requires no special privilege.

Looking at the code I found that MSS logging calls QueryTrace to get the size of the ETW buffer and as far as I can see it only does this so it can print a nice warning if you set it too low, or if someone tries to log an event which is bigger than one buffer. Since 99% of users will enable logging from the MSS Management Console, and therefore will be using a buffer size of 60k, this seems fairly pointless.

I will definitely fix this in MSS 2006. I'm glad there is an easy workaround for MSS 2004 users.

[Update 10/19/05: It turns out this is actually documented in the MSS help. Whoever discovered this the first time must have thought it was a feature of ETW rather than a bug in MSS.]