Please help with [STAThread], WMI and access denied

[Guest]

Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second local
connect:Access denied!], but got no answer until now. In the meantime, I
found, that I cannot understand some thread-settings for the Main() function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Willy Denoyette [MVP]]

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.

 

[Manfred Braun]

Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too. I am
working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results ....
I used two production machines, just to be sure, that not some fumbling ;-)
on my admin machine have caused that. Accidentally, on the next machine, I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with DCOMCNFG, the
behavior return to that, what I originally described and this is on all my
W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.

Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second local
connect:Access denied!], but got no answer until now. In the meantime, I
found, that I cannot understand some thread-settings for the Main() function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Manfred Braun]

Hi All,

interestingly, in one of my latest tests, I found privilege failure audit in
the eventlog, claming the denied access to the right SeSecurityPrivilege
......

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that after
a first connect, a second one fails and does not explain what this has to do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred

Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too. I am
working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results ....
I used two production machines, just to be sure, that not some fumbling ;-)
on my admin machine have caused that. Accidentally, on the next machine, I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with DCOMCNFG, the
behavior return to that, what I originally described and this is on all my
W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.

Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second local
connect:Access denied!], but got no answer until now. In the meantime, I
found, that I cannot understand some thread-settings for the Main() function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Ivan Brugiolo [MSFT]]

This has all to do with Identity Tracking and STATIC/DYNAMIC cloaking.
If you are writing C++ code, all these settings are exposed and obvious.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Hi All,

interestingly, in one of my latest tests, I found privilege failure audit in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that after
a first connect, a second one fails and does not explain what this has to do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred

Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too. I am
working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results .....
I used two production machines, just to be sure, that not some fumbling ;-)
on my admin machine have caused that. Accidentally, on the next machine, I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with DCOMCNFG, the
behavior return to that, what I originally described and this is on all my
W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the

meantime,

I

found, that I cannot understand some thread-settings for the Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Willy Denoyette [MVP]]

Manfred,

WMI provider COM objects are "free" threaded, that means they need to run in
a MTA thread.
When your main thread is initialized for STA, the Management classes check
the current apartment for MTA compatibility, and will create a new thread
and enter the MTA to create the COM objects, COM will marshal the interfaces
between the STA thread (running your managed code) and the MTA thread
running the native COM code.
But, your main thread (STA) has enabled the SeSecurityPrivilege for the main
thread, but this privilege is not propagated to the MTA thread, resulting in
an access denied exception.
Therefore I suggest you allways run your code on an MTA thread, the net
benifits are
- no marshaling overhead
- no difficult to track security issues.
- no issues due to eventsink marshalin between MTA and STA threads.

Willy.

Hi All,

interestingly, in one of my latest tests, I found privilege failure audit in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that after
a first connect, a second one fails and does not explain what this has to do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred

Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too. I am
working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results .....
I used two production machines, just to be sure, that not some fumbling ;-)
on my admin machine have caused that. Accidentally, on the next machine, I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with DCOMCNFG, the
behavior return to that, what I originally described and this is on all my
W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the

meantime,

I

found, that I cannot understand some thread-settings for the Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get "access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how possibly can
explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Manfred Braun]

Hello Willy,

thanks a lot, I had not understand this completely, and so I tried to use
the [STAThread], because my code, using a [MTAThread] fails to re-connect.
Using ManagementEventWatcher.Start(), followed by .Stop() and another
..Start() failes also with access denied using the [MTAThread] attribute.

As a test, I opened a direct connection to WMI via the
ManagementScope.Connect(), left this connection open, do a .Start(),
followed by a .Stop() and another .Start() and this works! So I have to
assume, the the ConnectionOptions.EnablePrivileges is not passed to my
second ManagementEventWatcher.Start() code. This now looks like a bug for
me. Because I really want to connect to a huge number of computers with a
service, I would not use the Scope.Connect(), because I assume, it would
need much more resources.

Do you, or maybe someone else, have a good hint to handle this situation? I
am lerning C# and the framework, but I cannot code this in C++.

Thanks so far and
best regards,
Manfred

Manfred,

WMI provider COM objects are "free" threaded, that means they need to run in
a MTA thread.
When your main thread is initialized for STA, the Management classes check
the current apartment for MTA compatibility, and will create a new thread
and enter the MTA to create the COM objects, COM will marshal the interfaces
between the STA thread (running your managed code) and the MTA thread
running the native COM code.
But, your main thread (STA) has enabled the SeSecurityPrivilege for the main
thread, but this privilege is not propagated to the MTA thread, resulting in
an access denied exception.
Therefore I suggest you allways run your code on an MTA thread, the net
benifits are
- no marshaling overhead
- no difficult to track security issues.
- no issues due to eventsink marshalin between MTA and STA threads.

Willy.

Hi All,

interestingly, in one of my latest tests, I found privilege failure

