You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It throws an exception, terminating analysis -- meaning I get NO RESULTS AT ALL FOR ANY RULES.
Invoke-ScriptAnalyzer : Object reference not set to an instance of an object.
$error[0,1] |Select-Object*
ErrorRecord : Object reference not set to an instance of an object.
WasThrownFromThrowStatement : False
Message : The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Object reference not set to an instance of an object.
Data : {System.Management.Automation.Interpreter.InterpretedFrameInfo}
InnerException :
TargetSite : System.Collections.ObjectModel.Collection`1[System.Management.Automation.PSObject] Invoke(System.Collections.IEnumerable)
StackTrace : at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
at Microsoft.PowerShell.Executor.ExecuteCommandHelper(Pipeline tempPipeline, Exception& exceptionThrown, ExecutionOptions options)
HelpLink :
Source : System.Management.Automation
HResult : -2146233087
PSMessageDetails :
Exception : System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Windows.PowerShell.ScriptAnalyzer.Helper.<>c__DisplayClass61_0.<GetTypeFromMemberExpressionAst>b__0(TypeDefinitionAst item)
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.Helper.GetTypeFromMemberExpressionAst(MemberExpressionAst memberAst, Ast scopeAst, IEnumerable`1 classes)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.VisitInvokeMemberExpression(InvokeMemberExpressionAst invokeAst)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.VisitCommandExpression(CommandExpressionAst commandAst)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.VisitPipeline(PipelineAst pipelineAst)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.VisitNamedBlock(NamedBlockAst namedBlockAst)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.VisitScriptBlock(ScriptBlockAst scriptBlockAst)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput..ctor(FunctionDefinitionAst ast, IEnumerable`1 classes)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.FindPipelineOutput.OutputTypes(FunctionDefinitionAst funcAst, IEnumerable`1 classes)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.UseOutputTypeCorrectly.VisitFunctionDefinition(FunctionDefinitionAst funcAst)
at System.Management.Automation.Language.FunctionDefinitionAst.InternalVisit(AstVisitor visitor)
at System.Management.Automation.Language.StatementBlockAst.InternalVisit(AstVisitor visitor, ReadOnlyCollection`1 traps, ReadOnlyCollection`1 statements, AstVisitAction action)
at System.Management.Automation.Language.NamedBlockAst.InternalVisit(AstVisitor visitor)
at System.Management.Automation.Language.ScriptBlockAst.InternalVisit(AstVisitor visitor)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.UseOutputTypeCorrectly.AnalyzeScript(Ast ast, String fileName)
at Microsoft.Windows.PowerShell.ScriptAnalyzer.ScriptAnalyzer.<>c__DisplayClass83_1.<AnalyzeSyntaxTree>b__2()
TargetObject :
CategoryInfo : InvalidOperation: (:) [Invoke-ScriptAnalyzer], NullReferenceException
FullyQualifiedErrorId : RULE_ERROR,Microsoft.Windows.PowerShell.ScriptAnalyzer.Commands.InvokeScriptAnalyzerCommand
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
Thanks for logging this. I plan to look into this and other related issues. After talking to Dongbo last month, some of it might be because of the multi-threading nature of PSSA where the ComandInfo object is being retrieved in a different thread but the PowerShell object is lazily populated. When then accessing those properties at a later time, PowerShell tries to evaluate them but the original pointer to the runspace that created might be either broken or being disposed, which then leads to those sporadic errors. That's just what we think is going on after some brainstorming but needs more investigation, we recently improved PSSA (after the 1.18.0 release) to keep a runspace pool but that seemed to not fix it, therefore I am thinking it might be best to evaluate the property of the CommandInfo object at query time to work-around what seems to be a complicated bug within PowerShell itself.
Worst case, if you can at least catch the exception and make the rule fail (incorrectly) instead of crashing (affecting all the other rules too), that would be a ... less severe bug.
I mean, it would still be failing incorrectly, but users would be able to tell what had failed (we had this happen on a build server and I had to repro locally in -verbose to even identify the rule).
It is possible to work around it (at least in our case, by putting a [void] cast in front of the already void method worked), but only after you know what the problem is.
I can repro in 1.18.0 but I can also confirm that this got already fixed in the development branch by PR #1182 :-)
We plan to release 1.18.1 in the next 1-2 weeks and are trying to wrap everything up at the moment.
This is related to #602 but complicated to reproduce:
Then PSUseOutputTypeCorrectly will throw a null reference exception -- presumably trying to check the output type of the
[void]
method?Steps to reproduce
Expected behavior
It should be exactly the same as when I write it this way:
Actual behavior
It throws an exception, terminating analysis -- meaning I get NO RESULTS AT ALL FOR ANY RULES.
Environment data
The text was updated successfully, but these errors were encountered: