Solved Major issues with native boot vhdx after installing 22631.4602 CU (KB5048685)

As some of you may know, I muti-boot using native boot vhdx, mostly various Insider builds. but I also have vhdx for Win10 and RTM Win11. I have three machine set up for this, my (unsupported) System Two with 24H2 as its conventional OS, System Four (unsupported) with Windows 10, and my supported System Five on 23H2 (see My Computers > Other Info for the last two). All of them got their respective cumulative updates on Patch Tuesday. Two out of the three work normally after the updates. My 23H2 system has major issues when booting to a vhdx after the update to 22631.4602.

When booted to any one of the available vhdx I have no keyboard, no touchpad, and no sound. The only way I can interact with Windows is through the touchscreen. That on its own is a major inconvenience, but not insurmountable. What is worse is that I am locked out of using anything but the built in Microsoft apps, nor am I allowed to open Windows Security. This is the case regardless of which OS I choose to boot. The only one that works normally is the conventional install of 23H2.

Attempting to open a non-Microsoft app like Firefox, or to open Windows Security is greeted with the statement that "Your organisation used App Control for Business to block this app". I repeat, this applies whichever vhdx I boot.



That is apparently part of Intune. As I only ever use a local account I cannot see how it possibly applies to me.

Intune's App Control for Business policies are part of endpoint security and use the Windows ApplicationControl CSP to manage allowed apps on Windows devices.

Click to expand...

I must emphasise, none of this is in any way a problem in any of the vhdx OS's, they are all affected the same way. It is the main Windows 11 23H2 22631.4602 that seems to be applying the policies to any and all of the vhdx when it boots them. To confirm that I have restored a system image of its previous 22631.4460 (KB5046633) and all the vhdx are back to working normally again. In fact, I'm typing this in Firefox on the Canary build vhdx, passing the time while it installs the 27764.1000 feature update. Windows update says it's 95% installed, so I'll have to stop typing and reboot shortly....

Just curious.... do you use a license from one of those discount Windows key places? Blink once for yes, twice for no.

Edit: This is from a couple days ago. Search for the Known Issues section. Previewing More Copilot+ Experiences with Windows Insiders in the Dev Channel

pseymour said:

Just curious.... do you use a license from one of those discount Windows key places? Blink once for yes, twice for no.

Click to expand...

No.

My Dell Latitude 3190 2-in-1 is second hand. When I bought it I gave it a clean install of Windows 11 Pro, using the generic *-3V66T key. That activates from an existing digital licence, which it originally obtained (before I owned it) from the OEM key embedded in the firmware, a Win10 Pro Education key. Similarly, all the native boot vhdx OS's have the Pro generic key and activate from the PC's digital licence.

My other 2-in-1 that multi-boots vhdx, an unsupported Lenovo Yoga 11e 20DA, has a similar purchase and install history, except that it had a clean install of Windows 10 Pro, and its digital licence came from its OEM embedded key for Windows 8.1 Pro, back when MS were still giving out the free upgrades.

pseymour said:

Edit: This is from a couple days ago. Search for the Known Issues section. Previewing More Copilot+ Experiences with Windows Insiders in the Dev Channel

Click to expand...

I don't see the relevance. None of my machine have the NPU required to use Copilot+ (or meet the 16GB minimum RAM specs).

Hi @Bree, I am a bit confused as you have a lot of devices at different host os etc.

I cannot see the woid for the trees.

As far as I can tell your vhdxs fall over if host is on 23H2 22631.4602?

It is not clear to me how vhdx files were created e.g. were they created in hyper-v first, then a native boot added.

Alternatively did you clone host OS to vhdx files or clean install to vhdx etc.

What is puzzling is why vhdx should fall over if host is updated.

Lets start with one case and I will see if I can repeat your issues.

There are changes in the new builds that are not related to Copilot.

cereberus said:

Hi @Bree, I am a bit confused as you have a lot of devices at different host os etc.
I cannot see the woid for the trees.
As far as I can tell your vhdxs fall over if host is on 23H2 22631.4602?

Click to expand...

