[Windows]PowerShellScript resources hampered by use of HadErrors

[JohnMcPMS]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Summary

Due to longstanding issues with HadErrors (PowerShell/PowerShell#4613) and the [Windows]PowerShellScript resources use of HadErrors

DSC/resources/PSScript/psscript.ps1

Lines 148 to 152 in aa3e331

	if ($ps.HadErrors) {
	# If there are any errors, we will exit with an error code
	Write-DscTrace -Now -Level Error -Message 'Errors occurred during script execution.'
	exit 1
	}

after invoking any of the scripts, it is difficult to implement some patterns with these resources. It is even more difficult to diagnose them, as you get back only a generic "it failed" message. Manually running the script will not expose the issue obviously unless you already know about the problem (you must remove any -ErrorAction that is intended to make a call into a "try").

I certainly don't know enough about the PS model to strongly suggest how to do this, but the answer feels like implementing an externalized version of the suggestion to have a HadTerminatingErrors property. Maybe just checking the state of $Error instead of HadErrors would be a better mechanism? If the user decides to $Error.Clear() in their script, it seems reasonable to treat that as success. That of course also allows the use of -ErrorAction values that prevent the update of $Error in the first place.

Steps to reproduce

# test.yml
$schema: https://aka.ms/dsc/schema/v3/bundled/config/document.json
resources:
  - name: TestHadErrors
    type: Microsoft.DSC.Transitional/PowerShellScript
    metadata:
      description: Install and default the stable Rust toolchain via rustup
    properties:
      getScript:
      testScript: |
        return [bool](Get-Command this-command-is-fake -ErrorAction SilentlyContinue)
      setScript:

> dsc config test -i test.yml

Replacing this-command-is-fake with an existing command produces a successful test (and in the desired state).

Expected behavior

The resource is able to execute the test without issue, returning a "not in desired state" result.

Actual behavior

> dsc config test -f test.yml
2026-05-28T17:54:23.691113Z ERROR PID 57844: Errors occurred during script execution.
2026-05-28T17:54:23.819646Z ERROR Failed to run process 'pwsh': Command: Resource 'pwsh' [exit code 1] manifest description: PowerShell script execution failed
2026-05-28T17:54:23.823655Z ERROR Command: Resource 'pwsh' [exit code 1] manifest description: PowerShell script execution failed

Error details

Environment data

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.6.2
PSEdition                      Core
GitCommitId                    7.6.2
OS                             Microsoft Windows 10.0.28581
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.4
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

3.2.1

Visuals

No response

[SteveL-MSFT]

I guess the question is whether it makes sense to expose a ErrorAction type property to control this or just not check HadErrors since in the real world things are never clean?

[michaeltlombardi]

I think we can safely consider the resource to have failed when $ps.InvocationStateInfo.State is Failed - that holds for any terminating error in the script, where HadErrors is $true when any error is raised, even when you use -ErrorAction Ignore or place a statement you expect to fail in a try/catch block.