Engine health report

Yesterday, we had strange reports from our custom security compliance audit process based on PowerShell and remoting.

We’ve got a computer that said:
The following error occurred while loading the extended type data file: Microsoft.PowerShell.Core, C:\Windows\System32\WindowsPowerShell\v1.0\types.ps1xml : Exception: ‘♦’, hexadecimal value 0x04, is an invalid character. Line 212, position 4.
What a nice and precise error that tells you immediately what’s wrong.

As you can see in the following screenshot, I got the above error as soon as I enter the remote session and the automatic variable $PSVersionTable being altered and reporting a hashtable with empty keys names:

What’s wrong with types.ps1.xml? It’s a signed protected system file. I mean that it has a signature block at the end of the file:

..and that it’s protected by NTFS ACLs:

Ok, let’s compare a safe computer named Pxxxx5 and the failing one Pxxxx7.

If we check the file size, timestamp,…

… there’s nothing wrong.

But if I check its signature…

… the built-in Get-AuthenticodeSignature cmdlet shows that the file on the failing computer has lost its integrity.

If I compare the content, we can see:

Weird, isn’t it?

Besides the fact the error reported tells you exactly what’s wrong and that PowerShell lets you easily analyze the problem, there’s another good news:
The following event is logged in the “Windows PowerShell” log.
. This makes the issues easily detectable.

Get-WinEvent -ComputerName $computer -FilterHashtable @{ 
    LogName = "Windows PowerShell" ;
    Level = 3 ;
    Id = 103 
}  -MaxEvents 1

You may wonder how the file was corrupted.
We’ve talk to the user about the behavior of his computer. He said that there’s was a power cut in the morning.

Advertisement