ExceptionPolicy.HandleException does not install Event Source for Logging in Registry if XBAP run outside debugger

Question

I am using the Logging Application Block (of Microsoft Enterprise Library) to log exceptions in the Event Viewer that occur in my WPF XBAP application.

If I run the XBAP in the debugger from Visual Studio, an Event Source entry for my application is automatically created in the Registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\MyApp

This occurs at the point ExceptionPolicy.HandleException() is called.

However, if I run the XBAP outside of the IDE directly from the file system or from its published location, the Registry entry isn't added. Therefore, no logging takes place.

I can only assume this is a security issue with running XBAP applications and they do not have access to write to the Registry. Is this a setting within my project? Any idea on why this might be happening?

Any help much appreciated.

Answer 1

You are right about it being a permission problem.

If you try to log to the event log and the event source does not exist the runtime will attempt to create a registry entry for the event source. If you don't have permission then a System.Security.SecurityException with a message of "Requested registry access is not allowed." is thrown. Enterprise Library catches this exception and attempts to log saying that it couldn't log the message. If that also fails then the exception is swallowed.

The application is running in a partial trust sandbox so wouldn't have permission to create registry keys. You could try configuring the application to run as a Full Trust Application. Although this post says that there may still be a problem with that.

This issue also arises frequently when logging from ASP.NET and the usual solution is to create the required registry keys during the deployment process. For WPF this feels a bit wrong, but is it possible to create a Windows Installer (.msi) that installs the registry keys? Then the application wouldn't need to write to the registry (although it would still need to read from the registry so hopefully there is no permission problem with that!).

UPDATE in response to comment

As mentioned in the URL above:

Yes, this is a design flaw in our hosting process. You get "full trust" from CLR point of view, but not in terms of NT security. We'll try to address this issue in a future release.

I'm not sure if the issue has been resolved or not but it may be what you are seeing.