Workstation Pro 16: Unable to Boot W10 ISO to Upgrade W7 VM

[MVCobb]

Using VMware Workstation 16 Pro. I'm unable to upgrade a Windows 7 VM to Windows 10. When I start the update from Windows, it gets stuck after the reboot. After hours of waiting, turning the VM off and on again will make it go back to Windows 7. Then an error message appears saying "Installation failed during SAFE_OS phase".

When booting from the Windows 10 ISO, it shows the logo and spinner wheel for a second and then goes into a blank dark-blue screen forever (waited overnight and nothing). The mouse cursor moves, but there's nothing else happening (see attachment).

The C: drive has 150GB free, so that's not the problem. I also disconnected all non-essential devices.

Tried setting the disk from SCSI to IDE and then to SATA, as described in this article (to no avail):
https://communities.vmware.com/t5/VMware-Fusion-Discussions/Solved-Have-been-unable-to-upgrade-Win-1...

Tried upgrading and downgrading the hardware (versions 12 through 16). Didn't work.

Also tried changing to BIOS and EFI. Didn't work.

However, if I replace the VMDK disk file (containing W7) with a blank/brand new one, then the ISO boots fine. So clearly the issue is with the VMDK file that has the Windows 7 guest client. This VMDK file was created from a hardware drive using the Converter years ago.

I've used VMware Workstation 16 Player, as well as VMware Workstation 16 Pro but I still can't boot the Windows 10 ISO if this particular VMDK disk is connected to the VM. Is there anything else that can be done?

[ajgringo619]

Have you tried running the upgrade from inside Windows 7; i.e. mounting the ISO after you login into W7, then running setup.exe from there?

[MVCobb]

Yes, that's the first thing I tried. That's the only time I get an error message (after the reboot fails and it boots back W7).

[btmp]

If you have VMTools installed on the Guest perhaps try uninstalling those, then do the upgrade then re-install the tools? That might only help for the 'in Windows' setup attempts.

I've never seen an official ISO fail to load due to what any HDD attached held.....is this a custom ISO by chance or a virgin one made by MS?

[MVCobb]

Yep, did that too (uninstalled VMware Tools). No luck. I also uninstalled every non-Microsoft driver I could find, and then removed from the VM every non-essential device, except for the USB hub, video card and CD/HD drives.

This is not a custom ISO, it's the official release from Microsoft. I also used previous versions too. In all, I tried the official ISO files for W10 versions 1909 (Nov-2019), 20H2 (Apr-201) and 21H1 (current).

At this point I don't think it's anything related to W7 itself, because the boot process doesn't even get to the point where it analyzes the previous Windows installation.  It fails right away, in seconds.  So the problem must be with the VMDK file headers, there's something there that the Windows installer does not like.  If I replace the W7 VMDK file with a newly created blank one, the ISO boots just fine and the main window appears.

The W7 VMDK file is old, created from an actual drive using the Converter tool back when Workstation was in version 11. Is there a tool that could check this file for errors or even copy the contents (but not the headers) to another fresh/new VMDK file?

[btmp]

Can't recall coming across any tool that checks such things in my time with Workstation.

You could mount the existing disk on your host and use DISM to capture it to a wim and once you have the wim of the current state you could apply it to the new vmdk (after it has been partitioned and formatted then mounted) That wouldn't carry over the bootloader and such but you should be able to use the Windows ISO to handle that part via the cmd line if need be

[RDPetruska]

Is there a particular reason you want to upgrade a Win7 VM to Win10?  The easiest thing is keep the Win7 VM as it is, and create a brand new Win10 VM.  You then have one of each available to you.

[MVCobb]

@RDPetruska It's a dev machine full of old code, libraries and compilers that are no longer supported or distributed. One particular library was made by a company that no longer exists, and there's no way to reinstall it on a new machine because their licensing server is gone. It will keep working forever on this machine, but there's no way to install it on a new one.

The code is being ported/recreated in a newer dev environment, slowly, but I need to buy more time before it can be fully decommissioned.

Why W10, and why now? Because one of the systems this thing interacts with has new security requirements, and their encryption tools won't run on W7. So now I'm stuck between old and new technologies, and W10 is my best chance.

[btmp]

Ooh, if it's that critical please be sure to have a backup of the VM or only mess with a full 'clone'!

[MVCobb]

@btmp Yes, I think it's time to start checking some other/unusual ways. I thought that maybe there would be a disk checker of some sort. Thanks.

[MVCobb]

@btmp Absolutely. I have copies of this thing in multiple places, from many different times in the past. I'm now just messing with an offline clone.

[btmp]

As upgrading the existing Win7 to 10 is your primary goal and only starting the upgrade from inside Windows 7 works at this point, perhaps you should start that route again and take a look at the resulting log files related to the failure that MS saves? It might give you (us) a better idea of WHERE Windblows is choking and a better place to start for trying to fix that route?

[MVCobb]

