View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001196 | SpeedFan | Other | public | 2008-07-19 18:56 | 2009-05-11 11:56 |
| Reporter | Picsman | Assigned To | alfredo | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Windows | OS | Windows XP Professional | OS Version | SP3 |
| Product Version | 4.35 beta | ||||
| Summary | 0001196: Very frequent writes to wbemcore.log | ||||
| Description | I recently noted unusual disk activity. Using Sysinternals Filemon, I learned errors were being written to C:\WINDOWS\system32\wbem\Logs\wbemcore.log about every three seconds. I traced this to Svchost.exe, and WMI. When Speedfan is not running, writes to wbemcore.log are infrequent and variable, from once in 10 seconds to once in an hour or more. As the limit to log file size is set to 64k, after a short time with Speedfan running, the logging directory fills up with 64k "overflow" logs. I reloaded 4.34 and the same behavior occurs. | ||||
| Additional Information | When Speedfan is NOT loaded, these errors are written to wbemcore.log: --------------- GetUserDefaultLCID failed, restorting to system verion(Sat Jun 28 08:55:18 2008.6371359). --------------- When Speedfan IS loaded these errors (partial extraction from the log) are written to wbemcore.log: --------------- (Sat Jun 28 21:56:56 2008.42070718) : Error 80041002 occured executing request for CancelProvAsyncCall for sink 07E01628 (Sat Jun 28 21:56:56 2008.42070718) : CAsyncReq_CancelProvAsyncCall call failed (Sat Jun 28 21:56:59 2008.42073718) : CALL ConnectionLogin::NTLMLogin wszNetworkResource = \\.\root\WMI pPreferredLocale = (null) lFlags = 0x0 (Sat Jun 28 21:56:59 2008.42073718) : DCOM connection from NUMBER-ONE\Ron VanAbrahams at authentiction level Privacy, AuthnSvc = 10, AuthzSvc = 0, Capabilities = 0 (Sat Jun 28 21:56:59 2008.42073718) : GetUserDefaultLCID failed, restorting to system verion(Sat Jun 28 21:56:59 2008.42073718) : CALL CWbemNamespace::CreateInstanceEnum long lFlags = 0x10 BSTR Class = msacpi_thermalzonetemperature IEnumWbemClassObject **pEnum = 0x8E70080 (Sat Jun 28 21:56:59 2008.42073718) : CALL CWbemNamespace::CreateInstanceEnumAsync BSTR Class = msacpi_thermalzonetemperature long lFlags = 0x0 IWbemObjectSink pHandler = 0x0 (Sat Jun 28 21:56:59 2008.42073718) : CALL CWbemNamespace::GetObject BSTR ObjectPath = msacpi_thermalzonetemperature long lFlags = 0 IWbemClassObject ** pObj = 0x368FB58 (Sat Jun 28 21:56:59 2008.42073718) : CALL CWbemNamespace::GetObjectAsync BSTR ObjectPath = msacpi_thermalzonetemperature long lFlags = 0 IWbemObjectSink* pHandler = 0x0 (Sat Jun 28 21:56:59 2008.42073718) : Query Engine request: querying dyn provider with <select * from msacpi_thermalzonetemperature> (Sat Jun 28 21:56:59 2008.42073718) : Query Engine actual: querying dyn provider with <select * from MSAcpi_ThermalZoneTemperature> (Sat Jun 28 21:56:59 2008.42073718) : CALL CWbemNamespace::GetObject BSTR ObjectPath = MSAcpi_ThermalZoneTemperature long lFlags = 0 IWbemClassObject ** pObj = 0x297F918 (Sat Jun 28 21:56:59 2008.42073718) : Error 80041002 occured executing request for CancelProvAsyncCall for sink 07E01628 (Sat Jun 28 21:56:59 2008.42073718) : CAsyncReq_CancelProvAsyncCall call failed --------------- | ||||
| Tags | No tags attached. | ||||
| Motherboard Model | |||||
| Video Card Model | NVIDIA GeForce 8600GTS | ||||
|
|
I don't know what should be logged in that file, but MS states that "The Wbemcore.log file contains trace messages generated by the WMI service". I don't see any real issue with it. May be that there is some options somewhere to lower the logging activity, but I don't know about it. |
|
|
When Speedfan is running, wbemcore.log is updated every three seconds. As the log size is (currently) limited to 64k, when the current log file limit is reached, another log file is started. After a day or so running, the folder has a large number of 64k files. When Speedfan is not running, wbemcore.log never reaches 64k even after days of system uptime. The conclusion is Speedfan is using up some CPU cycles (and disk space) writing "errors" to wbemcore.log WMI logging can be disabled or set to write only errors or set to "verbose" level. Run "%windir%\system32\wmimgmt.msc" to see how this works for yourself. I have disabled log writes but that is more a workaround than a proper fix. SF's constant writing to wbemcore.log suggests something, somewhere has not been optimized. |
|
|
This behaviour must be system specific. I only have two error messages in that log and they are more than a month old (using 4.35 beta 17). |
|
|
Of course the errors (partial extraction from the log) might be system specific: ------ (Fri Jul 25 10:51:51 2008.13435765) : Query Engine request: querying dyn provider with <select * from msacpi_thermalzonetemperature> (Fri Jul 25 10:51:51 2008.13435765) : Query Engine actual: querying dyn provider with <select * from MSAcpi_ThermalZoneTemperature> (Fri Jul 25 10:51:51 2008.13435781) : CALL CWbemNamespace::GetObject BSTR ObjectPath = MSAcpi_ThermalZoneTemperature long lFlags = 0 IWbemClassObject ** pObj = 0x399F918 (Fri Jul 25 10:51:51 2008.13435781) : Error 80041002 occured executing request for CancelProvAsyncCall for sink 0821B4E8 (Fri Jul 25 10:51:51 2008.13435781) : CAsyncReq_CancelProvAsyncCall call failed ------ There is no doubt, however, they are somehow related to Speedfan as they do not occur when Speedfan is not running. With Speedfan not running, a few entries (no "errors") are written to the file initially but the 64k file limit of the log file is not reached even after the system has run for two weeks. You might check your system's WMI to be sure logging is enabled. Also, I believe the system clears the log folder upon reboot. This system runs without a reboot a few weeks at a time so the detritus that accumulates in the folder is quite noticeable. (I have now disabled logging which is the current workaround for me.) A few Google searches and cruising around in the MSKB provides some clues but I am no programmer. Based upon one clue I reinstalled .NET Framework 1.1 but that changed nothing. I can upload ZIPped log files if anyone wants to see if they can learn anything from them. It's gobbledygook to me! This system: ECS 945GCT/M/1333; E6850 3Ghz; 4gig RAM; Nvidai 8600GTS. |
|
|
I was Googling for this and came upon this bug; I too am using Speedfan on my Windows 2003 Server. GetUserDefaultLCID failed, restorting to system verion(Thu Dec 04 00:11:35 2008.-1089096828) is the exact message... Exactly copy and pasted, with those two amusing spelling errors. Those are the only errors I get in my wbemcore.log anyway. |
|
|
Microsoft says to ignore the error, However, speedfan is continously connecting to WMI which is why the log file continues to expand. |
|
|
http://www.microsoft.com/technet/scriptcenter/topics/help/wmi.mspx/ claims it is error 0x80041002 ( |
|
|
Only occurs when only detecting sensors over the ISAbus here... hmm |
|
|
There's some help here: http://forum.sysinternals.com/forum_posts.asp?TID=18400 http://forum.sysinternals.com/forum_posts.asp?TID=18032 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-07-19 18:56 | Picsman | New Issue | |
| 2008-07-19 18:56 | Picsman | Status | new => assigned |
| 2008-07-19 18:56 | Picsman | Assigned To | => alfredo |
| 2008-07-19 18:56 | Picsman | Video Card Model | => NVIDIA GeForce 8600GTS |
| 2008-07-22 19:36 | alfredo | Note Added: 0003849 | |
| 2008-07-22 19:36 | alfredo | Status | assigned => acknowledged |
| 2008-07-25 04:58 | Picsman | Note Added: 0003854 | |
| 2008-07-25 06:43 | norman02us | Note Added: 0003855 | |
| 2008-07-25 06:44 | norman02us | Note Edited: 0003855 | |
| 2008-07-25 06:46 | norman02us | Note Edited: 0003855 | |
| 2008-07-25 20:57 | Picsman | Note Added: 0003856 | |
| 2008-12-04 01:25 | lozzd | Note Added: 0004322 | |
| 2009-03-13 21:39 | SQUALL_LEONHART69R | Note Added: 0004655 | |
| 2009-03-15 00:27 | danbendan | Note Added: 0004660 | |
| 2009-03-17 17:30 | SQUALL_LEONHART69R | Note Added: 0004663 | |
| 2009-05-11 11:56 | MRCS | Note Added: 0004771 |