audit

in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that after
a first connect, a second one fails and does not explain what this has

to

do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred

Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too. I am
working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results ....
I used two production machines, just to be sure, that not some

fumbling
;-)

on my admin machine have caused that. Accidentally, on the next

machine,

I

all

my

W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the

meantime,

I
found, that I cannot understand some thread-settings for the Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get
"access
denied error", if I use a ManagementEventWatcher to connect to the local
machine to receive events. Is there anybody out there, how

possibly
can

explain why this happens?? If I remove this attribute or use [MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where

targetinstance
isa

'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Andy Cheung [MSFT]]

This is a known bug in System.Management.dll in .NET Framework v1.0. The bug
that prevents WMI privileges from propagating from managed code running on
STAThread to WMI core. Applying [MTAThread] to the calling thread appears to
be a partial workaround to this problem as Access Denied would still be
returned on the second time of event subscription. This problem should be
fixed in .NET Framework v1.1. Have you tried running your application with
v1.1?

--
Andy Cheung
Microsoft WMI Test Engineer
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Hello Willy,

thanks a lot, I had not understand this completely, and so I tried to use
the [STAThread], because my code, using a [MTAThread] fails to re-connect.
Using ManagementEventWatcher.Start(), followed by .Stop() and another
.Start() failes also with access denied using the [MTAThread] attribute.

As a test, I opened a direct connection to WMI via the
ManagementScope.Connect(), left this connection open, do a .Start(),
followed by a .Stop() and another .Start() and this works! So I have to
assume, the the ConnectionOptions.EnablePrivileges is not passed to my
second ManagementEventWatcher.Start() code. This now looks like a bug for
me. Because I really want to connect to a huge number of computers with a
service, I would not use the Scope.Connect(), because I assume, it would
need much more resources.

Do you, or maybe someone else, have a good hint to handle this situation? I
am lerning C# and the framework, but I cannot code this in C++.

Thanks so far and
best regards,
Manfred

Manfred,

WMI provider COM objects are "free" threaded, that means they need to

run

in
a MTA thread.
When your main thread is initialized for STA, the Management classes check
the current apartment for MTA compatibility, and will create a new thread
and enter the MTA to create the COM objects, COM will marshal the interfaces
between the STA thread (running your managed code) and the MTA thread
running the native COM code.
But, your main thread (STA) has enabled the SeSecurityPrivilege for the main
thread, but this privilege is not propagated to the MTA thread,

resulting

in
an access denied exception.
Therefore I suggest you allways run your code on an MTA thread, the net
benifits are
- no marshaling overhead
- no difficult to track security issues.
- no issues due to eventsink marshalin between MTA and STA threads.

Willy.

Hi All,

interestingly, in one of my latest tests, I found privilege failure

audit

in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that after
a first connect, a second one fails and does not explain what this has

to

do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred


Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english too.

I
am

working in an NT4 domain with logged-on account domain admin and the W2K
machine are domain members.

And my chain of experiments always seems to return different results ....
I used two production machines, just to be sure, that not some fumbling
;-)
on my admin machine have caused that. Accidentally, on the next

machine,

I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with DCOMCNFG, the
behavior return to that, what I originally described and this is on

all

my
W2K machines now really the same. But this last experiment tells me, it
could have something to do with DCOM and/or WMI settings, which are
normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question [WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the meantime,
I
found, that I cannot understand some thread-settings for the Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get
"access
denied error", if I use a ManagementEventWatcher to connect to the
local
machine to receive events. Is there anybody out there, how possibly
can
explain why this happens?? If I remove this attribute or use
[MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new
EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance
isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Manfred Braun]

Hello Andy,

that's the best news I heard about this !!!!! Ok, not that bugs are all the
time good news, but if there
is a solution .... ;-) ;-)

I have a lot of ASP.Net page using the framework and I was to "shy" to triy
this, but now, I have a good reason. I'll do the update shortly and will see
and answer, if this helps/or other results.

Thanks a lot and
best regards,
Manfred

This is a known bug in System.Management.dll in .NET Framework v1.0. The bug
that prevents WMI privileges from propagating from managed code running on
STAThread to WMI core. Applying [MTAThread] to the calling thread appears to
be a partial workaround to this problem as Access Denied would still be
returned on the second time of event subscription. This problem should be
fixed in .NET Framework v1.1. Have you tried running your application with
v1.1?

--
Andy Cheung
Microsoft WMI Test Engineer
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Hello Willy,

thanks a lot, I had not understand this completely, and so I tried to use
the [STAThread], because my code, using a [MTAThread] fails to re-connect.
Using ManagementEventWatcher.Start(), followed by .Stop() and another
.Start() failes also with access denied using the [MTAThread] attribute.

As a test, I opened a direct connection to WMI via the
ManagementScope.Connect(), left this connection open, do a .Start(),
followed by a .Stop() and another .Start() and this works! So I have to
assume, the the ConnectionOptions.EnablePrivileges is not passed to my
second ManagementEventWatcher.Start() code. This now looks like a bug for
me. Because I really want to connect to a huge number of computers with a
service, I would not use the Scope.Connect(), because I assume, it would
need much more resources.

Do you, or maybe someone else, have a good hint to handle this

situation?

I
am lerning C# and the framework, but I cannot code this in C++.

Thanks so far and
best regards,
Manfred

Manfred,

WMI provider COM objects are "free" threaded, that means they need to

run

in
a MTA thread.
When your main thread is initialized for STA, the Management classes check
the current apartment for MTA compatibility, and will create a new thread
and enter the MTA to create the COM objects, COM will marshal the interfaces
between the STA thread (running your managed code) and the MTA thread
running the native COM code.
But, your main thread (STA) has enabled the SeSecurityPrivilege for

the
main

thread, but this privilege is not propagated to the MTA thread,

resulting

in
an access denied exception.
Therefore I suggest you allways run your code on an MTA thread, the net
benifits are
- no marshaling overhead
- no difficult to track security issues.
- no issues due to eventsink marshalin between MTA and STA threads.

Willy.

Hi All,

interestingly, in one of my latest tests, I found privilege failure audit
in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions or the
WqlEventQuery about security. But even all this does not explain that
after
a first connect, a second one fails and does not explain what this

has
to

do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred


Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english

too.

I

am
working in an NT4 domain with logged-on account domain admin and

the
W2K

machine are domain members.

And my chain of experiments always seems to return different results
....
I used two production machines, just to be sure, that not some fumbling
;-)
on my admin machine have caused that. Accidentally, on the next machine,
I
found a new behavior:Both versions are not running. After finding and
removing some <account deleted> entries from the ACLs with

DCOMCNFG,
the

behavior return to that, what I originally described and this is

on
all

my
W2K machines now really the same. But this last experiment tells

me,
it

could have something to do with DCOM and/or WMI settings, which are
normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question
[WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the
meantime,
I
found, that I cannot understand some thread-settings for the Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function, I get
"access
denied error", if I use a ManagementEventWatcher to connect to the
local
machine to receive events. Is there anybody out there, how possibly
can
explain why this happens?? If I remove this attribute or use
[MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new
EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to
stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where targetinstance
isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.

 

[Manfred Braun]

Hello Andy and All,

a lot of thanks for the help again! After upgrading to runtime V1.1 the same
code is excact doing what I expect!!!

A lot of thanks and
best regards,
Manfred

Hello Andy,

that's the best news I heard about this !!!!! Ok, not that bugs are all the
time good news, but if there
is a solution .... ;-) ;-)

I have a lot of ASP.Net page using the framework and I was to "shy" to triy
this, but now, I have a good reason. I'll do the update shortly and will see
and answer, if this helps/or other results.

Thanks a lot and
best regards,
Manfred

This is a known bug in System.Management.dll in .NET Framework v1.0. The bug
that prevents WMI privileges from propagating from managed code running on
STAThread to WMI core. Applying [MTAThread] to the calling thread

appears

to
be a partial workaround to this problem as Access Denied would still be
returned on the second time of event subscription. This problem should be
fixed in .NET Framework v1.1. Have you tried running your application with
v1.1?

--
Andy Cheung
Microsoft WMI Test Engineer
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Hello Willy,

thanks a lot, I had not understand this completely, and so I tried to use
the [STAThread], because my code, using a [MTAThread] fails to re-connect.
Using ManagementEventWatcher.Start(), followed by .Stop() and another
.Start() failes also with access denied using the [MTAThread] attribute.

As a test, I opened a direct connection to WMI via the
ManagementScope.Connect(), left this connection open, do a .Start(),
followed by a .Stop() and another .Start() and this works! So I have to
assume, the the ConnectionOptions.EnablePrivileges is not passed to my
second ManagementEventWatcher.Start() code. This now looks like a bug for
me. Because I really want to connect to a huge number of computers

with

a

service, I would not use the Scope.Connect(), because I assume, it would
need much more resources.

Do you, or maybe someone else, have a good hint to handle this

situation?

I
am lerning C# and the framework, but I cannot code this in C++.

Thanks so far and
best regards,
Manfred


Manfred,

WMI provider COM objects are "free" threaded, that means they need

to
run

in
a MTA thread.
When your main thread is initialized for STA, the Management classes check
the current apartment for MTA compatibility, and will create a new thread
and enter the MTA to create the COM objects, COM will marshal the
interfaces
between the STA thread (running your managed code) and the MTA thread
running the native COM code.
But, your main thread (STA) has enabled the SeSecurityPrivilege for the
main
thread, but this privilege is not propagated to the MTA thread, resulting
in
an access denied exception.
Therefore I suggest you allways run your code on an MTA thread, the net
benifits are
- no marshaling overhead
- no difficult to track security issues.
- no issues due to eventsink marshalin between MTA and STA threads.

