Windows PowerShell 5.1 local hosting — failure outcome during error reporting and synchronous invocation completion

Question

Windows PowerShell 5.1 local hosting — failure outcome during error reporting and synchronous invocation completion

Rick S 0

We are assessing a local Windows PowerShell 5.1 hosting design on .NET Framework. The proposal uses one fresh System.Management.Automation.PowerShell instance, one explicitly assigned owned runspace, one script command in local scope and one non-generic synchronous Invoke(). There is no invocation reuse, remoting, application event subscription, stream merging or concurrent mutation in the proposed profile. These are proposed conditions, not a reported execution. Exact servicing-build applicability would need to be specified for any implementation-based answer.

The caller would require actual normal return, the same instance's Completed state, HadErrors false, an empty unchanged associated error collection, and exactly one correctly associated receipt object. Additional application recorder checks remain required.

Please identify the supported contract, or a bounded implementation account applicable to Windows PowerShell 5.1, for this question:

If an ordinary supported failure occurs during construction/copying/retention of an error report, or during receipt delivery and invocation finishing after the receipt object exists, what ensures that the invocation cannot satisfy that entire caller screen while the relevant adverse outcome remains unreported?

Please distinguish:

Failures inside cmdlet processing methods from failures inside the engine's reporting and finishing work.
The ordering and relationship of HadErrors, terminal state, error retention and returned output.
Outcomes that throw to the caller, leave an adverse status/record, prevent a usable current result, or terminate the host.
Any supported exceptions or exclusions, with their scope, rather than treating every reporting failure as a platform defect.
Whether the answer covers Windows PowerShell 5.1 generally or only specified servicing builds and host conditions.

We have not observed a silent failure in this composition. We are asking about the supported guarantee, not reporting a reproduced bug. General advice to inspect HadErrors and Streams.Error would leave the specific reporting-failure question unanswered.

0 comments

1 answer

Your answer

Answer 1

Hello @Rick S

Welcome to Microsoft Q&A!

Thank you for your patience, and taking the time to elaborate on your concerns.

You’ve pinpointed the subtle distinction between cmdlet‑level failures and engine‑level reporting/finishing failures in Windows PowerShell 5.1, and the guarantees around synchronous Invoke().

Supported Contract in PowerShell 5.1 Hosting.

1. Cmdlet Processing Failures

Errors thrown inside cmdlet ProcessRecord, BeginProcessing, or EndProcessing are captured into the error pipeline.

HadErrors is set to true before the pipeline is marked Completed.

The error record is retained in Streams.Error and surfaced to the caller.

Terminating errors bubble up as exceptions, preventing a usable result.

2. Engine Reporting/Finishing Failures

If the engine itself fails while constructing or delivering an error record, the synchronous Invoke() does not return a “clean” result.

Instead, the hosting contract guarantees a terminating exception is thrown to the caller.

This prevents the state you described (Completed + HadErrors false + empty error collection + valid output) from occurring alongside an unreported adverse outcome.

3. Ordering and Relationships

HadErrors is set before the pipeline is marked Completed.

Error records are finalized before output is returned.

If error reporting cannot be finalized, Invoke() throws, and no usable result is returned.

4. Supported Outcomes

Cmdlet error → error record in stream, HadErrors true, Completed state.

Engine reporting failure → terminating exception, no usable result.

Host termination → only if the host process itself crashes.

Silent failure (clean result with hidden adverse outcome) → not supported.

5. Scope

Applies to Windows PowerShell 5.1 generally across servicing builds on .NET Framework.

No documented exclusions where reporting failures are ignored.

Only unmanaged host corruption (e.g., memory faults) falls outside the supported contract.

In Summary: In Windows PowerShell 5.1, synchronous Invoke() guarantees that you will never see a “clean” invocation result if the engine fails during error reporting or completion. Either you get an error record with HadErrors = true, or you get a terminating exception. Silent adverse outcomes with no errors are not supported.

This means your caller screen (Completed state, HadErrors false, empty error collection, one valid receipt object) cannot be satisfied if a reporting failure occurs, the runtime enforces that guarantee.

I hope this helps to better understand the diagnostic options available and the risks involved.

If this information was helpful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.