Yes, that is correct. Before Patch Tuesday all the vhdx would behave normally on this particular PC with 23H2 as the main OS, after the PT update to 22631.4602 any vhdx I tried would be restricted by App Control for Business. Restoring last month's system image of 22631.4460 restored normal behaviour in each vhdx.

The two other multi-boot PCs, one on 24H2 and the other on Win10 had no such issues after their PT updates. The significant difference, besides the base OS, is that the PC with the problem is a supported device, while the two without are legacy bios/MBR. Hence the two without issues do not have secure boot.

cereberus said:

It is not clear to me how vhdx files were created e.g. were they created in hyper-v first, then a native boot added.
Alternatively did you clone host OS to vhdx files or clean install to vhdx etc.

Click to expand...

From various sources. This PC is my most recent of the three, the Dev and Canary vhdx's were copied from one of the others. The Win10 vhdx was created with Disk Management, then a system image from one of my other PCs was restored to it. I'm not sure their origin is relevant though, all we being restricted.

cereberus said:

What is puzzling is why vhdx should fall over if host is updated.
Lets start with one case and I will see if I can repeat your issues.

Click to expand...

Puzzles me too. Something changed/updated in the host machine's efi partition? As I said, the two unaffected machines are using a different base OS, and are Legacy/MBR.

Now I have got my vhdx all working again, and have finished updating them all, my next step should be to update the base OS from 22631.4460 to 22631.4602 again. If it has no problems this time then it was a 'one off' quirk. If it is repeatable, then I can see if turning off secure boot makes any difference.

Now here's an interesting twist. With secure boot turned off and the PC's main OS still on 22631.4460, booting to the vhdx for 24H2 RTM and updating to 26100.2605 triggered App Control for Business for just that one vhdx, all others still working freely. Uninstalling KB5048667 restored unrestricted use to the 24H2 vhdx.

Bree said:

booting to the vhdx for 24H2 RTM and updating to 26100.2605 triggered App Control for Business for just that one vhdx, all others still working freely. Uninstalling KB5048667 restored unrestricted use to the 24H2 vhdx.

Click to expand...

I'm now testing installing the standalone updates from the MS catalog, first November's preview update for 24H2: windows11.0-kb5046617-x64.msu. 'App Control for Business' was enabled again. I restored an earlier (working) version of the 24H2 vhdx. This time I disconnected from the internet while installing December's Patch Tuesday update windows11.0-kb5048667-x64.msu. Again, App Control for Business was back.

@Bree,
I had the same issue.
This problem originates from the latest Dev build and is passed on to other versions.
Unlike you, I natively boot Dev & Canary by switching using a Macrium image and updating as needed.
On the problem system(s) do this: (elevated)

(.cip files are Code Integrity Policy files)
Reboot & try again. Do this for each OS that behaves that way. If the message reports no files or something similar, that system is OK.

(known issues)

"There is an issue where if you roll back from Build 26120.2510 to Build 26120.2415, you will see an “Your organization used App Control for Business to block this app” dialog when attempting to use or install certain third-party apps on your PC due to an incorrect policy being enforced.
If you do not do these steps FIRST before rolling back, your PC could get into a bad state. If you run into issues with Build 26120.2510, we recommend trying the option “Fix problems using Windows Update” via Settings > Recovery which delivers an in-place upgrade (IPU) of Build 26120.2510 instead of rolling back. We expect to have this issue fixed with the next Dev Channel flight."

You are being warned about roll backs but NOT about switching between OS builds.

OAT said:

@Bree,
I had the same issue.
This problem originates from the latest Dev build and is passed on to other versions.
On the problem system(s) do this: (elevated)

Click to expand...

Thank you, I thought this issue might be unique to my specific PC. I'll try that ASAP.

OAT said:

I had the same issue.

Click to expand...

I can now say that I had the issue (with the emphasis firmly on the past tense).

OAT said:

(.cip files are Code Integrity Policy file)
Reboot & try again. Do this for each OS that behaves that way.

Click to expand...

The instructions mount the EFI partition and delete certain policies there. I said in post #7 I suspected the EFI partition...

Bree said:

Puzzles me too. Something changed/updated in the host machine's efi partition? As I said, the two unaffected machines are using a different base OS, and are Legacy/MBR.

Click to expand...