Willy.

Hi All,

interestingly, in one of my latest tests, I found privilege failure
audit
in
the eventlog, claming the denied access to the right SeSecurityPrivilege
.....

With this in mind, I changed the query in my sample

from:
select * from __instancecreationevent where targetinstance isa
'Win32_NTLogEvent'";

to:
"select * from __instancecreationevent where TargetInstance isa
'Win32_NTLogEvent' and TargetInstance.LogFile = 'Application'";

This is working. But this means, that setting the
ConnectionOptions.EnablePrivileges = true has no effect using the
ManagementEventWatcher. But in the constructor, I pass a
ManagementScope,
with this option set!

I found no information inside the SDK in the EventWatcherOptions

or
the

WqlEventQuery about security. But even all this does not explain that
after
a first connect, a second one fails and does not explain what this has
to
do
with setting the [xxxThread] option for my Main() function.

Any help would be really very welcomed!

Thanks so far and
best regards,
Manfred


Hello Willy,

oh, yes and sorry for my inaccuracy about the environment. I am using
Windows 2000 Server, english, SP3, dot.net runtime 1.0, english

too.

I
am
working in an NT4 domain with logged-on account domain admin and the
W2K
machine are domain members.

And my chain of experiments always seems to return different results
....
I used two production machines, just to be sure, that not some
fumbling
;-)
on my admin machine have caused that. Accidentally, on the next
machine,
I
found a new behavior:Both versions are not running. After

finding
and

removing some <account deleted> entries from the ACLs with DCOMCNFG,
the
behavior return to that, what I originally described and this is on
all
my
W2K machines now really the same. But this last experiment tells me,
it
could have something to do with DCOM and/or WMI settings, which are
normally
remains at the OS defaults.

Thanks so far and
best regards,
Manfred

Works for me with both, STA and MTAThread attribute set.

What OS are you runnng?

Willy.


Hi All,

I have allready tried to ask a similar question
[WQLEventQuery:Second
local
connect:Access denied!], but got no answer until now. In the
meantime,
I
found, that I cannot understand some thread-settings for the
Main()
function
[I am using C#].
If I use the [STAThread] attribute for the Main() function,

I
get

"access
denied error", if I use a ManagementEventWatcher to connect

to
the

local
machine to receive events. Is there anybody out there, how
possibly
can
explain why this happens?? If I remove this attribute or use
[MTAThread]
instead it works one time.
I append a short sample at the end.

Some help would be really very good.

Thanks so far and
best regards
Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany

mailto:[email protected]
Phone : +49-621-37 53 86
(Remove the anti-spam-underscore to mail me!)

/*
Name: WMIAsyncQuerySampleReconnectSample5a.cs
*/

using System;
using System.Management;

class Sample_ManagementEventWatcher
{
[STAThread]
public static int Main(string[] args)
{
if(args.Length != 0)
{
string comp = args[0];

MyHandler mh;
EventArrivedEventHandler eventArrivedEventHandler;
ManagementEventWatcher watcher;

mh = new MyHandler();
eventArrivedEventHandler = new
EventArrivedEventHandler(mh.Arrived);
watcher = Sample_ManagementEventWatcher.getWatcher(comp);
watcher.EventArrived += eventArrivedEventHandler;

watcher.Start(); //Access denied!
Console.WriteLine("Watcher is running, press <enter> to
stop...");
Console.ReadLine();
watcher.Stop();
watcher.EventArrived -= eventArrivedEventHandler;
}
else
Console.WriteLine("Args!!! [P1=Computername]");

return 0;
}

public static ManagementEventWatcher getWatcher(string comp)
{
ConnectionOptions co;
ManagementPath mp;
ManagementScope ms;
WqlEventQuery EventQuery;
ManagementEventWatcher watcher;
string wql;

co = new ConnectionOptions();
co.Timeout = new TimeSpan(0, 0, 60);
co.EnablePrivileges = true;

mp = new ManagementPath();
mp.NamespacePath = @"\root\cimv2";
mp.Server = comp;
ms = new ManagementScope(mp, co);

wql = "select * from __instancecreationevent where
targetinstance
isa
'Win32_NTLogEvent'";
EventQuery = new WqlEventQuery(wql);

watcher = new ManagementEventWatcher(ms, EventQuery);

return watcher;
}


public class MyHandler
{
public void Arrived(object sender, EventArrivedEventArgs e)
{
ManagementBaseObject mbo =
(ManagementBaseObject)e.NewEvent["TargetInstance"];
Console.WriteLine("Event:{0}", mbo["message"]);
}
}

}//Namespace.