MVCobb's Posts

@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.

@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...

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.

@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.

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?