Progress Bar problems with Remove-AppxPackage

[RobMahn]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

This script will demonstrate the problem by removing and re-installing the Calculator app. (It requires Administrator privileges to be able to re-install the app.)
BugInRemove-AppxPackage.zip

The work-around to re-displaying the progress bar is to run the cmdlet in a new shell. e.g.
$Env:AppxPackageName = $AppxPackage.Name
. (Get-Process -Id $PID).Processname -Command 'Get-AppxPackage $Env:AppxPackageName | Remove-AppPackage'

Expected behavior

The progress bar should honor the ProgressPreference and never re-display after the cmdlet completes.

Actual behavior

Remove-AppxPackage does not honor $ProgressPreference = 'SilentlyContinue'.

Then, the progress bar is re-displayed and remains in view if the command is followed by [System.Console]::ReadKey().

These are probably two seperate bugs, but tied closely together.

Error details

No response

Environment data

The problem exists in V5.1 and V7.3.1

Visuals

No response

[RobMahn]

I previously tried calling "Write-Progress - Activity 'dummy' -Complete" and that did not work. I also tried creating a new progress bar and clearing it, but the old progress bar remained.

I also tried using pause right after the call and that did not protect the next ReadKey, which I was using to make a menu selection. The menu display was trashed.

BTW, thanks for the better code idea, now using:
. (Get-Process -Id $PID).Processname { $args[0] | Remove-AppPackage } -Args $AppxPackage

[mklement0]

Let's try to narrow this down:

• With direct calls, doesn't setting $global:ProgressPreference = 'SilentlyContinue' solve your problem?

It is plausible that the implicit remoting involved in direct calls to (the proxy commands for) the AppX module thwarts the Write-Progress - Activity 'dummy' -Complete workaround. (I haven't tried, given that you shouldn't expect others to download source code just to reproduce your symptom).

[RobMahn]

Let's try to narrow this down:

• With direct calls, doesn't setting $global:ProgressPreference = 'SilentlyContinue' solve your problem?

It is plausible that the implicit remoting involved in direct calls to (the proxy commands for) the AppX module thwarts the Write-Progress - Activity 'dummy' -Complete workaround. (I haven't tried, given that you shouldn't expect others to download source code just to reproduce your symptom).

I just tested $global:ProgressPreference = 'SilentlyContinue' and it does prevent the progress bar from appearing. I looked in the documentation and saw nothing about when to specify global preference variables. I did find this came up over 3 years ago in https://github.com/PlagueHO/CosmosDB/issues/308.

The script that I submitted was specifically written to demonstrate the problem and short enough to examine before running. The problem does not present itself outside of a script and describing how to write the script seemed too cumbersome. But I understand your reluctance, especially with the Administrator requirement to replace the deleted app.

[mklement0]

First, a meta comment:

• I dug deeper, and realized that I had some misconceptions and that some of what I suggested wouldn't help.

  • Notably, I found $global:ProgressPreference = 'SilentlyContinue' not to be effective: while the point about script modules only seeing preference variables if they're defined in the global scope is correct (see Need straightforward way to honor the caller's preference-variable values / inherited common parameters in functions defined in script modules #4568), it seems that the additional factor of implicit remoting being involved makes the workaround ineffective.
  • I think it is due to the fact that the progress display must be silenced at the source, and the automatically generated local proxy script module makes no attempt to pass the local value on.
    • This may be worth reporting as a separate bug.
  • On a side note, a -ProgressAction common parameter is coming (though it wouldn't help here): see Add -ProgressAction common parameter #18887

• I've hidden my previous comments and will post a - hopefully now correct - summary below.

• It is commendable that you prepared detailed code to demonstrate the problem, but to make it easier for others to run it, please in general add it directly to your post, not as an attachment, ideally in the form of a minimal example.

[mklement0]

The root problem is that the Appx cmdlets apparently do not call Write-Progress -Completed (or make an equivalent .WriteProgress() method call, given that they are binary cmdlets) in order to remove the progress bar on completion, which means that PowerShell will eventually hide the progress bar automatically, but not until after the script at hand has terminated.

• As such, the problem should be reported against the Appx module, which is not maintained in this repo. The module's doc page has a "Feedback" section that suggests the Feedback Hub app should be used.

• Given that properly removing a progress bar isn't enforced by syntax / tooling, the problem is likely to affect other modules as well.

In your case, since you're using an interactive feature that delays completion of the script - [Console]::ReadKey() - the progress bar lingers at that point.
(Interactive features provided by PowerShell - such as pause - may mask the problem, because they temporarily hide a progress bar, but they actually restore it afterwards).

As for workarounds:

• Silencing the progress display altogether with $ProgressPreference = 'SilentlyContinue' is normally an option, but not in this particular case, given that the Appx module is loaded via the Windows PowerShell Compatibility feature, which involves implicit remoting via a proxy script module that is generated on demand, and this module seemingly does not relay the preference, even if set globally (which script modules in general require, unfortunately (see Need straightforward way to honor the caller's preference-variable values / inherited common parameters in functions defined in script modules #4568)) - see Implicit-remoting modules, at least as used by the Windows PowerShell Compatibility feature, do not honor $ProgressPreference #19063

• However, the workaround you came up with - calling via a child PowerShell process, using PowerShell's CLI - is effective, and even allows you to choose to display the progress bar, relying on the fact that the PowerShell child process automatically hides it on exiting:

  • In this case, given that Windows PowerShell is ultimately called anyway, the workaround can be optimized by always calling powershell.exe. Aside from paying a performance penalty (if you call more than once), no functionality is lost.

    # With progress display
    powershell.exe -NoProfile { Get-AppxPackage $args[0] | Remove-AppPackage } -args $AppxPackage.Name
    
    # Without progress display
    powershell.exe -NoProfile { $ProgressPreference = 'SilentlyContinue'; Get-AppxPackage $args[0] | Remove-AppPackage }  -args $AppxPackage.Name

  • Generally, in cases where implicit remoting is not involved by default, a CLI-based workaround comes with potential loss of type fidelity, however (a price you invariably pay when implicit remoting is involved). That said, you only need a CLI-based workaround in the absence of remoting if you want to show (and hide in a timely fashion) the progress bar; to silence it, setting $ProgressPreference = 'Continue' is sufficient ($global:ProgressPreference = 'Continue' for commands from script modules).

  • Hiding another command's lingering progress bar on demand with Write-Progress -Activity 'unused' -Completed works only if the progress bar was put up from PowerShell code with Write-Progress too and without using an -Id argument (or if you happen to know the -Id value that was used and use it too, but that seems unlikely).

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.

[RobMahn]

Thank you for that detailed resolution. I have reported this problem on the Feedback Hub as "Remove-AppxPackage does not close the progress bar".