After a new Vista install, you’ll find there are numerous clean-up tasks that must sometimes (or always) be performed in its wake. Two weeks later, I’ve gotten far enough past major post-install clean-up issues that you’ll find documented in other recent blog posts and articles here to dig into my Event Viewer logs to see what else needs cleaning up. So far, I’ve found and fixed two common sources of Error events in the Application log: WMI, aka Windows Management Instrumentation, and Windows Search.
Error 0x80041003: WMI Event Filter Cannot Be Reactivated
This error occurs after installation of Vista SP1 and is announced with the fairly cryptic error message information shown in the following screen shot. This is actually not a big problem and can be left alone, but the fix is also reasonably simple as long as you log in as administrator to perform the fix, or make sure to run cmd.exe as administrator to perform the command sequence I’m about to provide.
You must rebuild the WMI log files to clear this error on your PC.
1. Open a command window with elevated privileges or from an administrator login (to do this in another account with admin privileges, click Start, All Programs, Accessories, then right-click the Command Prompt icon and select “Run as administrator” from the resulting pop-up menu).
2. type net stop winmgmt. This stops the WMI process, but lasts for only 5 minutes before it restarts, so hurry on up and complete the next command quickly as well, then reboot right after that.
3. type del %windir%\System32\wbem\Repository\*.*, then confirm that deletion when prompted.
4. Reboot your PC and let it idle for a least 5 minutes (long enough for WMI to rebuild itself and restart with a clean slate)
5. Reboot again, and error and warning messages in the Application log will cease.
Windows Search Error 0x80041201
This appears as Event 3036, and indicates a content source with a URL that starts with “<csc://… or <mapi://… cannot be accessed“. Turns out that if you leave the default to index Offline files alone in your Control Panel Indexing Options settings, this error will be produced if you have no offline files set up on your machine. In that case simply modify the settings to exclude Offline files and the error message will cease and desist. This also occurs if you have previously maintained, then broken, a link to a SharePoint server, but I couldn’t find a quick fix for this other cause (further research on this error code with SharePoint looks promising, though, for those who suffer from this affliction).
When the URL begins with <csc://… it’s very likely default search for non-existent Offline files is the cause.
Outlook Crawl Scope Error 0x8001010D
If you visit Microsof Help and Support and search on “Outlook error 0x8001010D” you’ll quickly learn two things: first, that this error has been widely and aggressively reported since March, 2008; and second; that it’s a bit of a misnomer in that while the error indicates some problem in indexing Outlook files (or in accessing the index that gets built as a result), there really is no problem with Outlook or the Windows Search indexing tool, and you can still use search within Outlook to access your e-mails.
Although this looks like a real problem, in most cases Windows Search is finding and indexing Outlook e-mail just fine.
Though you will find some “interesting fixes” posted on the Web, that usually entail editing the Registry and deleting certain key indexing files, these don’t appear to resolve the problem, and make the error messages go away. I followed these recipes without success, and even uninstalled Windows Search 4.0, then reinstalled that update (KB940157) without affecting the presence or absence of these error messages. In the apparent absence of a workable or conclusive fix, I’ve resolved to ignore these errors in Event Viewer until a conclusive fix emerges.
