Posted On: Friday, 20 October 2006 by Rajiv Popat

There is one thing good about windows. What can be done, or sometimes... what happens ("seemingly automatically"), can be undone (and explained). Last week one of the 3 power-horse machine that I work on mysteriously slowed down. I'm a multi-tasker who has three instances of Visual Studio.NET open with at-least 10 other applications running simultaneously at any given point of time.

So, initially, this slow-down seemed "normal" and the tendency was to monitor the RAM usage. But Task Manager and Process Explorer did not reveal anything peculiar. After some more investigation and using FileMon it was evident that the bottle-neck was actually the HardDisk which kept constantly thrashing. The Instant reaction was to Defrag the disk which pointed out the real problem. The Defragmenter completed "successfully" with an error :)

The error (included in the Defragmenter report) was that it wasn't able to move a particular file "C:\WINNT\system32\LogFiles\WMI\Trace.log" (No, I'm not using the primitive Windows NT - that's just how I like to name my Windows folder :))

But the real shock came when I tried to get to the file using explorer and see what's going on. Here's what I mean:

Now, I have three problems with this picture here:

  1. That is a 80 gig disk that has cost Money to buy. If there's going to be a 2.5 gig file somewhere on that disk, I'd better know about it.
  2. What-ever wrote that darn thing on this disk, wasted quite a bit of processor and RAM writing it.
  3. I couldn't delete it. Apparently, some process seemed to be using it and locking it!

A little more Googling on Large trace files revealed that there's some utility out there let's you disable trace logging and then allows you to delete these files. Back, in my MCSE days and days of NT 4.0 people like me, who were both into IT and Development, used to talk a lot about Resource Kits and Option packs and things like that. But not a lot of people seem to be talking about Resource Kits these days.

As it turns out, there's a Resource Kit for Windows 2003 available here. And in that long list of tools and utilities is a tool called TraceLog.exe. A quick "TraceLog.exe -l" told me what was occupying the file and writing away to it. A quick "TraceLog.exe -stop" allowed me to stop the NT Kernel Logger from Trace Logging.

Once trace logging stopped I was able to Delete the Log file off my disk and re-run the defragmenter successfully without any errors.

What really bothered me was not knowing what had Enabled Trace logging and the creation of a 2.5 Gig file on my disk. With the file now wiped off and the problem solved I decided to read a little more and do some investigation into the possible causes of this problem.

Discussion threads like this one revealed that the real problem was BootVis

BootVis is a tool which is supposed to provide faster Boots with Windows XP. I Had played with it a few days ago and realized that it does NOT work very well with Windows 2003.

BootVis had started Trace Logging. And in all probabilities, the NT Kernel Logger had diligently continued logging since then (even after BootVis was uninstalled) just because no-one told it that it was ok to stop logging now.

Long story short, I have a couple of gigs won over from a Zombie file that I wasn't going to need / read anyways and the Defragmented disk seems much faster than yesterday; and that makes me a happy man for today.


Comment Section






Comments are closed.