Protected Event Logging is breaking execution

[chelnak]

Both DSC resources and anything with a provider => powershell is immediately erroring out with errors as follows:

#<Thread:0x0000000005efc6a8@C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:587 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
        1: from C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:589:in `block in read_streams'
C:/ProgramData/PuppetLabs/puppet/cache/lib/pwsh.rb:589:in `sysread': end of file reached (EOFError)

See Slack thread for more discussion and a link to the ZenDesk ticket.

[chelnak]

I'm not having much success with the repro for this issue.

The following image shows some basic info from my test rig.. You can see that applying test.pp works with no issue:

Also Protected Event Logging is enabled and encrypting events as expected:

The main thing that perplexes me right now is how the encryption of the logs is correlated with the output of the PowerShell provider.

[cummingscody]

Attaching docs and further info from customer...

Also, this is coupled with the GPO "Turn on PowerShell Script Block Logging" set to "Enabled". In testing I've found that the errors don't occur if "Protected Event Logging" is enabled, but that policy is not.

[chelnak]

Great news! That extra info helped me replicate the issue 😄

[chelnak]

Fixed in #189

For each run we reset the session environment to a last known good state. We did this by removing all environment variables, then re-setting them from a cached set we took at the start of the run.

It appears that when ScriptBlock Logging and Protected Event Logging are both enabled, removing the SystemRoot environment variable from the current session causes PowerShell to crash.

I'm unclear at this time what the dependency is but suspect that there is a process that is consuming $env:\SystemRoot when building a path to an executable.

I was able to replicate by manually invoking init.ps1 with a custom name and redirecting pwshlib to the new pipe. Once you do this you can see the whole error message. It talks about a missing environment variable...

A bit of trial and error narrowed it down to SystemRoot.

#189 fixes the issue by filtering out SystemRoot from the list and only removing the remainder.

The questions remaining for me are:

1. When the two settings are combined, what causes the dependency on SystemRoot?
2. Would it be better to scope the filtering to only happen when the two settings are both enabled?