I was deploying a SharePoint 2010 web part recently. The deployment completed, including feature activation, but when I put the part on a page, it failed with a correlation ID. The correlation ID didn’t take me far but I noticed this in my log:
The source was not found, but some or all event logs could not be searched. Inaccessible logs: Security.
The web part I was deploying has very little in the way of activation, just a feature containing a web part with no content types, lists, custom feature receivers, or otherwise.
A Bing search seemed to point this to a permissions problem or an issue with Service Packs. None of these were relevant in my case, the deploying and testing user was a farm admin and local machine admin.
Then I remembered that I was doing a lot of logging. I’m not a SharePoint logging expert and the code I used was a combination of adaptation from other Catapult projects and research from MSDN. Plus, this error was suggesting event logs, which I wasn’t trying to write to.
Inspecting my code, my logging object is based off SPDiagnosticServiceBase. I have a series of chained write events that were tied to a (base.)WriteEvent(…). I changed this from WriteEvent to WriteTrace. The error went away on re-compile and -deploy.
It appears as if this error comes from unregistered categories in the local machine event log. WriteEvent writes to the event log and relies on the category posted having been registered. Some web searches on this show that a feature receiver may be a good place to register categories because it must run with an elevated permission level anyhow. Instead, I chose a simpler option, writing to the ULS.
Logging is a critical piece for maintainability for applications that we develop and upgrade. All code has bugs, therefore all code will fail at some point. This should be usual and expected. When code fails, having meaningful, unpolluted logs takes us a long way to being able to fix a problem. Many problems are intermittent and difficult to reproduce. Having good logs sometimes prevents the need to reproduce something that could happen very occasionally. Also, many of our users are in environments that are difficult to reproduce. Shipping a log for information is much easier than shipping an environment to reproduce an issue.