Using various methods I was able to back track the elusive event 10 to the source.
Here is what you see when you open the event viewer on a Windows Vista system.
There are A LOT of post all over the web on this event.
One article that led me to my conclusion, started me here in this KB Article.
When you scroll down the page in this KB Article you see a script to delete the offending event provider.
I wanted to go deeper. So looking at the script I discovered the WMI namespace root\subscription which contains the classes needed to get the information.
Using several tools I was able to back track to the source of the problem.
Scriptomatic 2.0, WMI Tools (WMI CIM Studio), wbemtest.exe, My Highly modified version of the Scriptomatic which list all classes not just the dynamic ones., and a new tool I built just for this search based on the classes, and you can’t forget the most valuable tool, the internet search. (The classes used are not dynamic classes )
First of all we need to figure out where the event is, so we turn to the root\subscription namespace and the class, _EventFilter and we get back this.
This tells us that the filter name is BVTFilter . Which still does not answer the question. Nothing really shows up any more on that filter name which was useful.
Back to the internet .
Which led me to this page Receiving Events at All Times on MSDN site and another Class to search. Then to here __FilterToConsumerBinding class Also in the root\subscription namespace .When run we get back this.
Now this narrows the problem down to another class, CommandLineEventConsumer, also in the root\subscription namespace. Back to MSDN for an Explanation.
From what I get out of this is when an event matches the event filter, then it triggers the CommandLineEventConsumer event. In this case it appears that when something is running the processor at greater than 99% utilization then the CommandLineEventConsumer will be triggered.
Next we look at exactly what it is supposed to do by getting the instance of CommandLineEventConsumer WHERE NAME = BVTConsumer.
The CommandLineEventConsumer appears to be used to start actions that can be run from the command line, such as here, running a script.
We Get this.
This Is what is supposed to run when the BVTFilter event is triggered.
Traveling back thru this process we find out that when something pushes the processor over 99 % utilization then it triggers the script cscript KernCap.vbs which is supposed to be in the C:\\tools\\kernrate folder. (Neither the script or the location exist on my system)
Back to the original error, it is a WMI error 0x80041003 which when looked up at MSDN once again, we find that this error is, WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) Current user does not have permission to perform the action.
Now why is access denied, for one thing when looking up the CreatorSID It is either bogus or no longer used, Either way it has no permissions on my system to do anything and doesn’t exist on my system either. Since WMI does not recognize the security ID (SID) provided then it denies Access to do anything.
For more information on WMI Security Start here: Access to WMI Namespaces
You could use the script listed in the link to remove the bogus provider and stop the logging of the event, but that still does not solve the problem. When something is running the processor to over 99% utilization.
To solve the error problem a new CommandLineEventConsumer would need to be built to record what is going on or handle the event in some way. Which would still, not solve the underlying problem of the processor running over 99 % utilization. But at least you could look at a log of the problem to see what was happening.
For now the error basically tells us that the event did happen, but there is no real way to log what was running that caused the high CPU utilization.
I hope this Finally answers the question once and for all.
If anyone believes my assumptions are incorrect please leave a comment so I can fix the article.