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.
