Can you shed more light on these Windows XP anamolies?

My WinXP is often crashing so I resorted to filemon debugging (among
others) to see what files were being accessed & what they were doing.

Is it normal for filemon to report thousands upon thousands of this?
c:\windows\system32\wbem\logs\wmiprov.log

Inside, is it normal to find the same error thousands of times?

c:\windows\system32\wbem\logs\wmiprov.log
------------
(Sun Dec 18 10:07:19 2005.335892) : The instance name passed was not
recognized as valid(Sun Dec 18 10:07:19 2005.335892) :
(Sun Dec 18 10:07:19 2005.335973) : WDM call returned error: 4201

c:\windows\system32\wbem\logs\wbemess.log
------------
(Sun Dec 18 10:07:19 2005.987289) : NT Event Log Consumer: could not
retrieve sid, 0x80041002

In summary, do you have insight into why filemon report thousands upon
thousands of access to wmiprov.log and why these logs contain these errors?

Notes: Please prune cross list as needed as I didn't know where to ask.

> In summary, do you have insight into why filemon report thousands upon
> thousands of access to wmiprov.log and why these logs contain these errors?

If it helps us get to the bottom of this, here is the filemon log showing
constant and repetitive access to wmiprov.log yet not showing SUCCESS even
though the content of the logs seem to show constant failure (as noted).

5 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Length: 9225

6 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Length: 9225

7 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Offset: 9225 Length: 78

8 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS

9 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS

10 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CREATE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Options: OpenIf Access:
All

11 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9303

12 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9303

13 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Offset: 9303 Length: 89

14 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS

15 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS

16 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CREATE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Options: OpenIf Access:
All
17 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9392

18 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9392

19 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Offset: 9392 Length: 39

20 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS

21 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS

Disable WMI logging.

wmiprov.log
Mostly necessary for WMI script developers or system administrators when
searching for the cause of errors. For the average user these logs make no
sense and can just as well be disabled to avoid unnecessary I/O and
defragmentation.
C:\WINDOWS\system32\wbem\Logs

Administrative Tools | Computer Management | Click on [+] Services and
Applications | Right click on WMI Control | Click on properties | Click on
Logging. Change the logging level to Disabled.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In newswal843sf29j$.32jh2rjt8dmr.dlg@40tude.net,
Tom Quan <tquan@telleride.com> hunted and pecked:
>> In summary, do you have insight into why filemon report thousands upon
>> thousands of access to wmiprov.log and why these logs contain these
>> errors?
>
> If it helps us get to the bottom of this, here is the filemon log showing
> constant and repetitive access to wmiprov.log yet not showing SUCCESS even
> though the content of the logs seem to show constant failure (as noted).
>
> 5 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Length: 9225
>
> 6 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Length: 9225
>
> 7 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
> C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS Offset: 9225 Length: 78
>
> 8 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
> C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS
>
> 9 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
> C:\WINDOWS\system32\wbem\Logs\wmiprov.log SUCCESS
>
> 10 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CREATE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Options: OpenIf Access:
> All
>
> 11 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9303
>
> 12 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9303
>
> 13 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Offset: 9303 Length: 89
>
> 14 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS
>
> 15 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS
>
> 16 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CREATE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Options: OpenIf Access:
> All
> 17 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9392
>
> 18 10:20:08 AM wmiprvse.exe:1660 FASTIO_QUERY_STANDARD_INFO
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Length: 9392
>
> 19 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_WRITE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS Offset: 9392 Length: 39
>
> 20 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLEANUP
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS
>
> 21 10:20:08 AM wmiprvse.exe:1660 IRP_MJ_CLOSE
> C:\WINDOWS\system32\WBEM\Logs\wmiprov.log SUCCESS

On Sun, 18 Dec 2005 11:50:59 -0700, Wesley Vogel wrote:
>> Is it normal for wbem logs to constantly report repeated errors?
> Disable WMI logging.
> Administrative Tools | Computer Management | Click on [+] Services and
> Applications | Right click on WMI Control | Click on properties | Click on
> Logging. Change the logging level to Disabled.

Hi Wesley,

Are you saying these errors in the wmi log files are meaningless?

I'm confused. If I disable the Windows Management Instrumentation (WMI)
logs, will that make the errors go away or just not report them?

TQ

>> Is it normal for wbem logs to constantly report repeated errors?
> Are you saying these errors in the wmi log files are meaningless?

I looked up what happens if I kill this service and I'm even more confused.

While the filemon.exe log does not show the failure which exists inside the
wmiprov.log and wbemess.log files, filemon does implicate the process which
is constantly being called as "wmiprvse.exe" (whatever that is).

