Hi,
The instance name passed was not recognized as valid by a WMI data provider.
I think that tracelog took note of the running trace session(s) before shutting it/them down and didn't find the "owner(s)" of the session(s) listed among the registered GUIDs. In other words, and I hope that someone who knows more than I do will correct me if I'm wrong, whatever was causing the trace log to accumulate was not registered with Windows Management Instrumentation to make use of tracelog.exe.
After a reboot, or other operations, has the logging resumed, or has it stayed dead? If it resumes you might try "tracelog -l" and "tracelog -enumguid" to gather some information about what's going on. (You can issue "tracelog -enumguid>enumguid.txt" and "tracelog-l>l.txt" in order to collect the output in text files. They should be fairly small, particularly the "l" output. You might try those commands anyway, just to see if they report anything. That could at least point you to the intermediary in the process, but very possibly not the base cause. Someone might have to go over that system with a fine-toothed comb to find that. The cause could even be malicious code, but is more likely an errant install process that didn't completely finish / left an active registry entry running a trace or whatnot. A malfunctioning driver may be able to spark something like this. The few cases of really bad drivers I've run across in WinXP didn't bear investigation because they completely whacked the systems on which they were running. Also, I seem to recall hearing something about the bootvis utility (for boot time optimization) causing this sort of behavior under certain circumstances, but I can't seem to find any info on that right now.
You might look at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI\GlobalLogger in the registry to see what the REG_DWORD value named "Start" (in the right-hand pane of regedit) is set to. Normally should be 0x00000000 (0). I think the "tracelog -remove" command should reset the ordinary operating system flags that might cause logging to be enabled. An expert might be able to examine the contents of the log and tell just what was causing it to run, but the contents of a log don't HAVE to have anything to do with whatever caused the data to be gathered if the cause is a registry error or malware or some other behavior on the part of an ill-natured fairy. (Excuse me for wandering into Gilbert and Sullivan mode for a moment there.)
My speculations about the possible causes are just that, speculations. With any luck this little glitch will just leave you alone now. If it doesn't, I'd strongly suggest tracking it down.
- Collin
PS: If NogginBoink can tell us about the contents of the MSKB article (Q321275) mentioned earlier, I'd appreciate it. When I search for it, I get a notification that the danged article is not available.:|