Some WMI instances can have their first method call fail and get-member not work in PowerShell V1

Some WMI instances can have their first method call fail and get-member not work in PowerShell V1

  • Comments 7

Due to a problem retrieving the available methods in V1 that we have worked around for the upcoming version of PowerShell, you might experience that the first method call to a WMI object fails with a message that mentions:

           Exception calling GetType() with “0” argument(s): “You cannot call a method on a null-valued expression.”

 

This happens when calling the first method in objects that are not in the root\cimv2 like:

           $instance=([wmiclass]"root\MyNamespace:MyObject").CreateInstance()

           $instance.GetType()

 

As a PowerShell V1 workaround, a first call to GetType() can be performed to prevent the failure in other method calls.

 

Also, the get-member cmdlet will fail to work with the instance above with the following error message:

           Get-Member : Exception retrieving members: “Not Found “

 

As a PowerShell V1 workaround, you can list the properties available in the object by calling:

         $instance.PsObject.Properties | format-table Name

 

We apologize for the inconvenience this might cause.

 

Lucio Silveira [MSFT]
Software Developer Engineer
Visit the Windows PowerShell Team blog at:   
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx 

Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post
  • I love to use the Get-WMIobject cmdlet but..

    How about using the .PUT() method? I have a bug submitted since April 17th/29th and haven't heard anything yet.  

    Bug ID: 340983

    This issue keeps bugging me so I did more testing. From my Vista Desktop, I ran this cmdlet that use the WMI win32_operatingsystem so I can change the computer description (using the *Put() method) on any server on our network when needed.

    $Test = get-wmiobject -Class "Win32_OperatingSystem" -ComputerName "ServerCore"

    $Test.description = "ServerCore Sample1"

    $Test.Put()

    Here's what I found:

    From Vista to any Windows Server 2003 -> Always WORK.

    From Vista to any Windows XP -> Always WORK.

    From Vista to any Windows Server 2008 (or Core) -> ONLY WORK the FIRST TIME.

    From Windows Server 2008 to Windows Server 2008 -> ONLY WORK the FIRST TIME.

  • MaxT,

    Sounds more like a direct WMI provider issue.  Likely the PowerShell team will have to pass this off to someone in WMI...

    I don't think PowerShell will be able to fix this problem...

  • Hi.  This never works on Windows Server 2008.  Your workaround does not work either.  Any suggestions?  I am trying to set the server description.  I can always use a registry hack.  But that is so NOT elegant.

    $x = Get-WmiObject -class "Win32_OperatingSystem" -NameSpace "Root\CIMV2"

    $x.Description = "Test"

    $x.gettype()

    $x.put()

    Exception calling "Put" with "0" argument(s): "Exception calling "Put" with "0" argument(s): "Value out of range

    At line:1 char:7

    + $x.put( <<<< )

  • I've tried this method as well with no luck:

    http://www.microsoft.com/technet/scriptcenter/topics/winpsh/wmiin2.mspx

    So rather than:

    $x = get-wmiobject win32_operatingsystem

    $x.description = "Test"

    $x.put()

    I tried:

    set-wmiinstance -class win32_operatingsystem -argument @{description="Test"}

    Neither work and give different error messages.  More odd though, the first time I used the .put() method to change the description it worked.  Subsequent attempts have all failed.

  • So this will is a trick:

    $x = get-wmiobject win32_operatingsystem

    $x.description = "Test"

    &{

       Trap [System.Management.Automation.MethodInvocationException] {

           "first put will fail but this is the hack"

           continue

       }    

       &{

          $x.put()

       }

    }

    $x.put()

    It means: catch the first Exception and then do the final put()

    AFAIK &{ and } around the Trap will prevent the shell fron catching _all_ MethodInvocationException of the following code

    Happy Hacking

  • So this will is a trick:

    $x = get-wmiobject win32_operatingsystem

    $x.description = "Test"

    &{

       Trap [System.Management.Automation.MethodInvocationException] {

           "first put will fail but this is the hack"

           continue

       }    

       &{

          $x.put()

       }

    }

    $x.put()

    It means: catch the first Exception and then do the final put()

    AFAIK &{ and } around the Trap will prevent the shell fron catching _all_ MethodInvocationException of the following code

    Happy Hacking

  •    $ErrorActionPrefTemp = $ErrorActionPreference

       $ErrorActionPreference = "SilentlyContinue"

       $cnt = 0    # Do it again if it fails as there is a bug with Powershell/WMI

       DO

       {

    $cnt = $cnt + 1

           $newPool.Put()

       } WHILE (!$? -AND ($cnt -lt 10))

       $ErrorActionPreference = $ErrorActionPrefTemp

Page 1 of 1 (7 items)