Looking this up, I find wmiprvse.exe is a Windowx XP SP2 Windows Management
Instrumentation (WMI) process which is not supposed to be killed according
to http://www.auditmypc.com/process/wmiprvse.asp

Process Library & Answers that Work imply this service essential to XP:
http://www.processlibrary.com/directory/files/wmiprvse
http://www.answersthatwork.com/Taskl...tasklist_w.htm

It may be useful to note my anti-virus software has been running and is up
to date even though this intermittent daily Windows XP lockup has been
occurring for weeks.

Are you sure that killing the wmiprvse service will solve the problem
intimated by the constant errors in the WBEM log files?

I did not post anything about the Windows Management Instrumentation
service. Leave it set to Automatic in services.msc.

I suggested disabling WMI logging. I have it disabled. My wmiprov.log is
0KB.

The following has nothing to do with the Windows Management Instrumentation
service.

All it does is disable WMI logging so that nothing is added to the
wmiprov.log.

Administrative Tools | Computer Management | Click on [+] Services and
Applications | Right click on WMI Control | Click on properties | Click on
Logging. Change the logging level to Disabled.

Apparently you have WMI logging set to verbose. That means that it shows
not only errors, but SUCCESS as well.

[[Verbose logging can negatively impact system performance, so select
Verbose only when you need more extensive information about the events
leading to errors. ]]

To turn WMI error logging on or off
http://www.microsoft.com/resources/d...ng_on_off.mspx

You do what ever you want.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:loo5byk23neu$.1xdiea6nkwjka.dlg@40tude.net,
Tom Quan <tquan@telleride.com> hunted and pecked:
>>> Is it normal for wbem logs to constantly report repeated errors?
>> Are you saying these errors in the wmi log files are meaningless?
>
> I looked up what happens if I kill this service and I'm even more
> confused.
>
> While the filemon.exe log does not show the failure which exists inside
> the wmiprov.log and wbemess.log files, filemon does implicate the process
> which is constantly being called as "wmiprvse.exe" (whatever that is).
>
> Looking this up, I find wmiprvse.exe is a Windowx XP SP2 Windows
> Management Instrumentation (WMI) process which is not supposed to be
> killed according to http://www.auditmypc.com/process/wmiprvse.asp
>
> Process Library & Answers that Work imply this service essential to XP:
> http://www.processlibrary.com/directory/files/wmiprvse
> http://www.answersthatwork.com/Taskl...tasklist_w.htm
>
> It may be useful to note my anti-virus software has been running and is up
> to date even though this intermittent daily Windows XP lockup has been
> occurring for weeks.
>
> Are you sure that killing the wmiprvse service will solve the problem
> intimated by the constant errors in the WBEM log files?

On Sun, 18 Dec 2005 12:50:28 -0700, Wesley Vogel wrote:
> I did not post anything about the Windows Management Instrumentation
> service. Leave it set to Automatic in services.msc.
> I suggested disabling WMI logging.

Oh. OK. I am less confused now. Thank you for your patience. I've never
encountered this thing called windows management instrumentation before so
I'm starting with a knowledge base of zero (other than what I glean from
google and learn from you from your kind efforts).

I right clicked on the WinXP SP2 "My Computer", pressed "Manage", "Services
and Applications", and right clicked on "WMI Control", "Properties" which
then said "Connecting to Windows Management" and brought up a 5-tab "WMI
Control Properties" form.

Pressing on the "Logging" tab for the first time, I see it was actually set
to "Errors only". As a test, I set it next to "Verbose" and noticed LOTS of
new logs showed up in C:\windows\system32\wbem\Logs, e.g., Framework.log,
provss.log, wbemcore.log, WinMgmt.log, wbemprox.log, etc.

