Invoke-ScriptAnalyzer fails intermittently with NullReferenceException in CommandInfo.ResolveParameter (ProvideCommentHelp / AvoidReservedCharInCmdlet race on Export-ModuleMember) #2229

Activity

1. Christoph Bergmeister (bergmeister)

   added

   Issue - Bug

   on Oct 22, 2026
2. bergmeister commented on Oct 22, 2026

   

   Christoph Bergmeister (bergmeister)

   on Oct 22, 2026

   Collaborator

   More actions

   PR #2206 might fix that

   👍React with 👍1Reacted by Ondřej Tučný
3. ChrisTX commented on Nov 1, 2026

   

   Christian Pfeiffer (ChrisTX)

   on Nov 1, 2026

   More actions

   The same thing happens on Linux (PowerShell 7.6.9 on .NET 10.0.14, PSScriptAnalyzer 1.25.0 built from the 1.25.0 tag), with the same stack:

   System.NullReferenceException: Object reference not set to an instance of an object.
      at System.Management.Automation.CommandInfo.ResolveParameter(String name)
      at Microsoft.Windows.PowerShell.ScriptAnalyzer.Helper.GetExportedFunction(Ast ast)
      at Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.ProvideCommentHelp.AnalyzeScript(Ast ast, String fileName)+MoveNext()
      at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
      at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
      at Microsoft.Windows.PowerShell.ScriptAnalyzer.ScriptAnalyzer.<>c__DisplayClass84_1.<AnalyzeSyntaxTree>b__2()
   

   There's also a second symptom: most of the time, the pwsh process doesn't exit after this error. It hangs forever at about 0% CPU, even when the script catches the error. That's how we noticed it: a pre-commit hook running Invoke-ScriptAnalyzer on two files (a .ps1 and a .psm1 with Export-ModuleMember -Function ...) hung intermittently.

   Out of 15 runs of pwsh -NoProfile -NonInteractive -CommandWithArgs '$ErrorActionPreference = "Stop"; foreach ($path in $args) { Invoke-ScriptAnalyzer -Path $path }' a.ps1 b.psm1:

   • 7 were clean
   • 1 failed with the NullReferenceException
   • 7 printed the NullReferenceException and then hung (killed after 30 s)

   With -ExcludeRule PSProvideCommentHelp, PSReservedCmdletChar, 30 of 30 runs were clean.

   Why it hangs:

   • In the hung process, the main thread has returned from Main and is in ThreadStore::WaitForOtherThreads, so the runtime is waiting for foreground threads. The only threads left are the TP gate, timer, sockets and IPC threads plus two Pipeline Execution Threads.

   • Those are the worker threads of the runspaces in CommandInfoCache's runspace pool. A pool runspace uses PSThreadOptions.ReuseThread, and its PipelineThread is a foreground thread.

   • Normally they end when the primary runspace closes and disposes all other open runspaces. After the race, though, one pool runspace is left Busy with a Get-Command pipeline still Running (from Get-Runspace in the same process right after catching the exception):

     Id           : 3
     State        : Opened
     Availability : Busy
     Running      : Running Get-Command
     

     That pipeline never completes, so its thread keeps the process alive. CommandInfoCache is never disposed, and ScriptAnalyzer.CleanUp() doesn't dispose it either.

   This fits the analysis above: GetMergedCommandParameterMetadataSafely runs the metadata lookup on the rule's thread against the pool runspace's ExecutionContext when that runspace looks idle, and it dispatches through the engine event when the runspace is busy. Neither path is safe while other rule threads use the same runspace for Get-Command.

   #2206 replaces the ResolveParameter call in GetExportedFunction, but it's a large change. A minimal fix for this call site alone: Export-ModuleMember has no dynamic parameters, so its static metadata can be used without touching any runspace.

   -            CommandInfo exportMM = Helper.Instance.GetCommandInfo("export-modulemember", CommandTypes.Cmdlet);
   +            // Export-ModuleMember has no dynamic parameters, so its parameters are taken from the static
   +            // metadata of the cmdlet. CommandInfo.ResolveParameter() would use the runspace the cached
   +            // CommandInfo comes from, which races with the other rules running in parallel.
   +            List<ParameterMetadata> exportMMParams = ParameterMetadata.GetParameterMetadata(typeof(Microsoft.PowerShell.Commands.ExportModuleMemberCommand)).Values
   +                .Concat(ParameterMetadata.GetParameterMetadata(typeof(CommonParameters)).Values).ToList();
   
                // switch parameters
   -            IEnumerable<ParameterMetadata> switchParams = (exportMM != null) ? exportMM.Parameters.Values.Where<ParameterMetadata>(pm => pm.SwitchParameter) : Enumerable.Empty<ParameterMetadata>();
   -
   -            if (exportMM == null)
   -            {
   -                return exportedFunctions;
   -            }
   +            IEnumerable<ParameterMetadata> switchParams = exportMMParams.Where<ParameterMetadata>(pm => pm.SwitchParameter);
   ...
   -                        var param = exportMM.ResolveParameter(paramAst.ParameterName);
   +                        var param = ResolveParameter(exportMMParams, paramAst.ParameterName);

   Here ResolveParameter is a small helper that matches the parameter's name or alias, or else a prefix of only one of them, like the parameter binder does. With this change, 100 runs in a row of the command above were clean (before, about half failed or hung). The findings of PSProvideCommentHelp are unchanged for the different forms of Export-ModuleMember (-Function, -Fun, -Function:x, positional, after -ErrorAction/-ea, -Verbose/-vb, -Alias, -Variable).

   If that would help in the meantime, I can open a small PR with just this fix, independent of #2206.