...and the two others being Legacy/MBR were immune from this bug.

You do realise the implications of this? It means that everyone who has a UEFI/GPT machine running either 23H2 or 24H2 and has installed the Patch Tuesday updates will now have these rogue policies in their EFI partition? I know for a fact that it's in 23H2 as well, as I also said in post #7 that 23H2 was this PC's main OS...

Bree said:

Before Patch Tuesday all the vhdx would behave normally on this particular PC with 23H2 as the main OS, after the PT update to 22631.4602 any vhdx I tried would be restricted by App Control for Business. Restoring last month's system image of 22631.4460 restored normal behaviour in each vhdx.

Click to expand...

Bree said:

I can now say that I had the issue (with the emphasis firmly on the past tense).

Click to expand...

Sadly, I had just seen your thread as I have been a bit busy, otherwise I would have been able to jump in earlier.
I bet you must feel a bit better now.

Not to contradict you but this did not come with the Tuesday patch, it came from the latest Dev CU.
I experienced the issue last week and was fortunate to have read the known issues from the release.

pseymour said:

Just curious.... do you use a license from one of those discount Windows key places? Blink once for yes, twice for no.

Edit: This is from a couple days ago. Search for the Known Issues section. Previewing More Copilot+ Experiences with Windows Insiders in the Dev Channel

Click to expand...

Funny, the instructions and link posted by OAT are the same thing I posted yesterday.

pseymour said:

Funny, the instructions and link posted by OAT are the same thing I posted yesterday.

Click to expand...

Indeed. Sadly, that must have been missed.
I didn't even notice the link until you pointed it out now.

pseymour said:

Funny, the instructions and link posted by OAT are the same thing I posted yesterday.

Click to expand...

My apologies. I'm sorry but I didn't realise so at the time. It just didn't register that this was the cause of my issues. Please accept my retrospective thanks.

Please hang on every word I say from now on. :) j/k it's all good mate

OAT said:

Not to contradict you but this did not come with the Tuesday patch, it came from the latest Dev CU.
I experienced the issue last week and was fortunate to have read the known issues from the release.

Click to expand...

It did come with the 24H2 Patch Tuesday CU for me. See my posts #7 & #9 where installing kb5048667 would cause the issue, and uninstalling it would remove it. At no time during those tests was I booting to any other vhdx than my RTM 24H2 one. And it was while booted in the 24H2 RTM vhd that I applied the .cip fixes.

I was mistaken about 23H2 though, I've now restored the system image of this PC's 23H2 primary OS made just after the PT update and have no issues in any of the vhdx. It must have somehow spilled over from my Dev build vhdx some time past.

I'm marking this as solved now that I have all my vhdx boots back to normal working order. Thanks everyone I couldn't have done it without you.

Hi all, I created an account to reply to this post.

On the morning of 13-DEC-24 (+10 GMT), Windows 11 Canary Build 27764 (also occurred with the previous Canary build), I also had this issue. Microsoft Support refused to help, saying to either log out of all work/school accounts, and/or contact work/school IT department, or pay over $300 for Business support . Unfortunately, I am logged into FOUR work/school accounts on my personal machine

I can confirm that the fixes in this post worked for me on my machine. Thank you for providing the instructions. Now I can get on with my life

For anyone wondering, here are the steps I took (formatted by Copilot):

------------

The solution to the issue described on the page involves deleting certain Code Integrity Policy (.cip) files from the EFI partition. Here are the steps provided:

1. Open an elevated Command Prompt.
2. Mount the EFI partition by running the command:

mountvol s: /s

Click to expand...

3. Delete the specific .cip files by running the following commands:

del S:\EFI\Microsoft\Boot\cipolicies\active\{36D62F7C-AB85-4F61-8724-744294F24023}.cip
del S:\EFI\Microsoft\Boot\cipolicies\active\{8E8A94F0-6EB9-42C7-A189-E018C8CF3D10}.cip
del S:\EFI\Microsoft\Boot\cipolicies\active\{66D7D265-7EDD-47DD-86E4-F7C42CD55A8F}.cip

Click to expand...

4. Reboot the system and try again.

This should resolve the issue with App Control for Business policies affecting the VHDX files.