Stopping a counter before copying the log file?

May 17, 2010 at 3:20 PM


Just a general, best practice question. 

Is it necessary to "stop" a performance monitor counter before copying the ".blg" file to a local machine for analysis with PAL? Is it bad practice to copy a ".blg" file that is currently logging data?





May 18, 2010 at 3:47 AM

The perfmon log service has a hard lock on the file, so my guess it stop it first. With that said, if it works, then it work. I've always stopped them first and never tried this.

My guess is that you tried this... did something bad happen?

May 18, 2010 at 7:33 AM

As far as I know (did some experiments). If you try to analyse the .blg that is currently in use by Perfmon the analysis won't be full (because perfmon has some buffer to write to). Moreover sometimes the analysis interval is taken improperly and may cause a report being incostintent.

My personal advise would be to stop the perfmon log first...

May 18, 2010 at 6:34 PM

Thanks for the tips folks.


BTW, I always stop the counter before using PAL to analyze it, however, I often run perfmon to open a log file that is currently running to make sure I get valid data (see my post from yesterday in regards to corrupted .blg files).


Thanks again!!!!!!

Jun 3, 2010 at 6:00 PM

Just to let you folks know, I have, on multiple occasions, had success copying the live ".blg" file (without stopping the counter first) and opened it up with PAL and got a good report. The thing is, if I can prove this never hurts the .blg file (to copy it live) it would be a big help. There are times when I need to report on how a system is doing during app testing (but  I need to keep the counter running) and PAL is tremendously helpful in reporting this.

I am going to do a bunch of testing on this and post back to let everyone know my results.....