Logging causes Form contructor to hang

Topics: Enterprise Library Core, General discussion, Logging Application Block
Nov 16, 2009 at 9:06 PM

I have an interesting problem.  It seems that having code related to the EL 4.1 logging block in my form causes the form's constructor to stall for several seconds.  I've proved this to myself by creating a new, default form and having it be created inside the typical Application.Run() call in my main function block.  When my form's constructor has code in it related to logging, it will stall at the line where the constructor is called (not in the constructor).  When I comment out the logging code, it all runs just as you would expect it to.

This all came about in the last several days.  I have an application that has quite a bit of logging in it, and it had been working just fine until recently.  Then this morning, I noticed that several of the log entries that I had been expecting we not showing up in the log.  After trying to track that down, I eventually scrolled down through all the application events in the event view and had the event view inform me that my event log was corrupt.  After the alert, no events were showing in the viewer.  So I cleared all of the events out of the log.  My application was then able to produce all the log entries I was expecting, but now the application takes a while to start its form.

Has anyone else seen anything like this, and were you able to fix it?  If so, how?  I've tried uninstalling and reinstalling EL 4.1 thinking that along with the corrupted event log, something else might have gotten corrupted, but that didn't seem to fix anything.

All of my code is C# for .NET 3.5.

Thanks in advance for any adivse you can provide.

Nov 17, 2009 at 2:32 AM

I haven't encountered this scenario before.  Did you re-install instrumentation as well?

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com

Nov 17, 2009 at 2:09 PM

Yes.  I've reinstalled the instrumentation.

On a side note, if I make a change to the EL 4.1 source code that is distributed with the libraries, and then rebuild the source code, do I just have to re-run the instrumentation installer to get my modified libraries to install?  Or do I have to go through a more painful process?  I ask, because I read elsewhere that if you remove the compile flags for building in the permormance counters, the code will run faster.

I doubt very many people have seen this problem.  I suspect what is happening is that somewhere on the stack, as my form gets created and it creates the static Logger object, or the first LogEntry object, there is some code in the library for opening the system event log.  I'm guessing that the corruption of my event log is still there somehow and that it is causing some kind of problem and delay during the library's attempt to open a handle to the event log.  I've already tried completely deleting the file that the event log stores the events in, but that didn't seem to have any effect (note that a "cleared" event log file is still 64K in size).

What I'm hoping this doesn't boil down to is that I have to wipe and reinstall the machine to get the problem to go away.  I can handle having to do that for development purposes, but for my final deployment of this code, that may not be acceptable.  I'd like to find a better way to resolve this issue.

Nov 25, 2009 at 7:02 PM

I had a similiar problem today.  I was able to reproduce it using this super simple example:

http://elegantcode.com/2009/01/20/enterprise-library-logging-101/

Until I cleared all events, the Enterprise Logging didn't show up.  Once I cleared all events, they would appear after a run of the application.

Nov 27, 2009 at 3:12 AM

Unfortunately, I'm still unable to repro this scenario. 

dshiplet, you can just re-run the instrumentation but before you do, make sure the modified libraries is in the correct path.  Those should be in the bin folder, just like the structure of the files in the entlib installation folder.

 

Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com