I have the same issue on macbook air m 1 2020 with a windows 11 arm vm. It worked fine on Ventura

One thing I notice is that you have ThinPrint (virtual printing) enabled in the VM log files you posted.

Fusion 13.5 has removed ThinPrint features (see the Fusion 13.5 release notes).  Shut down Fusion, and manually edit the .vmx file of the VM. It can be found by locating the VM in the Finder, right clicking on it, and selecting "Show Package Contents". A Finder window will open and show the files that make up your VM. You'll find the .vmx file there (if extensions aren't shown, it's the file with the "Kind" of "VMConfig".

Edit the file and remove the following lines:

serial0.fileType = "thinprint"
serial0.fileName = "thinprint"
serial0.present = "TRUE"

Save the file and restart Fusion. See if the VM will now power on.

Thanks for the suggestion but unfortunately removing thin print and also the serial0 entries does not make any differences. I tried on three different guests, Linux, Windows 10 and Windows 11 (encrypted) so I don't think it is guest OS related. I also tried to disable the network adapter to narrow down the problem. The strange thing is that it starts, stays running for about 3 seconds and powers off. Looking at the logs I do not see any relation between the power states and this behavior. Looking at the corresponding logs in backed up files I see that they end with something like 

2023-09-20T16:24:50.656Z In(05) vmx WQPoolFreePoll : pollIx = 2, signalHandle = 15
2023-09-20T16:24:50.656Z In(05) vmx WQPoolFreePoll : pollIx = 1, signalHandle = 16
2023-09-20T16:24:50.663Z In(05) vmx VMX exit (0).
2023-09-20T16:24:50.670Z In(05) vmx OBJLIB-LIB: ObjLib cleanup done.
2023-09-20T16:24:50.670Z In(05) vmx AIOMGR-S : stat o=8 r=27 w=2112 i=0 br=431263 bw=8591633533

so memory is freed, the subprocess is exited.

In my case it looks like the whole process ends prematurely from the VMWARE side.

Is there any other source for debugging / tracking this down?

Thanks!

Getting the same issues on my 2019 Macbook Pro, guess we just have to wait for Fusion to get updated...

@RolandZi 

in a "trust, but verify" moment, did you verify that all the files noted in the tech note were removed (Especially the ones in your home fold'er's Library folder?

It appears that the vmx process may be crashing. I've tried to reproduce this on my 2014 Mac mini running Monterey with Fusion 13.5 but haven't been able to get it to fail.

If you don't want to "wait for Fusion to get updated" (note that it's hit or miss that VMware developers and support people read this forum and less likely that they take action on anything you post here), if you can open up a support request with VMware, that'd be advisable. (either through a support contract, the initial 30 day period after purchasing a license, or via purchase of a per-incident support voucher through the VMware Store). 

Hi,

The root cause is found.

In Mac OS Sonoma VM fusion does not work at all with the builtin VoiceOver screenreader which I need to use.

This worked until updating to Sonoma with all previous versions of VM Fusion.

Second source link:

https://www.applevis.com/forum/macos-mac-apps/if-your-using-vmware-fusion-mac-do-not-upgrade-sonoma-...

Steps to reproduce:

1. Start Voiceover by pressing CMD+F5.

2. Start a virtual machine - guest does not matter.

Expected behavior: Guest OS starts.

Observed behavior: Guest runs for some seconds and then terminates.

What would be the best place to send such bug report to?

Thanks for your effort so far.

Best, Roland

Hi,

That's pretty nasty, @Mikero can you have someone look into this?

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva

I've been testing Voice Control all day but haven't seen that issue. 

However I am investigating an issue where the UI object reference numbers don't show up within the guest so it's not interactive. 

I'm having the team investigate as well, so I'll bring this to everyone's attention also.

@Mikero it's not Voice Control that's causing the problem  it's VoiceOver. Two different but similarly named features. 

I can reproduce this quite regularly on Fusion 13.5 on Sonoma:

Open Fusion.

Turn on VoiceOver by typing Command-F5. The VoiceOver box will appear on the screen and will start speaking to you as you either type or mouse.

Pick any VM and try to power it on.  It will try to boot but will immediately power off. Looking at the vmware.log file, you'll find that the VM abruptly stops writing log entries at:

2023-10-27T02:15:35.367Z In(05) vcpu-0 Guest: About to do EFI boot: Fedora
2023-10-27T02:15:35.433Z In(05) deviceThread DDB: "longContentID" = "28e33b78df87c46feaf9f56fdce997b3" (was "3a59ad10916b8fa24554ef32c06711a9")
2023-10-27T02:15:35.912Z In(05) vcpu-0 Tools: Running status rpc handler: 0 => 1.
2023-10-27T02:15:35.912Z In(05) vcpu-0 Tools: Changing running status: 0 => 1.
2023-10-27T02:15:35.912Z In(05) vcpu-0 Tools: [RunningStatus] Last heartbeat value 1 (last received 0s ago)
2023-10-27T02:15:35.912Z In(05) vcpu-0 Tools: Removing Tools inactivity timer.

The vmx process looks like it crashed.  (This is a case where there's no easy way to find out why the vmx process crashed - hints would be appreciated so we could help)

Now turn off VoiceOver with Command-F5

Power on the VM. It will now power on. 

This issue has been discussed before and according to:
https://communities.vmware.com/t5/Fusion-2023-Tech-Preview/Tech-preview-crashes-when-starting-Window...
there is an internal ticket for this (on VMWare server):
#3254837
https://bugzilla.eng.vmware.com/show_bug.cgi?id=3254837
A work-arround can be found in the 5th answer of this thread:
https://communities.vmware.com/t5/Fusion-2023-Tech-Preview/VM-shuts-down-seconds-after-powering-on-q...

Basically: When starting Fusion from the terminal with "su" privileges the error does not show.
I can confirm that this works for me, Mac Mini 2018.
Since this problem is only present when using Voiceover and since "su" privileges solve it I would assume the root cause is related to access privileges. Let's keep in mind that VM Ware does use the accessibility API and requests permission to it during installation.
May be they are dropped again when running as normal user in Sonoma?
Best, Roland

As another blind user I can confirm this issue and its impact. Fusion has been the most accessible virtualization product on the Mac historically so this was a really nasty surprise.

The other posts here describe clearly the issue, it is as simple as trying to start a VM with VoiceOver running under Sonoma. Happy to provide any other info that could be helpful.

Fortunately I only upgraded my personal Mac and not my work one; my daily workflow sees me with Windows and Linux VMs alongside the host macOS.

@Mikero This is a showstopper for those that have vision issues and need to use VoiceOver with Fusion. IIt appears that your team has known about this as it was discovered immediately after the 2023 Tech Preview was released and an internal ticket raised. For some reason they chose not to address it for Fusion 13.5 GA.

Can you ask your team to expedite a fix for this? For the visually impaired, it's right up there in priority with a security vulnerability.

@RolandZi Issue reproduced on Sonoma Host today. Updated the existing ticket which you have highlighted in one of the comments above and team is looking into it. This is occurring on both Fusion 13.0.2 and Fusion 13.5.

This is NOT seen on Ventura Host.

This still needs to be addressed as soon as possible even though it doesn’t happen on Ventura. Staying on Ventura  may be an alternative for those that haven’t or can’t make the upgrade. But expecting that one should should downgrade to Ventura to work around this bug isn’t practical for those that made the jump already. It is not an easy process to downgrade an Apple Silicon Mac to earlier versions.

This bug also makes Fusion unusable for the visually impaired on  any system that requires Sonoma (like the ones announced last night). 

Thanks Paul, we're well aware of the scope and gravity of the situation and are working diligently to resolve.

@Mikero Thanks for the feedback that VMware understands the situation. Keep us posted.