By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,165 Members | 1,394 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,165 IT Pros & Developers. It's quick & easy.

WMI - Win32_Process - Commandline Problem

P: n/a
Hello!
I have wrote a windows service in vb.net. This service monitors the running
processes with WMI and the Win32_Process class. Till last month all seems
ok. But since the begin of september the service can't retrieve the
commandline property of the processes. I think this is an result of .NET
Framework 1.1 Service Pack 1 or XP SP2.
Did somebody recognice the same effect? Did anybody knows how i can retrieve
the commandline property of processes that other users have started. This
problem only occurs when the service retrieve the process infos of other
users, system processes were retrieved completly with the commandline
property. When i use the code in a winform, my own processes where also
retrieved completly with the commandline property. But other user processes
have a blank commandline property too. The service is running under an
account, that was in the local admin group, so the service must have all
rights to acces the processinfos of the other users.

C. Borger
Nov 21 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi,

Seam to get an error with system idle process only. Try this.
' Add a Reference to System.Management

Dim moReturn As Management.ManagementObjectCollection

Dim moSearch As Management.ManagementObjectSearcher

Dim mo As Management.ManagementObject

moSearch = New Management.ManagementObjectSearcher("Select * from
Win32_Process")

moReturn = moSearch.Get

For Each mo In moReturn

Dim arOwner(2) As String

mo.InvokeMethod("GetOwner", arOwner)

Dim strOut As String

Trace.WriteLine("-------------")

strOut = String.Format("{0} Owner {1} Domain {2}", mo("Name"), arOwner(0),
arOwner(1))

Trace.WriteLine(strOut)

Try

Trace.WriteLine(mo("CommandLine").ToString)

Catch ex As System.Exception

Trace.WriteLine(ex.ToString)

End Try

Trace.WriteLine("-------------")

Next

Ken

----------------------------------

"Christoph Borger" <cb*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Hello!
I have wrote a windows service in vb.net. This service monitors the running
processes with WMI and the Win32_Process class. Till last month all seems
ok. But since the begin of september the service can't retrieve the
commandline property of the processes. I think this is an result of .NET
Framework 1.1 Service Pack 1 or XP SP2.
Did somebody recognice the same effect? Did anybody knows how i can retrieve
the commandline property of processes that other users have started. This
problem only occurs when the service retrieve the process infos of other
users, system processes were retrieved completly with the commandline
property. When i use the code in a winform, my own processes where also
retrieved completly with the commandline property. But other user processes
have a blank commandline property too. The service is running under an
account, that was in the local admin group, so the service must have all
rights to acces the processinfos of the other users.

C. Borger

Nov 21 '05 #2

P: n/a
Thank you for your quick answer!
I tested the code, but it appears the same problem i have discribed in my
first posting. By the own processes and the system processes, the
CommandLine property is resolved correctly, but by the processes of the
other users, the CommandLine property is empty.
i have started the program normally, all my process command lines where
shown. I have started the program under the admin account, the process
command lines of my processes are emty! But the admin account must have
enough rights to retrieve my process command lines, because all other
properties were retrieved correctly, only the commandline and the executable
path properties fails!

C. Borger
"Ken Tucker [MVP]" <vb***@bellsouth.net> schrieb im Newsbeitrag
news:%2****************@TK2MSFTNGP10.phx.gbl...
Hi,

Seam to get an error with system idle process only. Try this.
' Add a Reference to System.Management

Dim moReturn As Management.ManagementObjectCollection

Dim moSearch As Management.ManagementObjectSearcher

Dim mo As Management.ManagementObject

moSearch = New Management.ManagementObjectSearcher("Select * from
Win32_Process")

moReturn = moSearch.Get

For Each mo In moReturn

Dim arOwner(2) As String

mo.InvokeMethod("GetOwner", arOwner)

Dim strOut As String

Trace.WriteLine("-------------")

strOut = String.Format("{0} Owner {1} Domain {2}", mo("Name"), arOwner(0),
arOwner(1))

Trace.WriteLine(strOut)

Try

Trace.WriteLine(mo("CommandLine").ToString)

Catch ex As System.Exception

Trace.WriteLine(ex.ToString)

End Try

Trace.WriteLine("-------------")

Next

Ken

----------------------------------

"Christoph Borger" <cb*****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Hello!
I have wrote a windows service in vb.net. This service monitors the
running
processes with WMI and the Win32_Process class. Till last month all seems
ok. But since the begin of september the service can't retrieve the
commandline property of the processes. I think this is an result of .NET
Framework 1.1 Service Pack 1 or XP SP2.
Did somebody recognice the same effect? Did anybody knows how i can
retrieve
the commandline property of processes that other users have started. This
problem only occurs when the service retrieve the process infos of other
users, system processes were retrieved completly with the commandline
property. When i use the code in a winform, my own processes where also
retrieved completly with the commandline property. But other user
processes
have a blank commandline property too. The service is running under an
account, that was in the local admin group, so the service must have all
rights to acces the processinfos of the other users.

C. Borger

Nov 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.