VMware Communities
gen843620
Enthusiast
Enthusiast
Jump to solution

It seems Fusion 13.0.1's VMWare Tools installer isn't compatible with Windows XP (Pro, SP2)

I and several of my customers run VMWare Fusion 12 and 13 on Intel-based Macs.

Fusion 13.0.1 has been fine for Windows 10 and 11, but tonight I upgraded a customer's (macOS Monterey) Fusion 12 to Fusion 13 and VMWare Tools failed to install, including from d:\setup.exe (error appeared that setup.exe isn't a valid win32 program).

I have lots of experience over the last 10 or so years with customers' old messed up VMWare Tools updates and tried all my tricks, like deleting all registry keys with "vmware tools" matching whole phrase, but none helped.

So I created a new virtual machine from a Windows XP DVD -- a total clean install -- and the same thing happened: vmware tools wouldn't install even from d:\setup.exe (and the same error appeared "setup.exe isn't a valid Win32 app...").

I thought maybe if I could install .NET 4 or earlier, setup.exe would work, but without internet access with very old IE within the VM and without drag and drop file sharing from the Mac and without sharing enabled (because Tools wasn't installed), I don't see how I can install .NET 4 or earlier from a MS download -- AND I don't even know if .NET 4 would help.

So I downgraded VMWare Fusion 13 to v12 and VMWare Tools installed fine in WinXP.

I'm not sure, but it seems Fusion 13 programmers and QA testers didn't try v13 VMWare Tools with Windows XP. 

I still have about 4 customers using XP to run very old, very obscure specialized excellent but abandoned software for their industries. Several other customers use Fusion 13 with Win10 or Win11 to run Windows accounting software and VMWare Tools updates easily.

If Fusion 13's VMWare Tools wasn't intended to work WinXP and the developers don't care, please let us know so we can avoid the hassle of flailing, failing then downgrading. I can't charge my clients for all the time I spent upgrading, testing then downgrading. This issue really dinged my revenue today.

EDIT: maybe Fusion 13's VMWare Tools requires WinXP SP3. The above issue occurred with WinXP SP2. I just noticed it was SP2 after installing another VM from the WinXP DVD in Fusion 12, which has no trouble with WinXP SP2.

 

Labels (3)
Tags (1)
0 Kudos
2 Solutions

Accepted Solutions
Technogeezer
Immortal
Immortal
Jump to solution

There must be something else going on here. The version of VMWare Tools shipped for Windows XP (file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVista.iso) hasn't been changed since 2016. It identifies itself with VMWare Tools version 10.0.12 which was the last version that was built for XP.

Some basic questions and thoughts

Have you made sure that the guest operating system is configured with a guest OS type of Windows XP Professional?

Have you tried manually assigning the ISO file above to the CD/DVD drive and trying to install Tools from that?

Perhaps VMware didn't test Windows XP with Fusion 13 because Windows XP is seriously end-of-life from Microsoft. 

Have you tried dropping the virtual machine compatibility to hardware version 18 or 19 and see if that makes a difference?

Could you attach the vmware.log file for the virtual machine where the installation of Tools fails?

 

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides

View solution in original post

Technogeezer
Immortal
Immortal
Jump to solution

>> So the culprit(s) is/are a new version of Tools and/or new vm hardware version. Regardless, it's a VMWare bug.

It's sort of the former (new version of Tools), but not really. You have found a VMware bug, though.

I just installed XP Pro in Fusion 13 on an Intel Mac mini 2014 with the defaults for virtual hardware version. I got the same issue as you when trying to install VMware Tools from the GUI menu. Looking at both the ISOs mounted in the guest and the contents of the vmware.log file,  Fusion 13 is mounting the wrong VMware Tools ISO file for a Windows XP guest when you request an install of VMware Tools. It is mounting the ISO file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/windows.iso. The tools in that file are version 12.1.5, and they don't support Windows XP. That's why you're getting the "program is not a valid win32 application" message.

The file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVIsta.iso should be mounted by Fusion when a Tools installation requests is made for a Windows XP guest. That ISO is still part of Fusion 13, and contains VMware Tools 10.0.12 - the last tools version supported for Windows XP. Those tools haven't changed for years. I think you'll find if you look at the logs that Fusion 12 is likely (correctly) mounting this ISO file for an XP VM. My guess is that this is a regression from Fusion 12 introduced due to the addition of support for Apple Silicon Macs.

In a perfect world, this issue should have been caught. Given that Windows XP is no longer getting any kind of support from Microsoft and its support is deprecated on ESXi, VMware probably didn't think to include that scenario in Fusion test coverage. 

This issue can be worked around by either downloading VMware Tools 10.0.12 from VMware's software download site (the ISO is in that download), or making a copy of the /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVista.iso to the Desktop. Once you have the ISO file, re-configure the virtual CD/DVD drive to that file (you can't point the CD/DVD directly to the file in the Fusion application bundle, that's why you make a copy). When the guest recognizes the CD after the change, autostart will start setup.exe and install the tools.

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides

View solution in original post

20 Replies
Technogeezer
Immortal
Immortal
Jump to solution

There must be something else going on here. The version of VMWare Tools shipped for Windows XP (file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVista.iso) hasn't been changed since 2016. It identifies itself with VMWare Tools version 10.0.12 which was the last version that was built for XP.

Some basic questions and thoughts

Have you made sure that the guest operating system is configured with a guest OS type of Windows XP Professional?

Have you tried manually assigning the ISO file above to the CD/DVD drive and trying to install Tools from that?

Perhaps VMware didn't test Windows XP with Fusion 13 because Windows XP is seriously end-of-life from Microsoft. 

Have you tried dropping the virtual machine compatibility to hardware version 18 or 19 and see if that makes a difference?

Could you attach the vmware.log file for the virtual machine where the installation of Tools fails?

 

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
gen843620
Enthusiast
Enthusiast
Jump to solution

Thanks for the ideas.

I'm no longer connected to that customer's Mac and don't have time or desire to troubleshoot v13's Tools and/or virtual machine version (19, 18 etc) on my own dime.

This logic seems solid:

- plain WinXP SP2 w/VMWare Fusion 12 + Tools working well

- upgraded Fusion to v13, thenTools failed to load and D:\setup.exe yielded "...not a valid Win32 application..."

- created new Fusion 13 virtual machine with same WinXP SP2 DVD used to create the original v12 vm, and same problem occurred with Tools ("D:\setup.exe not a valid application...")

- replaced (downgraded) Fusion 13 to v12 program, then created a new vm with same WinXP SP2 DVD, and Tools installed smoothly (again Fusion v12).

Things that changed:

- Fusion 12 to 13, which might include a new version of VMWare Tools (but you mentioned it doesn't)

- The hardware version of the vm, whatever is the latest that Fusion v12 offers versus the latest that v13 offers (Fusion prompts to upgrade the vm to the latest hardware version, and I always do it; I don't time to try downgrading the hardware version of the vm in Fusion 13, as that'd require upgrading to v13 again, possibly messing up the 12-created vm for testing, then, if it doesn't, work revert to Fusion v12 and create a new vm; I already ate enough unbillable hours on this doing QA testing that VMWare should do, not me)

So the culprit(s) is/are a new version of Tools and/or new vm hardware version. Regardless, it's a VMWare bug.

 

0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution

>> So the culprit(s) is/are a new version of Tools and/or new vm hardware version. Regardless, it's a VMWare bug.

It's sort of the former (new version of Tools), but not really. You have found a VMware bug, though.

I just installed XP Pro in Fusion 13 on an Intel Mac mini 2014 with the defaults for virtual hardware version. I got the same issue as you when trying to install VMware Tools from the GUI menu. Looking at both the ISOs mounted in the guest and the contents of the vmware.log file,  Fusion 13 is mounting the wrong VMware Tools ISO file for a Windows XP guest when you request an install of VMware Tools. It is mounting the ISO file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/windows.iso. The tools in that file are version 12.1.5, and they don't support Windows XP. That's why you're getting the "program is not a valid win32 application" message.

The file /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVIsta.iso should be mounted by Fusion when a Tools installation requests is made for a Windows XP guest. That ISO is still part of Fusion 13, and contains VMware Tools 10.0.12 - the last tools version supported for Windows XP. Those tools haven't changed for years. I think you'll find if you look at the logs that Fusion 12 is likely (correctly) mounting this ISO file for an XP VM. My guess is that this is a regression from Fusion 12 introduced due to the addition of support for Apple Silicon Macs.

In a perfect world, this issue should have been caught. Given that Windows XP is no longer getting any kind of support from Microsoft and its support is deprecated on ESXi, VMware probably didn't think to include that scenario in Fusion test coverage. 

This issue can be worked around by either downloading VMware Tools 10.0.12 from VMware's software download site (the ISO is in that download), or making a copy of the /Applications/VMware\ Fusion/Contents/Library/isoimages/x86_64/winPreVista.iso to the Desktop. Once you have the ISO file, re-configure the virtual CD/DVD drive to that file (you can't point the CD/DVD directly to the file in the Fusion application bundle, that's why you make a copy). When the guest recognizes the CD after the change, autostart will start setup.exe and install the tools.

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
ColoradoMarmot
Champion
Champion
Jump to solution

Nice find.  XP is still listed as a supported guest for Fusion 13 so it's a definitely a bug.

gen843620
Enthusiast
Enthusiast
Jump to solution

Nice work.

Can you report the bug to VMWare?

It'd be great if they fix it soon.

I'm worried that if I use the workaround and VMWare doesn't fix Fusion 13, my customers using Fusion/WinXP might run into the same problem every time they install a minor update in Fusion 13 if that update tries to reinstall Tools. Then I'd need to reapply the workaround, but my clients would be dead in the water until they can schedule me.

In the mean time, my Fusion/WinXP customers will stick with Fusion 12 and macOS Monterey, though I want to move them to Ventura.

Most of my clients using Fusion are unaffected by this because they run Win10 or 11.

Thanks!

0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution

>> Can you report the bug to VMWare?

Neither I nor @ColoradoMarmot work for VMware. If you want this reported as a bug so VMware can fix it, you can either see if some kind soul from VMware notices this on their own time (VMware doesn't actively monitor these user-to-user forums), or you can open a service request.

>> I'm worried that if I use the workaround and VMWare doesn't fix Fusion 13, my customers using Fusion/WinXP might run into the same problem every time they install a minor update in Fusion 13 if that update tries to reinstall Tools. Then I'd need to reapply the workaround, but my clients would be dead in the water until they can schedule me.

Once the workaround to install the correct version of Tools is done, you shouldn't have to worry about it again.  First, any tools update offered by any future Fusion release that has this bug wouldn't install on XP - the installer wouldn't even start. Second, the 10.0.12 version of VMware Tools for XP VMs is the end of the line - so you should expect no need to update those tools. 

You can prevent the XP VMs from attempting to automatically upgrade Tools by editing the .vmx file (with both the XP VM and Fusion shut down) and changing the line

tools.upgrade.policy = "upgradeAtPowerCycle"

to

tools.upgrade.policy = "manual"

The only time the workaround would have to be re-applied is if they manually uninstalled the Tools from within the VM.  

>> In the mean time, my Fusion/WinXP customers will stick with Fusion 12 and macOS Monterey, though I want to move them to Ventura.

That's fine as long as you want them to stay on Monterey.  Moving to Ventura will require Fusion 13. If your customers already have the correct VMware Tools installed in an existing XP VM from Fusion 12, you should have no issues moving them to Fusion 13. It's only if you're creating a new XP VM that you need to use the ISO file workaround.

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
0 Kudos
ColoradoMarmot
Champion
Champion
Jump to solution

Just a couple of other notes:

- The lifespan of using XP is limited.  As Apple intel hardware goes out of support, you'll lose the ability to run any intel OS.  Best guess is in the 2025-2027 timeframe (you'll likely have a year's notice - Apple should announce that X is the last version that will have intel support).

- Of course, XP shouldn't be on the internet at all.  Suggest removing the ethernet adapter in the VM to be 100% sure.

- Fusion is starting to drop guest OS support, usually in line with esxi dropping it.  That's mostly hit MacOS so far, but they've deprecated it for XP, which is the first step to dropping it.  I'd expect to see end of support with 12-24 months.

- Getting XP to run on modern CPU's is getting more and more challenging, and often requires third-party patches.  So even moving to workstation on windows intel (or later Macs) could be a challenge, and of course, workstation will lose support at the same time as Fusion.

 

All of this points to the same place:  XP should have been retired years ago, but the true no-other-option is approaching, probably within  2 years.  It's definitely time to start planning to move off it completely.

0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution


@ColoradoMarmot wrote:

Just a couple of other notes:

- The lifespan of using XP is limited.  As Apple intel hardware goes out of support, you'll lose the ability to run any intel OS.  Best guess is in the 2025-2027 timeframe (you'll likely have a year's notice - Apple should announce that X is the last version that will have intel support).

- Of course, XP shouldn't be on the internet at all.  Suggest removing the ethernet adapter in the VM to be 100% sure.

- Fusion is starting to drop guest OS support, usually in line with esxi dropping it.  That's mostly hit MacOS so far, but they've deprecated it for XP, which is the first step to dropping it.  I'd expect to see end of support with 12-24 months.

- Getting XP to run on modern CPU's is getting more and more challenging, and often requires third-party patches.  So even moving to workstation on windows intel (or later Macs) could be a challenge, and of course, workstation will lose support at the same time as Fusion.

All of this points to the same place:  XP should have been retired years ago, but the true no-other-option is approaching, probably within  2 years.  It's definitely time to start planning to move off it completely.


All very good points. The corollary to the first point is if your customers ever want to go to a new Apple Silicon Mac, they immediately lose the ability to run any Intel VMs, including Windows XP. Emulation via QEMU is the only solution for that.

 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
0 Kudos
gen843620
Enthusiast
Enthusiast
Jump to solution

Yes. My clients run Macs for security and only XP within Fusion for very old specialized software for one industry. Once their Windows XP PCs died, they couldn't install WinXP on new PC hardware for obvious reasons (drivers etc).

These clients are all-Mac shops in order to have better online security and they only use XP for a zero-internet very specialized db. My clients who use that 1990s odd program all know each other in that industry and they'll all probably retire within 10 years. They bought the last release of Intel-based Macs just for this purpose, and they know that if their Intel Macs die they'll get used Intel Macs online (eBay, Macsales, et al.).

Some of my clients who still use that 1990s specialized db software use Crossover or Parallels to run Windows XP. 

WinXP runs better in Fusion in an Intel Mac then it ever did on PC hardware, perhaps because I allocate XP's max RAM (not very much) and several cores to their virtual machines and there's literally nothing else installed in WinXP.

I've kept XP running on Fusion since it came out in 2007 or 2008, I think, after moving most clients from Parallels in 2006 or 2007. Fusion and Parallels are both fine, now, though. Most of my Fusion and Parallels customers use it for QuickBooks and Quicken for Windows (they hate the Mac versions of those).

If new versions of Fusion drops XP support, my clients will just keep old versions of Fusion +WinXP running on Intel Macs only used for that purpose, i.e., no online use. 

Ironically, these very confidential databases in WinXP are more secure than modern/online competing products and services because all these Macs use whole disk encryption (FileVault) and the Macs have very long user passwords, encrypted TimeMachine backups and encrypted online backup with extra security keys and mostly importantly, zero online access through the vm. I'm pretty sure all the online versions of similar software have been or will get hacked.

I'll download Fusion 12's DMG and keep it for future legacy use; my clients all keep their Fusion license keys in text files.

Amazingly, Microsoft still allows activating XP still via their phone option followed by texted follow-up option, which allows easily saving the coded box-entry values for future reactivations. Microsoft probably does this because many point of sale devices ran WinXP way way past EOL;  poking a special registry key in an WinXP box made it into POS version (KEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady) from MS's point of view and prolonged security updates for years past normal EOL, though even that's long gone. Many ATM machines were based on WinXP way, way passed XP's official EOL (the horror, the horror).

0 Kudos
RDPetruska
Leadership
Leadership
Jump to solution


- The hardware version of the vm, whatever is the latest that Fusion v12 offers versus the latest that v13 offers (Fusion prompts to upgrade the vm to the latest hardware version, and I always do it; I don't time to try downgrading the hardware version of the vm in Fusion 13, as that'd require upgrading to v13 again, possibly messing up the 12-created vm for testing, then, if it doesn't, work revert to Fusion v12 and create a new vm; I already ate enough unbillable hours on this doing QA testing that VMWare should do, not me)

 


I NEVER do this with ANY of my VMs... of course, I'm a Process Control Engineer whose head it has been drilled into - if it ain't broke, don't fix it!  Unless I have a good reason to use newer features that a newer virtual hardware supports, then I leave my virtual hardware alone.  Many of my VMs are running at either Workstation 5.x compatibility or Workstation 10.x compatibility.

0 Kudos
ColoradoMarmot
Champion
Champion
Jump to solution

All fair points, but keep in mind that there is a terminal date within a handful of years when Intel Macs no longer get OS or security upgrades (Apple only guarantees full security fixes for the current release).  Since they're security conscious, they will have to upgrade in the next few years.  

0 Kudos
gen843620
Enthusiast
Enthusiast
Jump to solution

Fusion 13.0.2 came out today.

Any chance you could see if it fixes the Tools problem with XP?

I won't have access to the XP VMs for a few weeks.

 

0 Kudos
ColoradoMarmot
Champion
Champion
Jump to solution

It only has security fixes.  I wouldn’t expect any further development on xp support given that it’s been depreciated.

0 Kudos
gen843620
Enthusiast
Enthusiast
Jump to solution

Fusion 13 lists WinXP as supported guest OSFusion 13 lists WinXP as supported guest OS

 

vmware2.png

0 Kudos
ColoradoMarmot
Champion
Champion
Jump to solution

It’s been depreciated, which is the first step towards ending support.   Since the tools are common across all platforms, it’s likely that the next iteration will drop it.  In any case, once depreciated, I wouldn’t expect any further development or testing, especially on Fusion where the focus is on m1 support as Intel support will end completely in the next few years.

https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=Software&productid=11033&te...

 

It’s long past time for xp to head into retirement,  

0 Kudos
gen843620
Enthusiast
Enthusiast
Jump to solution

Thanks for supplying that link that shows VMWare Tools still supports Windows XP: 

"VMware Tools
"Tools available for download: Supported
"Tools bundled with host: Supported
"The VMware Tools ISO is bundled with host product"

"VMWare Support is deprecated." Of course, VMWare support is deprecated for VMware Fusion and Windows XP. 

Thanks for trying to help. I appreciate your concern that XP shouldn't be used anymore.

 

 

0 Kudos
RDPetruska
Leadership
Leadership
Jump to solution


It’s long past time for xp to head into retirement,  


Nope... some of us are using 16-bit tools that WILL NOT RUN on newer 64-bit OS's.  Heck, most of my work is still done in DOS VMs... the rest in XP VMs.

XP is still one of the best OS's Microsoft put out.

Of course, all are isolated - no network connection.  And all items scanned before going into/out of the VMs.

0 Kudos
Technogeezer
Immortal
Immortal
Jump to solution

Regardless of XP’s status in the world and if one should or should not use it, VMware still lists it as being supported by Fusion. Note the compatibility list technically doesn’t list XP as deprecated for Fusion. Just ESXi.

They still ship the last version of Tools for XP in Fusion 13.

It’s clearly a bug. The defect of not mounting the right version of the Tools ISO installer for XP should not take major development effort to identify or fix.

Conversely, in the grand scheme of things it’s not a showstopper bug. XP VMs already using tools on earlier Fusion versions will still work on Fusion 13 so they didn’t break anything in core support for XP VMs. The installation workaround is relatively straightforward. Find the file in the VMware Fusion.app bundle, and make a copy of it somewhere else. Then mount the winPreVista.iso file to the virtual CD drive. 

I suggested earlier to download Tools from VMware. Evidently they've either removed or hidden the page to download the 10.0 version containing those tools. So  it's a bit harder than I orginally thought. 

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides
0 Kudos
ColoradoMarmot
Champion
Champion
Jump to solution

We know that tools are common across all platforms, and that support is driven by esxi (since it's the big $), so having it depreciated there is a solid sign that depreciation, followed by desupport, is coming for other hypervisors too.

People who use XP for anything really should make solid plans to migrate off it.  Especially if they're using it on Fusion.

0 Kudos