ADSI query freezes PowerShell script when using "localhost" as computername RRS feed

  • Question

  • Hi,

    As part of my learning PowerShell I'm writing some basic functions for querying local users and groups.  I have located the following as a "base" for locating local user accounts on a given computer:

    $CompObj = [ADSI]"WinNT://$ComputerName,computer"
    $Users = $compobj.psbase.children | Where-Object {$_.psbase.schemaclassname -eq "user"}

    What I've found (at least on most of the computers that I have tried) is that the script will freeze if run with "localhost" in the $ComputerName variable (which I often do when testing a script).  The point that it freezes is the "... | Where-Object {$_.psbase.schemaclassname -eq "user"}" component of the script.

    I verified this by running the following:

    $ComputerName = "localhost"
    $CompObj = [ADSI]"WinNT://$ComputerName,computer"
    $Users = $compobj.psbase.children

    This causes no freeze.

    So, the creation of the $Users variable does not cause a script freeze.  However, if I try to display the contents of the $Users variable *after* running the above code, I get a list of all of the local users and groups, before it freezes the script completely.  Here are the last two entries I get when I run it (removed references to my production domain):


    DistinguishedName :
    Path              : WinNT://acme.local/localhost/Message Capture Users

    distinguishedName :
    Path              : WinNT://acme.local/localhost/WinRMRemoteWMIUsers



    PowerShell continues to run at this point, prompting me (in the status bar) to press "Ctrl+Break" if I wish to stop it.  If I do, PowerShell displays "Stopping" in the status bar, and in fact it never finishes stopping (I have to close Powershell, though not forcibly).  I ran this on a colleagues computer and we found that the output also includes Services (remember that we didn't filter it this time with the "Where-Object" cmdlet.

    So, we reason that something about the services causes the script to freeze.  I have tried this on the following (not hugely extensively, one of each):

    Win 7 SP1 x86: Appears to work

    Win 7 SP1 x64: script freezes

    Win 2008 R2 x64: script freezes

    Win 2012 R2 x64: script freezes.

    I'm not sure if the architecture is to blame at all, but I don't want to chase this as it's not a high priority; I'm very curious though to know the cause and how to troubleshoot it.

    I did trace the problem to the usage of the word "localhost" in the $ComputerName variable; if I use the actual computer name in place of localhost, the script runs exactly as planned and when I try to display the contents of "$User" it does not freeze before showin the services, and displays the services correctly.

    So, I'm trying to identify why this happens - I am thinking that I will have to validate the input into my script to prevent usage of the "localhost" value (or find a clever way to translate that into the hostname itself).

    Has anyone experienced this issue before or can help me identify what is causing the behaviour?

    Tuesday, October 21, 2014 2:47 AM


    • Marked as answer by Gareth.T Tuesday, October 21, 2014 10:34 AM
    Tuesday, October 21, 2014 7:29 AM

All replies

  • The behavior is by design?


    • Edited by jrv Tuesday, October 21, 2014 5:44 AM
    Tuesday, October 21, 2014 5:34 AM
    • Marked as answer by Gareth.T Tuesday, October 21, 2014 10:34 AM
    Tuesday, October 21, 2014 7:29 AM
  • Thanks... makes sense.  I tried to add to the bug report but I have trouble logging into the page for some reason...

    Tuesday, October 21, 2014 10:34 AM
  • Does it still hang if you use $Env:COMPUTERNAME instead of 'localhost' as the computer name?

    -- Bill Stewart [Bill_Stewart]

    Tuesday, October 21, 2014 12:27 PM
  • Thanks - I'll have my script check for localhost and use "$Env:COMPUTERNAME" to replace it if it does.

    It certainly works as expected, since it passes the computername to the ADSI query instead of "localhost", which does.

    Tuesday, October 21, 2014 7:18 PM