The explorer process could not be killed, because powershell cannot convert the "Explorer.exe" value of type "System.String" to type "System.Diagnostics.Process".
Description and solution in #240 . If issues still occur we could try the solution proposed in #259
- GUI previously not display
- Style of some code updated to reflect body and readability
- Updated the `string` types within double-quote to be within curly braces for interpreter
DebloatAll whitelisted XBox apps since a lot of home users
want to play games. So, I added ALL of the XBox items to
the whitelist. Seems reasonable to me.
The blacklist removed several XBox components (since it
ignores the whitelist). Since some XBox components are
being removed, I added ALL of the XBox items to
the blacklist. Seems reasonable to me.
Or alternatively all XBox apps should be removed from
one of the lists, right?
I also confirmed that both GameOverlay and GamingOverlay
are both valid/installed in 1809.
This ESPECIALLY helps during a second run of the removal script,
where the result is almost instantaneous. Instead of
initializing the Remove-AppxPackage routine N times,
it only needs to do it once.
The downside is that we can't control feedback to the user on
the progress - and users frequently complain about hung
processes etc. There is SOME feedback coming from the
Remove-AppxPackage process - hopefully that will be enough.
I also ensured that -AllUsers packages were removed,
which was not done previously. If there was a reason for
NOT removing -AllUsers for the blacklist, then it can
be removed, but the DeBloat All function does remove
it, so to be consistent it seemed best to do the same here.
In terms of $NonRemovables - I had just added that but
on second thought, let the user be smarter than the computer.
The user now has the tools to detect if there are
conflicts with nonRemovables, so if they choose to
try to remove it anyway, don't prevent that.
The computer might be lying after all...
At least as far as I can see. Microsoft.Paint is the appx name for
Paint3D. I often confuse it with Microsoft.Print3D, and perhaps
that is what has happened here as well.
