Troubleshooting Object reference not set to an instance of an object message

  • Problem description / Symptoms
Invoke-Command -ComputerName RemotePC -FilePath e:\myfile.ps1 -Verbose

Object reference not set to an instance of an object.
+ CategoryInfo : OpenError: (RemotePC:String) [], RemoteException
+ FullyQualifiedErrorId : PSSessionStateBroken

Enter-PSSession -ComputerName RemotePC

Enter-PSSession : Object reference not set to an instance of an object.
At line:1 char:2
+ Enter-PSSession -ComputerName RemotePC
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Enter-PSSession], NullReferenceException
+ FullyQualifiedErrorId : RemoteRunspaceStateInfoReason

  • Prerequisites:

If you haven’t done it yet and if you want to understand how Remoting works in Powershell, you absolutely need to read the free Secrets of Powershell Remoting ebook written by Don Jones and Tobias Weltner. There’s a whole chapter on Diagnotics and Troubleshooting and a diagram on the elements and components of PowerShell Remoting on page 9 (figure 1.1)

  • Troubleshooting steps
  1. Check the WSMan protocol
  2. First we use Test-WSMan to test if the WSMan protocol, the transport protocol over HTTP on TCP port 5985 (by default), being used is working properly.

    Test-WSMan -ComputerName RemotePC

    This step validates the fact that the firewall is opened on the remote PC and that the listener on the remote PC works.

  3. Check the authentication performed over the WSMan protocol
  4. Then in a domain environment we test if the Authentication is working properly

    Test-WSMan -ComputerName RemotePC -Authentication Kerberos

    WSMan authentication

  5. Check the WSMan listener on the remote computer
  6. On the remotePC we verify the WSMan listener settings:

    dir WSMan:\localhost\Listener            
    dir WSMan:\localhost\Listener\Listener_641507880

    WSMan Listener

  7. Check the WinRM service on the remote computer
  8. On the remotePC we verify the WinRM service is running.

    Get-Service -Name WinRM |             
     Stop-Service -Force -PassThru |             
     Start-Service -Verbose


  9. Check the endpoint on the remote computer
  10. Get-PSSessionConfiguration            
    Get-PSSessionConfiguration -Name microsoft.powershell | fl -p *


    Before switching to advanced troubleshooting mode, we run the following additional steps:

  11. Restart the computer
  12. Restart-Computer -ComputerName RemotePC -Force -wait -For:WinRM
  13. Connect with another user
  14. Invoke-Command -ComputerName RemotePC -Credential (            
    Get-Credential DomainName\UserName) -ScriptBlock {            
     Write-Host "Test"            

    NB: In my case, invoking command as another user works. So I won’t use the advanced troubleshooting steps that you can find the ‘Secrets of Powershell Remoting’ ebook.
    Instead we keep looking at basic things.

  15. Check the eventlog
  • There’s an event ID 1542 in the Application log complaining that it cannot load the file named UsrClass.dat located in AppData\Local\Microsoft\Windows\
    Application eventlog 1
  • Let’s get the exact time and the process ID responsible for logging the above event so that we can use this info to filter a procmon trace.
    Application eventlog 2
    Unfortunately, the procmon trace doesn’t even show that it fails to found the UsrClass.dat.
  • Wait, there’s another event in the ‘Known folders’ log,

    Eventlog Known folders
    We can also see that it cannot find the ‘temporary internet files’ located in AppData\Local\Microsoft\Windows\Temporary Internet Files

  • When I try to open a cmd window ‘running as a different user’, I can’t
    Open cmd via RunAs
  • Cause

It appears actually that the AppData\Local folder is simply missing inside the user profile.

  • Solution

I ended up deleting the user profile and everything turned back to normal.

3 thoughts on “Troubleshooting Object reference not set to an instance of an object message

  1. To fix this just delete the contents of the command cache folder in your profile:
    del “$env:userprofile\AppData\Local\Microsoft\Windows\PowerShell\CommandAnalysis\*” -force
    Close and reopen PowerShell and the cache will be rebuilt the first time you run Get-Command.

    • If your fix worked for you, that’s fine. Your profile wasn’t as “corrupted” as mine was.
      Your fix couldn’t work for me as the $env:userprofile\AppData\Local folder was completely missing.
      Thx for your feedback. It will probably help others establishing a more precise diagnosis.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.