Looking in the various logs, I find strange reports such as:
CWbemProviderGlue::Init 12/18/2005 11:14:14.228 thread:3982
[d:\xpsprtm\admin\wmi\wbem\sdk\framedyn\wbemglue.cp p.199]
Failed to open thread token: (1008) 12/18/2005 11:14:14.228 thread:3984
But my D: drive is almost wholly empty (except for something hidden called
"System Volume Information" and "MSOCache".

Do these tell us anything?

> Do these CWbemProviderGlue init failures tell us anything?

Doing the diligent search on CwbemProviderGlue init calls, I see whatever
they are, Microsoft feels they are obsolete according to
http://msdn.microsoft.com/library/de...oviderglue.asp
which says

"CWbemProviderGlue ties the Component Object Model (COM) interfaces of the
Windows Management Instrumentation (WMI) API to the classes derived from
the Provider class, and supplies methods for providers to use to query each
other."

May I ask what a "PROVIDER" is (or am I barking up the wrong tree)?

TQ

Tom,

Yes. For the average user these logs make no sense and can just as well be
disabled.

To discover more about WMI...

There is a super secret hidden very little known item on your machine. It
is called Help and Support. Accessed from the Start Menu.

Type or paste in the Search box and click the arrow.

WMI
WMI overview

WMI Control HELP
Start | Run | Paste this in the box and click OK...

hh newfeat1.chm::/wmi_s0.htm

How To Use Computer Management in Windows XP
http://support.microsoft.com/default...b;en-us;308423

wmi logging
http://search.msdn.microsoft.com/sea...=4&s=1 &swc=4

(Note the table of contents pane on the left)
Windows Management Instrumentation
http://msdn.microsoft.com/library/de...start_page.asp

Support articles for Windows Management Instrumentation
http://search.msdn.microsoft.com/sea...tion&s=1&swc=4

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In news:xie5bbvop7tf.8i3q7v9n2tl5$.dlg@40tude.net,
Tom Quan <tquan@telleride.com> hunted and pecked:
> On Sun, 18 Dec 2005 12:50:28 -0700, Wesley Vogel wrote:
>> I did not post anything about the Windows Management Instrumentation
>> service. Leave it set to Automatic in services.msc.
>> I suggested disabling WMI logging.
>
> Oh. OK. I am less confused now. Thank you for your patience. I've never
> encountered this thing called windows management instrumentation before so
> I'm starting with a knowledge base of zero (other than what I glean from
> google and learn from you from your kind efforts).
>
> I right clicked on the WinXP SP2 "My Computer", pressed "Manage",
> "Services and Applications", and right clicked on "WMI Control",
> "Properties" which then said "Connecting to Windows Management" and
> brought up a 5-tab "WMI Control Properties" form.
>
> Pressing on the "Logging" tab for the first time, I see it was actually
> set to "Errors only". As a test, I set it next to "Verbose" and noticed
> LOTS of new logs showed up in C:\windows\system32\wbem\Logs, e.g.,
> Framework.log, provss.log, wbemcore.log, WinMgmt.log, wbemprox.log, etc.
>
> Looking in the various logs, I find strange reports such as:
> CWbemProviderGlue::Init 12/18/2005 11:14:14.228 thread:3982
> [d:\xpsprtm\admin\wmi\wbem\sdk\framedyn\wbemglue.cp p.199]
> Failed to open thread token: (1008) 12/18/2005 11:14:14.228 thread:3984
> But my D: drive is almost wholly empty (except for something hidden called
> "System Volume Information" and "MSOCache".
>
> Do these tell us anything?

On the programmer's D drive (not yours) the source code for the module reporting the error is that file. WMI will start if something is using it. If nothing is using it then it can be killed. If you kill it and something is using it it will just restart.

--
--------------------------------------------------------------------------------------------------
Goodbye Web Diary
http://margokingston.typepad.com/har....html#comments
=================================================
"Tom Quan" <tquan@telleride.com> wrote in message news:xie5bbvop7tf.8i3q7v9n2tl5$.dlg@40tude.net...
> On Sun, 18 Dec 2005 12:50:28 -0700, Wesley Vogel wrote:
>> I did not post anything about the Windows Management Instrumentation
>> service. Leave it set to Automatic in services.msc.
>> I suggested disabling WMI logging.
>
> Oh. OK. I am less confused now. Thank you for your patience. I've never
> encountered this thing called windows management instrumentation before so
> I'm starting with a knowledge base of zero (other than what I glean from
> google and learn from you from your kind efforts).
>
> I right clicked on the WinXP SP2 "My Computer", pressed "Manage", "Services
> and Applications", and right clicked on "WMI Control", "Properties" which
> then said "Connecting to Windows Management" and brought up a 5-tab "WMI
> Control Properties" form.
>
> Pressing on the "Logging" tab for the first time, I see it was actually set
> to "Errors only". As a test, I set it next to "Verbose" and noticed LOTS of
> new logs showed up in C:\windows\system32\wbem\Logs, e.g., Framework.log,
> provss.log, wbemcore.log, WinMgmt.log, wbemprox.log, etc.
>
> Looking in the various logs, I find strange reports such as:
> CWbemProviderGlue::Init 12/18/2005 11:14:14.228 thread:3982
> [d:\xpsprtm\admin\wmi\wbem\sdk\framedyn\wbemglue.cp p.199]
> Failed to open thread token: (1008) 12/18/2005 11:14:14.228 thread:3984
> But my D: drive is almost wholly empty (except for something hidden called
> "System Volume Information" and "MSOCache".
>
> Do these tell us anything?
>