I went back to the live update as @btmp mentioned, then it failed and booted up W7 back again. I then looked at all log files created/updated during that time but there wasn't really anything useful there. The log files indicated a rollback, but not the reason why. And reading obscure Microsoft logs is quite funny sometimes... one line had something like "What? It didn't even get to this point?" Clearly some *very* unexpected situation is preventing the installer from working.

Next I created a new NVMe disk, about the same size as my W7 boot drive, and used Clonezilla to copy all contents from the IDE drive to the NVMe disk. Clonezilla did not crash and made the full copy without showing any errors. Then I disconnected the old drive and kept only the NVMe connected and booted the W10 ISO again -- it froze the same way. So it's not the VMDK file headers, because the NVMe kept the newly created headers and geometry data intact after cloning.

So, back to troubleshooting Windows (as opposed to VMware) for now.

My next attempt was to use a Windows 8 ISO. It froze at the same point as all other W10 ISOs.

And finally I ran the Windows 7 repair tool. To my surprise, it booted up just fine, but when I chose "repair" it came back with an error: "Startup repair cannot repair this computer automatically" and "StartupRepairOffline 6.1.7600.16385 Problem Signature 05 AutoFailover NoRootCause". Googling all those terms took me down a rabbit hole that I haven't recovered from yet (no pun intended). But it looks like it's a partition issue or something. I'm starting to be amazed that the W7 system even boots up.

When I ran bootrec /fixboot, for example, I got a strange error saying "The Volume does not contain a recognized file system" despite diskpart clearly listing the C: drive as NTFS.

So clearly the drive has issues and it may not be VMware-related at all. Sigh.

[wila]

Hi,

What's the partition layout of this VM?

--
Wil

[MVCobb]

@wila There's a 1.46GB recovery partition at the beginning of the disk, and then a 227.16GB bootable NTFS partition where W7 is. See attached screenshots for details.

PS: these screenshots were from yesterday. I was able to fix the "this volume does not contain a recognized file system" error by 1) marking the boot partition as "active" inside W7's disk manager (strange it wasn't); and 2) deleting the file C:\Boot\BCD and recreating it by running "bootrec /rebuildbcd".

I also ran CHKDSK and made sure the disk has no errors. Still, the problem persists. Today I'll try to make a data copy to a new NVMe disk file (without the partitions and boot) and see if W10 reads it and recognizes it as an "existing installation of Windows" that can be updated. Shooting in the dark now...

[btmp]

Sorry to hear there wasn't any helpful info in the windows install logs =(

As you have another copy perhaps you could try deleting the hidden recovery partion entirely? I kind of doubt it will do the trick unless there is something rather unique about it but might as well remove whatever possibilities we can, right? If not that, at least, disable the active parition flag on the hidden one now that you have it set on the OS partition...less chances of confusing something that way

Short of that I think re-creating a new disk (ideally with the same hardware in case any activations use that) would be the next best step. Then you could transfer 'only' the OS partition files over to the new one...I'd use DISM to capture and apply it myself but most 3rd party backup and restore softwares might do the trick except that we want to 'forget' or leave behind the original disks partition setup to ensure thats not involved somehow. Sounds similar to your 'data copy' attempt but I think it may run into some issues if you're only using Windows Explorer to Copy and Paste it over. Still, Good Luck!

[louyo]

PMJI late: my experience has been that you have to upgrade via the setup.exe in the image. Maybe try running msconfig and turn off safe boot, selective services, and disable starting  any services/programs that are not Microsoft? If the upgrade works, you can re-enable.

Lou

[louyo]

Forgot: Disable/remove any AV programs.

[MVCobb]

@btmpI actually used Acronis True Image to make the data copy, first with the boot sector and partitions intact, and later with just data. Both failed, which tells me that the Windows 10 installer is actually reading data from the disk and then failing (instead of failing to read the disk), but it's all very fast so what could it be that it's reading? I'll try DISM next.

@loyoI've already tried all that. I started deleting and turning off stuff in order to create the most simplified version of this VM that I could, hoping to figure out the problem first and then applying the solution to a full copy of the original.  I started with setup.exe, ran msconfig.exe for minimal boot, turned off non-microsoft services and drivers, and later even went as far as deleting every non-Microsoft driver and service  in the VM followed by removing all virtualized HW except for drive, RAM, CPU and video card. I also uninstalled the Microsoft Security Essentials too, so there's really nothing left in this barebones copy of my VM except MS stuff.

The interesting thing is that I found my original Windows 7 Pro SP1 physical disk, and booted from it just fine. The installer finds the disk, finds the current Windows installation, offers to install new or repair (and succeeds), etc. Fully functional. But boot from a Windows 8.1 or 10 disk and it just shows the logo for a few seconds and then goes blank. Amazing.

[btmp]

If it fails that quickly I'd expect it to be partition or maybe MFT related but you said you already checked the disk so I'm at a loss. Thanks for the update but sadly I'm out of ideas atm. Please do update us further if you make any progress!