Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the hueman domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/CloudIngenium.com/htdocs/wp-includes/functions.php on line 6114
Why is the Logging Application Block Not Writing to Vista Event Log? – Knowledge eXchange

Why is the Logging Application Block Not Writing to Vista Event Log?

Q: I’m currently working with Enterprise Library 4.1 and have set up the Logging Application Block on my Web.Config so that exceptions can be handled and logged on the event log. I have checked the configuration parameters and all the calls to the Logging Application Block but I’m not able to get it to record anything on the Event Log. I have checked with other people and the Event Log is working fine in Windows XP, Windows 7 and Windows Server 2003, so for some reason it has something to do with Vista. Any thoughts?

Here is a sample of the Web.Config for the Logging Application Block

<loggingConfiguration name=Logging Application Block tracingEnabled=true

defaultCategory=Default Category logWarningsWhenNoCategoriesMatch=true>

<listeners>

<add source=SOLA.CTS Logging formatter=Default Formatter

log=Application machineName=. listenerDataType=Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

traceOutputOptions=None filter=All type=Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Event Log Destination />

<add fileName=trace.log header=“” footer=“” formatter=“” listenerDataType=Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

traceOutputOptions=None filter=All type=Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Flat File Destination />

</listeners>

<formatters>

<add template=Timestamp: {timestamp} Message: {message} Category: {category} Priority: {priority} EventId: {eventid} Severity: {severity} Title:{title} Machine: {machine} Application Domain: {appDomain} Process Id: {processId} Process Name: {processName} Win32 Thread Id: {win32ThreadId} Thread Name: {threadName} Extended Properties: {dictionary({key} – {value} )}

type=Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Default Formatter />

</formatters>

<logFilters>

<add categoryFilterMode=AllowAllExceptDenied type=Microsoft.Practices.EnterpriseLibrary.Logging.Filters.CategoryFilter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Category />

<add minimumPriority=0 maximumPriority=2147483647 type=Microsoft.Practices.EnterpriseLibrary.Logging.Filters.PriorityFilter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Priority />

</logFilters>

<categorySources>

<add switchValue=All name=Default Category>

<listeners>

<add name=Event Log Destination />

</listeners>

</add>

<add switchValue=All name=Tracing>

<listeners>

<add name=Flat File Destination />

</listeners>

</add>

</categorySources>

<specialSources>

<allEvents switchValue=All name=All Events>

<listeners>

<add name=Event Log Destination />

</listeners>

</allEvents>

<notProcessed switchValue=All name=Unprocessed Category>

<listeners>

<add name=Event Log Destination />

</listeners>

</notProcessed>

<errors switchValue=All name=Logging Errors &amp; Warnings>

<listeners>

<add name=Event Log Destination />

</listeners>

</errors>

</specialSources>

</loggingConfiguration>

<exceptionHandling>

<exceptionPolicies>

<add name=Logging Policy>

<exceptionTypes>

<add type=System.Exception, mscorlib postHandlingAction=NotifyRethrow

name=Exception>

<exceptionHandlers>

<add logCategory=Default Category eventId=100 severity=Error

title=Application Exception formatterType=Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

priority=0 useDefaultLogger=false type=Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

name=Logging Handler />

</exceptionHandlers>

</add>

</exceptionTypes>

</add>

</exceptionPolicies>

</exceptionHandling>


I read that there is a typical permission issue that ASP.Net worker process account may not have permission to create Event Source, but can write into an existing event source. Another suggestion I’ve read is to run Visual Studio as an Administrator (right click, Run as Administrator). What I did to make it work was run as an Administrator and then use the “EventLog.CreateEventSource(source, log);” command to create the Event Source. After that it worked fine on my Vista Machine.


You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.