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:
- 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.
- What-ever wrote that darn thing on this disk, wasted quite a bit of processor and RAM writing it.
- 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.
good thing for sure!Thanx for this text....Same happened to me
just my trace.log file was 30GB :SSSSS...made by BootVis i think,
an application by microsoft...great :S
...bye
I wouldn’t really hold BootVis Responsible to the TraceFile Generation – if you think about it - BootVis had just instructed the Karnel Logger to start logging. And then, the NT Kernel Logger had diligently continued logging since then just because no-one told it that it was ok to stop logging :)
Given the fact that all of us run thousands of tools and a lot of these tools have some dependency on each other, things like these just happen – what I really like about MS tools and Operating systems however, is that it’s usually very easy to look under the hood and figure out what was done, what did it and then undo it :)
Very good advice and solution, it works well, thanks a lot.
Absolutly, BootVis is guilty, ;)
Your solution works to delete the file, but does not stop it from reoccurring next boot. Any ideas?
http://msdn2.microsoft.com/en-us/library/ms797661.aspx - provides more details.
Comments are closed.