Sandbox severely cripples the host (24H2)

[m33ts4k0z]

A lot of trial and error since the release of 1.4.9. Latest findings are that installing the dependencies of sandbox, practically destroys the host. At least on 24H2. This is tried on a clean win11 24h2 installation.

A lof of bugs are happening:

• Can no longer go to Windows Update, the button at the top right corner of the dashboard does nothing when clicked. I havent found any other way to get to the Windows Update either.
• The Apps settings menu is missing a lot of submenus like installed apps and these menus are no longer accessible by other means.
• System restore no longer works. It shows an "unsuccessful" error uppon restarting and the host shows black screen after login screen.
• PC reset while keeping personal files or clean wipe doesnt work. the issues persist even after successfully reseting the PC.
• Display settings menu is gone. No way to open it.
• No Windows account can be created.

I will update this post with new findings but this already makes 1.4.9 unusable.

[Black-Seraph]

I can't confirm any of your crippling claims locally on a 24H2 install, all the menus you mention as broken open just fine on my end.

I will setup a new local test machine soon to see if I can recreate your issues there.

[m33ts4k0z]

I tried a total format again and reinstallled Win 11 Pro with 24H2 and then Duo 1.4.9 both on bare metal as well as inan Unraid VM. The behavior I described is very consistent in both cases.

[Black-Seraph]

I had leftover 23H2 files in my system, which is why this worked on my system.
I can confirm that clean 24H2 installs will not work with Duo's Run in Sandbox setting yet.

I'll close this issue for now as I already know what the issue is and what needs to be done, and because I'd like to keep discussion of this 24H2 regression in a single issue, if possible.

For those adventurous enough, you can transplant a recent enough 23H2 madrid.dll file into a 24H2 install and it will work somewhat, but I don't suggest it.

Instead, keep an eye on issue #165, which will serve as a list of pending to-dos to undo the damage Microsoft has done with 24H2.

PS. Even on a fresh 24H2 install I can't simulate your UI crippling effect.
Sure, Run in Sandbox doesn't work there yet, but the UI isn't getting crippled by the installer on my end.

[Black-Seraph]

Reopening this issue because I can now confirm this on one of my machines.
@m33ts4k0z This is the strangest thing ever...

[m33ts4k0z]

What exactly surprises you? Did you for any second forget its Microsoft you are dealing with here? 😂

Really this could very well be a bug on their end or a change in behavior in one/some of their packages?

I guess finding out which package causes it isnt that hard here. Perform a format and start installing each package while restarting in between.

Then how to solve it could be another topic 😅

[Black-Seraph]

I found the cause of this issue but I can't quite explain it.

It's essentially Windows choking on its own Windows Update packages, which breaks its whole App & Update catalog.

And because Duo enables a bunch of Windows Update packages as part of its setup we now have affected Windows versions showing this behavior.

Manually ejecting these packages from the Windows Update package catalog fixes this issue, but because we need these packages we're now stuck in somewhat of a dilemma.

Here's how to purge these packages from the catalog, bringing the missing menus back:

1. Execute the following in an administrative command line:
   dism.exe /online /disable-feature /featurename:Containers-DisposableClientVM
2. As part of this action you'll have to reboot your computer, do so.
3. Execute the following in an administrative command line:
   dir /b %SystemRoot%\servicing\Packages\*Containers*.mum >sandbox.txt
for /f %%i in ('findstr /i . sandbox.txt 2^>nul') do dism /online /norestart /remove-package:"%SystemRoot%\servicing\Packages\%%i"
del sandbox.txt
4. Reboot the computer one last time, the missing menu points will be back afterwards.

Now I need to figure out how we can get these packages enabled without Windows choking on its own stuff.

[m33ts4k0z]

Apart from sandbox, there is really no need to use 1.4.9 so if you are on 24H2, just stay on 1.4.8 till these issues are resolved. 23H2 has no issues with sandbox/1.4.9 though.

[m33ts4k0z]

@Black-Seraph Something else that I noticed, is that sometimes, Duo 1.4.9 doesnt "see" that the dependencies are installed. Not even after restart. This occured on the preview version of 24H2 as well as once more randomly between the 10 formats that I performed with the release version.

Its not something that is a priority fix but I wonder if it has to do with the windows update package problems you mention.

[Black-Seraph]

@m33ts4k0z The dependency issue comes from the fact that the sandbox API lived in madrid.dll all the way up to 24H2, where it was absorbed directly into WindowsSandbox.exe.

Because the installer uses madrid.dll as a landmark to detect if the install of the dependencies succeeded, this will throw false negatives on 24H2.

This is something we'll have to fix as part of the reverse-engineering efforts of this issue.
We will probably move the check to the sandbox template file instead, which still does exist on 24H2.

I also noticed that the fix I've posted won't take effect until all pending Windows updates have been completed.
That means should one find that the commands above didn't fix the issue, one has to open the start menu, click the shutdown button and choose "Shutdown and restart" so that Windows can get its stuff back in order.

[m33ts4k0z]

Thanks for the explanation. Makes perfect sense.

So to recap. Apart from the effort needed to reverse engineer the new dll that has absorbed the madrid.dll functionality, we still need a way to make the sandbox packages to co-exist in a 24H2 system because what the commands you posted do, is to remove them so that the system works correctly again. Is that correct?

[Black-Seraph]

The commands I've posted are only there to buy 24H2 users time until I address this issue fully in Duo version 1.5.0, and they're only there to get the system back into a fully working state after Windows choked on its own packages that Duo's setup enabled in the package catalog.

I've done some more research since then and found that the issue is that Windows caches older versions of the package metadata in C:\Windows\servicing\Packages.

This causes multiple versions of the same package to get enabled as part of Duo's setup, which then causes Windows to fail on parsing the available package list.

This should be avoidable by adding a LCU-version tag to the setup's package filter, so there goes one problem.

The next problem is that 24H2 further splits up the Sandbox files across multiple features.

Part of the files are stored in the DisposableVM packages, some in the UtilityVM packages, some more in the HyperV packages and the last bits in the WindowsDefenderApplicationGuard packages.

In versions prior to 24H2 these could all be pulled in simply by enabling the DisposableVM feature, on 24H2 we need to do all that explicitly.