-
Notifications
You must be signed in to change notification settings - Fork 87
Known issues with runspaces
Some built-in types have additional ScriptProperty objects added by PowerShell. A good example is the [guid] type which has a Guid ScriptProperty of {$this.ToString()}. Normally you could define an argument like:
$MyParameter = [guid]::NewGuid().Guid
However, under heavy load, it's possible that at the time of object instantiation and the script running, PowerShell has not yet decorated the object with its ScriptProperty yet. So the proper alternate method is to access the property you want directly (the one built into the object):
$MyParameter = [guid]::NewGuid().ToString()
This is only a problem in the parameter definition for functions and not elsewhere.
If you do not do this, or you do it similarly elsewhere, you will receive an occasional exception on jobs with a message about BeginInvoke, and this can be very difficult to track down.
Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
If you see this error message, check your code for a Write-Output, Write-Host, Write-Error, which are being passed a $null argument.
For example:
$something = $null # Unexpectedly
Write-Output $something
While this has no effect outside of PoshRSJob, in this case it will trigger the above error. A fuller exception is as below:
ErrorRecord : Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
WasThrownFromThrowStatement : False
Message : Exception calling "EndInvoke" with "1" argument(s): "You cannot call a method on a null-valued expression."
Data : {}
InnerException : System.Management.Automation.CmdletInvocationException: You cannot call a method on a null-valued expression. --->
System.Management.Automation.RuntimeException: You cannot call a method on a null-valued expression.
at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
at System.Management.Automation.PSScriptCmdlet.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
at System.Management.Automation.PSScriptCmdlet.DoProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
--- End of inner exception stack trace ---
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
at CallSite.Target(Closure , CallSite , Object , Object )
TargetSite : Void ConvertToMethodInvocationException(System.Exception, System.Type, System.String, Int32, System.Reflection.MemberInfo)
StackTrace : at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at lambda_method(Closure , Object[] , StrongBox`1[] , InterpretedFrame )
HelpLink :
Source : System.Management.Automation
HResult : -2146233087
Functions which have SupportsShouldProcess will work as normal, however, the What If: output which would normally be output to screen by $PSCmdlet.ShouldProcess() outputs nothing with an RSJob. This is because it doesn't write to any normal streams that are accessible within jobs.