Process.GetProcesses, Vista & Access Denied errors

[Jimmy Jam]

While enumerating processes on Vista, I get access denied errors,
specifically when trying to get the file path.
I am using MS Visual Studio 2008 Professional Edition. I develop on Windows
XP, and it runs fine in that environment.
I have enabled full trust application under security. The target Vista
machine has v2.0 and v3.0 of the framework installed.

The only way I could get the full path information was to run the
application as administrator.
My question is : is there some other way to do this and return all the
information required information ?
I don't want my users to have to do anything other than run the application.

My simple code:
==================================================================
Dim oProcesses() As Process =
System.Diagnostics.Process.GetProcesses()
Dim sPath As String

For Each oProc As Process In oProcesses
If Not (oProc.Id = 0) And Not (oProc.Id = 4) Then
Dim lvi As ListViewItem

lvi = ListView1.Items.Add(oProc.ProcessName)
Try
sPath = oProc.MainModule.FileName
lvi.SubItems.Add(sPath)
Catch ex As Exception
lvi.SubItems.Add("")
End Try
End If
Next
==================================================================

I am a .Net noob.

Thanks for your help,
Jj

 

[C Kevin Provance]

And managed code is supposed to be superior. LOL. VB6 and some well placed
API would have accomplished this with no problems. ;-)

| While enumerating processes on Vista, I get access denied errors,
| specifically when trying to get the file path.
| I am using MS Visual Studio 2008 Professional Edition. I develop on
Windows
| XP, and it runs fine in that environment.
| I have enabled full trust application under security. The target Vista
| machine has v2.0 and v3.0 of the framework installed.
|
| The only way I could get the full path information was to run the
| application as administrator.
| My question is : is there some other way to do this and return all the
| information required information ?
| I don't want my users to have to do anything other than run the
application.
|
| My simple code:
| ==================================================================
| Dim oProcesses() As Process =
| System.Diagnostics.Process.GetProcesses()
| Dim sPath As String
|
| For Each oProc As Process In oProcesses
| If Not (oProc.Id = 0) And Not (oProc.Id = 4) Then
| Dim lvi As ListViewItem
|
| lvi = ListView1.Items.Add(oProc.ProcessName)
| Try
| sPath = oProc.MainModule.FileName
| lvi.SubItems.Add(sPath)
| Catch ex As Exception
| lvi.SubItems.Add("")
| End Try
| End If
| Next
| ==================================================================
|
| I am a .Net noob.
|
| Thanks for your help,
| Jj
|
|

 

[Alex Clark]

And managed code is supposed to be superior. LOL. VB6 and some well
placed
API would have accomplished this with no problems. ;-)

I very much doubt that. Vista doesn't care whether you're running under
..NET or calling APIs directly - it only cares that you're trying to do
something that requires Admin privs when you don't have them, and *that* is
why you get the UAC prompt. There's not much that VB6 was or is superior
for.

Personally I'm surprised this ran at all for you even on XP without any
error handling. I've used similar code in a routine which I wanted to use
to close down any apps that were using a specific DLL of mine, and when it
tried to access the SYSTEM process it tripped up - even with full Admin
privs on my XP machine.

Accessing information like that about other processes running on the system
requries admin privs. You either demand them at startup, or let UAC prompt
the user when necessary. It is a necessary security measure.

 

[Family Tree Mike]

I very much doubt that. Vista doesn't care whether you're running under
.NET or calling APIs directly - it only cares that you're trying to do
something that requires Admin privs when you don't have them, and *that*
is why you get the UAC prompt. There's not much that VB6 was or is
superior for.

Personally I'm surprised this ran at all for you even on XP without any
error handling. I've used similar code in a routine which I wanted to use
to close down any apps that were using a specific DLL of mine, and when it
tried to access the SYSTEM process it tripped up - even with full Admin
privs on my XP machine.

Accessing information like that about other processes running on the
system requries admin privs. You either demand them at startup, or let
UAC prompt the user when necessary. It is a necessary security measure.

The code does fail on XP under a restricted account that I am forced under.

 

[expvb]

While enumerating processes on Vista, I get access denied errors,
specifically when trying to get the file path.

This could happen on older OS versions too, so don't expect to always get
the path. Some processes could adjust the security to block VM_READ
permission, so OpenProcess() would fail to get a handle, and VM_READ is
required to get the file name.

My guess is that some processes do this as a form of copy protection or
security, to make it difficult to debug a process.