Process.EnableRaisingEvents = true causes exception on Win2K3 SP2

[Guest]

I have a class in my application that monitors for a few given processes
going up or down so that the user can be shown visually that something is
wrong. This class works fine for Windows 2003 SP1 but as soon as I apply SP2
I get many exceptions like:

System.ComponentModel.Win32Exception: Access is denied
at System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32
access, Boolean throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean
throwIfExited)
at System.Diagnostics.Process.GetProcessHandle(Int32 access)
at System.Diagnostics.Process.OpenProcessHandle()
at System.Diagnostics.Process.set_EnableRaisingEvents(Boolean value)

The EnableRaisingEvents seems to be the culprit. Sample code:
Process [] allProcesses = Process.GetProcesses();
foreach( Process p in allProcesses )
{
if( p.Id != 0 && p.HasExited == false)
{
p.Exited += new EventHandler( ProcessTerminatedEvent);
p.EnableRaisingEvents = true;
}
}

This is using Visual Studio 2003 and the .NET 1.1 Framework. I trap and
ignore these exceptions on the processes that I don't care about but I'm
getting this on the service that my GUI app is starting as well as the 2
processes that the service starts.

I can't find any answers elsewhere on why this is a problem in SP2 for
Windows 2003. The full source code is available to anyone who needs it but
there's not much more since I tried to trim the problem down to the bare
minimum.

Thank you for any assistance you can give,
George Davis

 

[Peter Duniho]

I have a class in my application that monitors for a few given processes
going up or down so that the user can be shown visually that something is
wrong. This class works fine for Windows 2003 SP1 but as soon as I
apply SP2
I get many exceptions like:

System.ComponentModel.Win32Exception: Access is denied

While I don't have a definite answer, at first glance the exception seems
pretty clear: you don't have the security privileges needed to change the
property on that process, because doing so requires opening the process
handle in a way that's not allowed (probably with write access to change
some Windows state of the process). It seems likely to me that Server
2003 SP2 changed the default security settings to disallow this.

You may be able to find the setting that was changed (probably in the
Security Policy, either Local or Group depending on your configuration)
and revert back to the older setting. But it would probably be better to
stick with the new setting for security reasons, and ensure that you have
the proper security rights to access the property you want.

Pete

 

[Guest]

Hi Peter,

I agree that it looks like a security issue but this was tested with the
same admin user on the same machine and SP2 was the only change (no changes
to group policies). When I used Process Explorer to look at the Security
settings for the app while running, the only privilege that the app had when
running SP1 that it didn't have with SP2 was "SeDebugPrivilege". From what I
can find on this privilege, it is for use in attaching a debugger to a
process. The list of privileges disabled (according to Process Explorer) in
SP1 and SP2 were:

(SP1) (SP2) SeBackupPrivilege
(SP1) (SP2) SeCreatePagefilePrivilege
(SP2) SeDebugPrivilege - not disabled in SP1
(SP1) (SP2) SeIncreaseBasePriorityPrivilege
(SP1) (SP2) SeIncreaseQuotaPrivilege
(SP1) (SP2) SeLoadDriverPrivilege
(SP1) (SP2) SeManageVolumePrivilege
(SP1) (SP2) SeProfileSingleProcessPrivilege
(SP1) (SP2) SeRemoteShutdownPrivilege
(SP1) (SP2) SeRestorePrivelege
(SP1) (SP2) SeSecurityPrivilege
(SP1) (SP2) SeShutdownPrivilege
(SP1) (SP2) SeSystemEnvironmentProfile
(SP1) (SP2) SeSystemProfilePrivilege
(SP1) (SP2) SeSystemtimePrivilege
(SP1) (SP2) SeTakeOwnershipPrivilege
(SP1) (SP2) SeUndockPrivilege

All "enabled" privileges were the same on SP1 and SP2. This might still be
a security issue but I'm just in search of how to fix this whether it's
through configuration/security changes or code changes.

Thanks,
George

 

[InDepth]

MSDN documentation states:
"To open a handle to another another local process and obtain full access
rights, you must enable the SeDebugPrivilege privilege"
(for example, http://msdn2.microsoft.com/en-us/library/ms684320.aspx)

And to get events from another process requires full access rights.

 

[Guest]

My boss found a code fix that will elevate your privileges so that you can
register for events on other processes:

System.Diagnostics.Process.EnterDebugMode();

From the MSDN help on this method:

"Puts a Process component in state to interact with operating system
processes that run in a special mode by enabling the native property
SeDebugPrivilege on the current thread."

When you get done, you can use the following line to lower your privilege
level back to "normal":

System.Diagnostics.Process.LeaveDebugMode();

I hope this saves someone else the many, many frustrating hours of searching
I put in trying to find a fix for this.

--George