Same thing happens in C#... "The exception happens when the text of the event contains the string %% followed by a long number" Apparently, when Powershell tries to query via Get-Winevent and retrieves %% followed by a long number, (Or maybe for some other reason, I think it has more to do with %% then any following value) Powershell chokes and gives error in title of this post. It would appear that Windows software engineers did not consider this combination of return characters that makes Powershell and .Net logic throw up.
I want to catch this error and handle in a cleaner fashion in Powershell (The post link above is for C#), any suggested way to catch and handle this error in Powershell script would be better than the exception thrown; all the way down to "can't get critical logs from this PC" and proceed.
get-winevent -LogName system -ComputerName $CompName | where {$_.LevelDisplayName -eq 'Critical' -and $_.TimeCreated -ge (Get-Date).AddDays(-30)} | Select-Object -Property TimeCreated, @{name='State';expression={$_.LevelDisplayName}}, Message | Format-Table -Auto -Wrap
BTW, this command runs just fine 99% of the time, it only throws when %%longassnumber is returned.
Use the -FilterHashtable parameter instead of Where-Object. It seems to be specifically designed to process this type of information.
get-winevent -ComputerName $CompName -FilterHashtable @{logname='system'; level=1; StartTime=(get-date).AddDays(-30) } | Format-Table -Auto -Wrap
The Answer was Here: Article by Doctor Scripto, and is referenced in many places for solutions to System log queries via Powershell.
Furthermore, it delivers the log information exponentially faster! (Found article that states that -FilterHashtable should be used instead of Where-Object due to it being so slow...)