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

ISO downloads are almost certain to give troublefree upgrades, and ESD upgrades too, but they are big full downloads, and won't work well for systems with minimal storage, or on slow, or data-limited connections.

UUP upgrades are partial system upgrades that rely on certain elements from the existing system being reused in the new upgrade, offering smaller quicker downloads, but depend on the existing system being complete, and in good working order.

I don't think UUP is well documented - well, Microsoft is famous for undocumented processes and methodologies, - but I think it is capable of behaving differently when downloading, for upgrades involving different versions, architectures, and builds.

UUP may even be variable from the initial download date, for instance starting as an Express minimal download and then a few days later, change to a Canonical maximal download, on the basis of feedback from systems that rollback, showing that the initial methodology had a high failure rate.

When 16215 was released, even for the previous release 16199, it was apparent that it was of the Canonical variety, capable of replacing all the files in the upgraded system.

16199 had plenty of bugs (as a bug-bash release), and plenty of time from 17th May to be tested until 8th June when 16215 was released to show that a Canonical maximal release would be necessary to cope with the variety of bugs discovered, and even then, many folk found that the upgrade was problematic.

I have a feeling that the 16215 upgrade's problems stemmed more from 16199's instability, than a poor quality upgrade.

It was warned from the release notes that there was an issue with some WiFi systems.

Still, Microsoft's Windows 10 development team can learn a lot from telemetered failed install logs (except when WiFi cannot connect to report back).

So far I have run 3 upgrades, 2 from different builds (16199 and 15046) on an Intel Core2 Duo, GM33 motherboard, Nvidia GT 730 multiboot desktop - no issues, and on a HP Compaq Presario CQ57 AMD E400 integrated AMD graphics laptop ( WiFi failed to initialise), otherwise trouble free.

I expect I'll upgrade a couple more before the next build release.

f14tomcat said:

Tony,

I have no hard evidence, and nothing to link to, but I have a suspicion about the rollback at the 30% mark.

In the past, I seem to recall that's where it loads some drivers, graphics comes to mind, and maybe others...then re-boots to pick up the process. A missing/corrupt/inappropriate HDD/SSD driver could easily explain why the message "Inaccessible boot device". It can't find it, see it.

Let me explain some experience concerning MS installs and device drivers. I have a NVMe SSD drive on this system. It's in a eSATA slot, not SATA 0. If I go to do a clean install from a thumb drive, properly prepared with the MS ISO, it will fail to see what we would call "drive 0". Sees all others, not the first one, the NVMe SSD. In order to get it to see the drive, I have to include the Intel drivers for that SSD on the thumb, and load them manually. Then it will see the "C" drive and allow me to choose where to install.

I'm using that as an example of a missing driver in a MS official ISO installation package causing issues with the process. The same exact problem when using Kyhi's Rescue media. I have to "Inject" those drivers into his package (the part that comes from the official MS ADK) in the .wim file on the thumb, then when I boot his Rescue thumb, all the progs will see the "C" drive. If I don't', the drive is invisible.

I'm only using all of this as a basis for saying that this build package may be missing a critical piece, and causing the failure. It can also explain why updating a VM went smoothly and without any of these "boot" problems. In a VM, the boot process is controlled by the VM host, not Windows.

Again, I have nothing hard to post to prove any of this, just what I have experienced.

Wait, I think you might be on to something.

Until you posted this, I had completely forgotten one aspect of the whole install debacle.

WU failed, where it would be at the orange screen at 33% - this happened twice. I then tried to mount the .ISO and perform an upgrade, which did not work - but I also noticed that my physical BR burner was no longer showing in my system as an optical drive, but rather as if it was a removable HD. Even clicking on it would simply open it as if it were a HD, instead of asking me to insert media.

I used the Safely remove ... panel and removed the BR burner - and ... nothing. Now it was just not there.

I then went into device manager and refreshed, and nothing. I then specifically found the BR burner and manually tried to update the driver, and it found no new driver, but it DID load it back up as a normal device.

Satisfied, I then rebooted to try to load the .ISO via USB to update - which is where it failed to load correctly, saying vcredist / .Net has terminated abruptly, and gave me the WInX troubleshooting screen, it was at this point that I hit the 'reboot into Windows 10 icon and the installation started back up where it had left off - and completed.

I had completely forgotten about that odd behavior with the burner until now. Thanks for the reminder - and a clue as to what might really be happening here, just as you supposed.

Update:

#WindowsInsiders we're chasing down some self host blockers & will not be flighting a build today.

Tweet

— Twitter API (@user) View on Twitter

No apologies....