Okay, this is a long one...
Based on what we've determined so far, I have an even stronger suspicion than before that what is happening has something to do with VisualCron attempting to parse Powershell scriptblocks as variables. They are both enclosed in {}, the problem only arises when using the Powershell script task in the context that would allow for use of Visualcron variable expressions...both of those seem to fit the hypothesis. The fact that a space before the closing brace of a script block seems to prevent the problem for me fits with the idea of it being a parsing problem, although it's still odd.
I even have a possible explanation for the "'No' is not recognized as the name..." exception that fits this hypothesis, although I don't know why you get that while we get crashes. If I copy that scriptblock and paste it into the Variables window WITH a space before the closing brace, the value preview just gives me back the scriptblock. If I remove the space (making it match the scriptblock that was causing me problems), the value preview changes to:
(No match on $_.Stats.Status -eq "Running" -and $_.Stats.DateLastExecution -lt (get-date).AddHours(-2))
Based on messing around a bit more, the specific circumstances under which the preview will give the "No match" message instead of just giving back the string exactly as entered is if the string contains a matched pair of {}, between which neither of those characters appears again, but at least one opening parenthesis does appear and a closing parenthesis is the last character before the }.
To put it in a regular expression: \{[^\{\}]*\([^\{\}]*\)\}
If on your installation Visualcron is actually substituting "No match on..." and so forth into the script to be executed, then the exception you quoted is exactly what Powershell would return. You could probably confirm that by running this, which I believe should display enough of a stack trace to see the substituted text if that's what's happening:
param($address="localhost")
try {
add-type -Path "c:\Program Files (x86)\VisualCron\VisualCron.dll"
add-type -Path "c:\Program Files (x86)\VisualCron\VisualCronAPI.dll"
$c = new-object VisualCronAPI.Client
$conn = new-object VisualCronAPI.Connection
$conn.Address = $address
$conn.UserName = 'usernameRedacted'
$conn.Password = 'passwordRedacted'
$s = $c.Connect($conn,$true)
$j = $s.Jobs.GetAll() | ?{$_.Stats.Status -eq "Running" -and $_.Stats.DateLastExecution -lt (get-date).AddHours(-2)}
$j | select-object Group, Name
$c.Disconnect($s)
}
catch{
$error | fl * -f
}
...I can't use that to confirm or deny, because that still goes into a runaway memory consumption for me. And of course, that still doesn't answer why you get substitution and we get crashes. I have only tested this on one of my two servers so far; it's running 6.2.2 on Windows Server 2008 64-bit with service pack 2.
What I'm chiefly interested in now is making sure I avoid this in the future. So far, adding a space before the closing brace of all Powershell blocks seems to prevent it, but I don't know whether that will remain reliable in future versions. I didn't find anything in the documentation indicating a way to escape {} characters so that VisualCron's variable substitution parser will ignore them. If there is a way to do that, then I could try that next, and if that also prevents the crash I'll feel a little bit safer about my approach.