Win32_Process.Getowner() very slow on a specific machine RRS feed

  • General discussion

  • I'm trying to get the owner of a process by running this WMI query in powershell:

    $processes = Get-WmiObject Win32_Process |where{$ -like "*notepad*"}
    $objcol = @()
    foreach ($process in $processes) 
        $owner = $process.GetOwner().User
        #$owner = $process.ProcessId
        $obj = New-Object System.Object
        $obj |Add-Member -MemberType NoteProperty -Name Owner -Value ($owner)
        $obj |Add-Member -MemberType NoteProperty -Name pid -Value $process.ProcessId
        $owner = "" 
        $objcol += $obj
    $objcol | ft  owner, pid -AutoSize |Out-String -Width 300 

    But somehow on a specific machine (windows server 2008), it takes 30mins to finish this short script. If I remove the line "$owner = $process.GetOwner().User", and replace it with "$owner = $process.ProcessId", the query can finish in a few seconds. But on other machines (Windows Server 2003, 2008, 2012), there is no such kind of problem. So I think it has something to do with this Win32_Process.Getowner() method but not sure how.

    Can anyone help? Thanks in advance!

    Monday, April 27, 2015 10:25 AM

All replies

  • I'm not able to reproduce the performance problem.

    However, I would recommend the following more PowerShell-like construction:

    get-wmiobject Win32_Process -filter "Name='notepad.exe'" | select-object `
      @{Name="Owner"; Expression={$_.GetOwner().User}},
      @{Name="pid";   Expression={$_.ProcessId}}

    First, you can filter the WMI query using the -filter parameter (makes the query more efficient). Second, there's no need to construct a new object and then output it when you can use Select-Object with calculated properties.

    -- Bill Stewart [Bill_Stewart]

    Monday, April 27, 2015 2:36 PM
  • Are you running this against a remote machine (via either Invoke-Command, use of jobs or passing -ComputerName to Get-WmiObject) or are you running it locally on each machine? This will affect things a lot.

    When you're querying WMI, you're actually asking the Windows Management Instrumentation service to do the work for you, so you're dependent on that service. If the service is busy doing other things, you will notice a slowness in retrieving info from it.

    The most important thing to ascertain is... can you replicate this? As in, does it happen every time you try to run that script on that box, or just the one time? Have you retried it after restarting the server? I once had my WMI service in such a state that whatever query I ran would return immediately and produce no results at all. Fix? Restart.

    I know it's a server but you're after a solution, so let's start with the basics and try giving the server a restart and trying again, ensure the problem is replicable, etc.

    Monday, April 27, 2015 3:03 PM
  • @Bill_Stewart

    Thanks for your suggestions, and a question for you. If I use -filter "Name='notepad.exe'", can I use it like this: "name like '*notepad*'". Cause it does not seem to be working for me...

    And actually my script's performance is good on the non-problematic machines, while it's so bad on this specific machine. So the question is what my cause such a big difference?

    Tuesday, April 28, 2015 5:40 AM
  • @FaustoNascimento

    I'm running this script locally and also remotely. On this problematic machine, the performance is as bad no matter I run the script locally or remotely for it.

    And yes, I can recreate the problem, it has been like this for quite a few months actually, just as good as the other machines. The server must have been rebooted quite a few times during the time. 

    One thing to note is, the script used to be working fine on this specific machine before. But it became bad at some point. I'm doubting that there was some change on the machine which casued this but not sure what could it be...

    Tuesday, April 28, 2015 5:51 AM
  • Kevin,

    the -Filter syntax is WQL so the correct form would be:

    -Filter "Name like '%notepad%'"

    There are a couple other things you can try too. If the servers are running PSv3 or higher, have a look at using the new CIM cmdlets. Even though it still relies on the WMI service, it should at least give you a way of checking where the problem is likely to lie.

    Tuesday, April 28, 2015 11:58 AM
  • So the question is what my cause such a big difference?

    As I noted previously, I can't reproduce the problem. All I can do is point out a better way to write the code.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, April 28, 2015 12:34 PM