Announcing Windows 10 Insider Preview Build 16215 PC + 15222 Mobile Insider

HippsieGypsie said:

I've been watching your progress, Marty. You get an A+ for the attempt. :)

I'm sure MS knew within hours of the release that it was a disaster.

Well thanks. I always learn something after each failure. I now know (and will report to the Feedback Hub) that build 16215 simply cannot handle any kind of multiboot setup.

Dora:

I can understand why you aren't providing us any explanations about 16215 but for crying out loud why can't you take it off the WU servers??

One of the errors I got when trying to upgrade laptop from 16199 to 16215 was this:



Error during INSTALL_RECOVERY_ENVIRONMENT.

Inspecting this a bit more I think I now know what happened. If I am right there's no way the upgrade could have worked, whatever upgrade method or workarund was used.

Some background.

If you let Windows installation to do the partitioning on a GPT disk, the 450 MB WinRE partition is set first on disk, followed by 100 MB EFI partition and hidden (not shown in Disk Management) small 16 MB MSR partition. The OS partition is then next, volume (partition) 4:


(Screenshot: default EFI partitioning.)

The problem is, the WinRE partition will need more space when subsequently upgrading to new builds but as it cannot grow when first on disk, EFI partition blocking its every effort to expand, Windows Upgrade creates a new WinRE partition after partition 4, Windows OS partition.

Being directly after C: partition is a good place for WinRE partition because it can something that no other partition can: it can extend backwards, shrinking Windows OS partition C: as needed to "steal" more space from it to cater its expansion needs.

That's why I use a diskpart script on clean installs or autounattend.xml answer file on deployments to partition GPT disk differently placing EFI partition first (green in screenshot), followed by hidden MSR partition, OS partition (blue) and finally WinRE partition (yellow):



When an upgrade then needs more space for WinRE partition, it takes the space needed from C: shrinking it:



(Above two screenshots from a Hyper- V VM on which I upgraded from 14393 through 15063 to 16199 to get screenshots.)

Build 16215 upgrade totally screwed that, ignoring the already existing WinRE partition and instead of extending it as it should have done created a new WinRE partition (red in screenshot) placing it between Windows OS partition and existing WinRE partition:


(Screenshot from my laptop, what actually happened.)

However, although upgrade created this new WinRE partition and installed recovery environment on it, it then tried to use the old WinRE partition, got confused and upgrade failed.

I still need to study this but I believe this is what happened. Confusion about what WinRE partition to use.

Kari

Kari said:

One of the errors I got when trying to upgrade laptop from 16199 to 16215 was this:



Error during INSTALL_RECOVERY_ENVIRONMENT.

Inspecting this a bit more I think I now know what happened. If I am right there's no way the upgrade could have worked, whatever upgrade method or workarund was used.

Some background.

If you let Windows installation to do the partitioning on a GPT disk, the 450 MB WinRE partition is set first on disk, followed by 100 MB EFI partition and hidden (not shown in Disk Management) small 16 MB MSR partition. The OS partition is then next, volume (partition) 4:


(Screenshot: default EFI partitioning.)

The problem is, the WinRE partition will need more space when subsequently upgrading to new builds but as it cannot grow when first on disk, EFI partition blocking its every effort to expand, Windows Upgrade creates a new WinRE partition after partition 4, Windows OS partition.

Being directly after C: partition is a good place for WinRE partition because it can something that no other partition can: it can extend backwards, shrinking Windows OS partition C: as needed to "steal" more space from it to cater its expansion needs.

That's why I use a diskpart script on clean installs or autounattend.xml answer file on deployments to partition GPT disk differently placing EFI partition first (green in screenshot), followed by hidden MSR partition, OS partition (blue) and finally WinRE partition (yellow):



When an upgrade then needs more space for WinRE partition, it takes the space needed from C: shrinking it:



(Above two screenshots from a Hyper- V VM on which I upgraded from 14393 through 15063 to 16199 to get screenshots.)

Build 16215 upgrade totally screwed that, ignoring the already existing WinRE partition and instead of extending it as it should have done created a new WinRE partition (red in screenshot) placing it between Windows OS partition and existing WinRE partition:


(Screenshot from my laptop, what actually happened.)

However, although upgrade created this new WinRE partition and installed recovery environment on it, it then tried to use the old WinRE partition, got confused and upgrade failed.

I still need to study this but I believe this is what happened. Confusion about what WinRE partition to use.

Kari

What happens if you delete the winre partitions before upgrading?

I usually delete them anyway as I simply use Macrium Reflect backups if I want to roll back, or use an ISO to refresh etc.

cereberus said:

What happens if you delete the winre partitions before upgrading?

I usually delete them anyway as I simply use Macrium Reflect backups if I want to roll back, or use an ISO to refresh etc.

Have not tested yet and honestly, as I found out that I can't connect to Hyper-V virtual machines in 16215, will not test with this built. Takes too much time to test as I then would be forced to restore 16199 because I really need Hyper-V.

HippsieGypsie said:

I've been watching your progress, Marty. You get an A+ for the attempt. :)

I'm sure MS knew within hours of the release that it was a disaster.

Is that better than E, for EFFORT ?

martyfelker said:

Had to use Unlocker 1.92 to delete a leftover $Windows~BT directory. Went back to slow ring (when will there be a release to the SLOW ring??)

@martyfelker

Marty, you said you thought that no 16xxx builds had been released to SLOW ring, that is I believe technically correct. But, 16193 ISO has been available for a while thru MS (Official Source - no gypsies selling out the back of a wagon).

Download Windows 10 Insider Preview Advanced