Vmware Fusion and Macos Tahoe

Hi,

I can confirm the issue and there are currently no workarounds that I know, except switching to a different virtualization software.
Parallel Desktop is somewhat usable in combination with VOCR , and if you need to virtualize some Linux or MacOS VMs, maybe UTM would be a good choice.

There's a solution to make it work; disable voiceover, as that's what causes the machine to crash; can confirm because this last happened to me on macos sonoma. Of course, switching to another vertualisation software is a solution as well but, yeah the bug from sonoma is back again. Btw this is squarely on fusion to fix, not on apple, got told that when reporting the bug to them back in sonoma. But yeah alternative solution, set your virtual machine to start up automatically on start up, via vertual machine settings, general, launch fusion, and quickly turn off voiceover. You should be able to set up a activity or similar that turns off voiceover when fusion starts but not sure how to do that though.
Defenetly report it to vmware to hopefully get this patched.

Since Shortcuts now supports automations, make an automation that turns off VO when VMWare opens, and back on when it closes.
I've also noticed that if you turn on VO while the VM is running, the vm will almost instantaniously crash.

Yeah that happened as well in macos sonoma. I've no idea exactly what's going on since the same thing doesn't happen in other vertualisation programs but yeah this bug drove 'me up the wall when it happened.

if you don't think you canturn off VO fast enough or are unfamiliar with automation, just open VMWare fusion, make sure your cursor is on start, then turn off VO and press the left mouse button on your trackpad. Always works for me.

You can also press the spacebar. Make sure you're on start in VMWare, turn off VO, press space, wait. That's what I've been doing and it works.

I would definitely reach out to Freedom Scientific or whoever you bought the JAWS license from, as the issue isn't anything that can be undone. I have in the past had negative experiences with Freedom Scientific regarding getting JAWS support when JAWS was running on Mac hardware in the Boot Camp days, so don't expect to get much help from them with using JAWS on the virtual machine itself. But they should at the very least be able to help you sort out the license issue.

From my breaf time using jaws, I seem to remember there beeing a jaws activation portal or something where you could deactivate your license from a machine, look at activations etc. This was years ago tthough, like back in 2018 if not earlier and I only got access thanks to a friend sharing their license, temporarily mind you but; yeah. Assuming that hasn't changed, you should be able to diactivate your license etc from that portal.
As far as vmware getting an update to fix this... I've no idea. I'd say probably as they still need to add mac tahho support but, it’s broadcom so; who knows if this particular issue will get fixed even if support for tahho gets added. Best option is to reach out to broadcom directly and let them know this ishue has resurfaced; as given this happened back in mac sonoma, they should, in theory; be aware that its not anything new. Also, to restart the vm, there is a workaround. Go the menu bar with voiceover on, vertual machine, restart, and go character by character to see exactly how it’s spelled. Then, go to system settings and set that action to a keyboard shortcut; it should, assuming keyboard isn't beeing captured via the vm; work as a workaround. However, I'd recommend always having a backup screenreader in your vm just in case of jaws failure like NVDA, or relying on narrator for backup, could be another option as well; but point is, have a secondary option available, weather that's NVDA or just launching narrator.

Hi,

I got the following from Google's AI search results, so hopefully they will help.

Deactivating Your License

Go to the Licensing Portal: Open your web browser and navigate to the Freedom Scientific Software Licensing Portal.

Log In: Enter your registered email address and password to sign in.

Manage Your License: On the portal page, you will find the option to activate or deactivate your license for different computers.

Deactivate: Select the option to deactivate the license on the desired computer to free up a slot.

Reactivating Your License

Log in to the Portal: As above, go to the Freedom Scientific Software Licensing Portal and sign in with your credentials.

Find the Activation Option: On the portal page, you'll see an option to "Activate the computer".

Follow the Steps: The portal will guide you through the installation and activation process, which involves downloading a small file and completing the setup to activate your license on the new computer.

Important Notes

• Your annual software license allows you to install and activate your software on multiple devices (up to three), so you can deactivate it on one computer and activate it on another.

• If you have purchased an annual license, you will receive emails with links to manage your license and access the portal.

• The process involves a successful installation of the software and downloading the license file, so ensure your computer has a stable internet connection.

The link to the Freedom Scientific portal can be found here.

You'll have to check to see if a new update has been released because the manual update is broken. As for alternatives, depends on what you use it for; if its for running fast paste games like hearthstone etc probably parallels or fusion is your best bet, but if you don't care about that, you could also use UTM while they fix this, assuming they haven't already.

Fusion 25H2 was released and VMWare acknowledged both the existence of the problem, and that there was no workaround. It looks like a carbon copy of the issue we saw under Sonoma and, as before, the ball is in Apple's court to fix it. Details here:
https://techdocs.broadcom.com/us/en/vmware-cis/desktop-hypervisors/fusion-pro/25H2/release-notes/vmware-fusion-25h2-release-notes.html

For now, however, be assured that updating Fusion will not help you.

And, yes, it is entirely reasonable to be annoyed about that.

Ok, here's what I don't get, why is it apples ishue. Because the last time that this happened under macOS Sonoma, I emailed Apple myself, and they specifically told me that this was on vmware to fix, not on them. Also... Hows's it apple's ishue if it only showed up in macOS sonoma then again now in taaho? I dunno, to me the, oh apple has to fix it seems kind of a cop out, if you ask me. I mean, think about this. If it was Apple‘s fault? This would happen in parallels, UTM, etc. Given this, it is more likely it’s actually a fusion specific ishue, not a apple ishue because if it was we'd likely be seeing this in utm, parallels etc; which is not the case. Also, no workaround? Yeah, clearly they haven't done their research. The workaround at the moment? Turn off voiceover before starting or resuming the vm. I know its not what many might want to hear, but that's likely the only viable workaround at the moment.

As far as I know, you cannot use vmware's vertual machines with UTM. Meaning you cannot import them into UTM and vise versa, from what I know. This is do to both using different formats for their vertual machines which, as far as are know, are not universally compatible with each other.

I asked Chat GBT if it would be possible to use a VM created in Fusion with Parallels. the answer was, apparently, yes. I did request it to do thorough research and not just give me a positive AI canned answer, so I'm reasonably confident in that particular answer. But if anyone wants to follow up I'd be interested in your findings.

From what research I have done, fusion to parallels can be done. Fusion to UTM, as far as I know, is not possible. As far as parallels though
https://kb.parallels.com/115305
Edit: there might be a way to do this for utm but, I have no idea if this still works.
https://gist.github.com/ogerardin/014aff71b7d7aacf4bbfb3b8bbc575b7
The steps are quite long and can be found in the link above but I've no idea if this works.

Regardless of who's blaming who, the issue is definitely caused by an Apple API deliberately causing a crash in a setuid helper program. So, obviously, VMWare will be expecting Apple to fix it, again. (Presumably Apple thinks VMWare has another solution, if that's what they're telling you.)

And, no, I definitely don't regard just not using VoiceOver as a workaround, because that quite simply means it's impossible to use both environments at once, or even manipulate the VM configuration while it's running, which I often need to do. So this is going to put a damper on my holiday cheer, no doubt about it.

See, here’s the thing — both the VoiceOver bug and the constant “Background Items Added” alert point to the same underlying problem: Fusion’s architecture just hasn’t kept up with macOS. If this were purely on Apple, Parallels and UTM would be tanking too. But they don’t, because they use Apple’s native virtualization framework that plays nice with the current accessibility and security layers. VMware Fusion, meanwhile, is still dragging around an older helper-based system — launch agents, daemons, and a privileged setuid helper — that macOS now treats with a lot less tolerance. So even if an Apple API technically kills the process, it’s doing so because Fusion’s still operating like it’s 2018.

That “VMware has added items that can run in the background” message you get every single launch? That’s another symptom of the same mess. A properly designed app adds its background agents once and macOS remembers them. Fusion doesn’t — it keeps re-registering or respawning them every time you open it, which trips macOS’s background-item monitor. That’s not normal behavior; that’s sloppy integration. It shows that VMware hasn’t modernized how their daemons and launch agents are handled under Apple’s new background-process model.

Put those two things together — the VoiceOver crash and the background-item warning — and you get a clear picture: Fusion’s still built around outdated system hooks that clash with modern macOS security, accessibility, and background management. Apple might’ve hardened things, sure, but it’s VMware’s job to adapt.

As for a workaround, the only reliable one right now is to disable VoiceOver before launching or resuming the VM, then re-enable it afterward — which, frankly, might work for some, but yeah, it might not work for others, and that's totally fair. If you rely on accessibility full-time, the smarter call might be switching to UTM for now. To be frank though, these ishues not beeing addressed as long as they have is pointing a clear picture; broadcom really don't care; and yeah, for those wundering, the login items bug? Yeah, that affects everyone. Sighted, blind, def... Everyone; it’s not blind specific. Granted its a small annoyance in the skeam of things sure, but, it tends to drive you bonkers after a while for sure.
I'm not pointing fingers by any means, but, this is not a good look for vmware. I mean, the login items bug has been around since sonoma as well as the voiceover bug we're talking its been 2, 3 years by now; not a good look, they should focus on modernising but I guess that's not in their priorities. Then again, it makes sense. In 2023, VMware was officially acquired by Broadcom on November 22, and macOS Sonoma released about two months earlier on September 26. After that point, VMware’s track record has been sliding — slower updates, long-standing bugs, and accessibility issues still lingering. The login-items problem has been around since those early Sonoma builds, and the VoiceOver crash dates back to that same timeframe. That’s two major issues surviving multiple OS updates and years of supposed “maintenance,” which doesn’t exactly scream active development.

And yeah, everything points to the fix not coming from Apple but from VMware quietly adjusting something on their end. The bug first appeared around Sonoma 14.2, seemed to disappear by 14.4, yet Apple didn’t issue any accessibility or virtualization-related patch notes in that window. No API changes, no framework fixes, nothing public. Then VMware’s later build changelogs claim the problem “no longer occurs.” That fits perfectly with VMware having tweaked Fusion itself, not Apple fixing the API. All the evidence suggests VMware finally patched around their own bad integration; it wasn't apple who fixed it.

I have no doubt that VMWare are taking it slow when it comes to working around Apple's newer security restrictions. Unfortunately, it just means I have one more reason to hold off upgrading from Sonoma, where everything's working fine. This is a nuisance, and I would have preferred VMWare take a more preventative approach, but Apple breaking compatibility because reasons is par for the course and I'm not that desperate for punishment—at least, not yet—on my desktop machine; the server's another matter, where I use other tools to virtualise Linux under Apple's Virtualization framework. I don't however regard Parallels as an option, because it's not accessible by any reasonable measure, and Fusion's the only option if you want GPU acceleration on Intel or Apple Silicon in Windows. So that's where things stand for me now.

I’m Going to be completely honest, I don’t think it’s VMware or in this case, Broadcom taking it slow. I mean, it’s been two years. That is not exactly taking it slow, if you ask me, that is not caring at all. The thing is, I’m just taking a wild guess, but it will not surprise me at all if fusion gets deep sixed, leaving either parallels or utm to be the only option. Just a wild guess; but given the direction things are going? I won't be surprised.

A euphemism. You're right, now it's a free product—and a difficult one to obtain, at that—development is basically "best-effort". The reason Fusion and Workstation exist is primarily so you can interoperate with VMWare's server platform, VSphere/VCenter Server. In that role it's one of a kind, allowing you to both remote into the server and manipulate VMWare VMs directly. But, for most end-user purposes, this isn't required at all, and other options exist. Even the consumer-facing functionality, like Unity or Bluetooth support, have been stripped back or removed.

So, sure. I think it's the best option, but I acknowledge that it's just limping along at this point. I regard the native UI as a very, very big bonus, but any reasonable assessment of the options would contend that Parallels can be made to work. I'd just prefer not to, is all.

Vmware clearly is wrong on this one. It is a vmware issue just going by the aerror message. VMware tries to elevate privileges to access some accessibility feature which fails due to apples security. Running vmware with sudo, which you should never do, will fix the issue as the vmware player then has the required privilege.

VMWare, for not redesigning their app to use a persistent elevated process, or Apple, for belligerently breaking stuff whenever they get the chance?

I think there's scope for arguing that both are at fault, if that's your jam.

Gonna be honest, Vmware gets the blame on this one, and the why is because as I have previously mentioned, this does not happen in any other virtual machine program. Whether that’s parallels or whether that’s UTM it does not happen on any other program other than vmware. If it was apple breaking stuff; this would be vertualisation program wide; its not. Not only that, but if it was apple breaking stuff, we'd also see this with other apps that need accessibility privileges, or say, using apple scripts, etc; which, is not the acase. Point beeing, this would be happening system wide if it was on apple to fix.

25H2U1 came out recently to fix security issues, and the release notes make no mention of this issue as either known or resolved. And VMWare forum guru "Technogeezer" still thinks the issue persists, though he doesn't say whether he confirmed this himself. It is known, however, that the change is Apple's and that they're the ones who need to fix it, so the temptation is sadly to think that VMWare have simply stopped lobbying on this issue.

TL;DR: install Fusion 25H2 on your Tahoe box, test it, and let us know how it went.

I tried fusion a few days ago again, and the VM instantly crashed with voiceover on, just as before.

That is all.

What I do is run VMWare, make sure I'm on the start button, turn off Voiceover, then hit space. It takes a bit for the VM to start up because I'm on a base M2 Mini. But it works once it gets going.

This thread is the best explanation. I'm a happy paying customer for slightly terrible accessibility but still very usable, anything is better than this neglect of a software and if you think broadcom are gonna do anything, then wake up, their own portals and sites are more broken than this thing. UTM has problems each time I've tried running any windows or linux vm from ventura to tahoe, freezing after a few minutes. Skill issue? 99%.
This is as much as a lost cause for me than say aplause group giving back the usual acapela tts speech rate than before the enshittification of the app, aka never or as close as possible to never we can get.

But, can you honestly say that it's a good endorsement of the Mac?

Yes, the Mac will do what you need. So long as you install Windows in a VM, using inaccessible virtualization software.

Yes, yes. The hardware is great. And I really shouldn't complain. Also, I just bought a MacBook Neo, so it can't be that bad. But still.

If its say audio editing, windows flops hard on this one. Can you do it? Yes; but most plug-ins will be inn-accessible and you have to use either addons, ocr, or sometimes a combination of both because most plug-ins are not accessible out of the box on windows on the mac yes, just as an example and yeah this does mean you'll miss out on very useful tools if on windows. Editing documents tables, emails, web etc, work fine on both, though of course both have their caveats.
Sorry got a bit off topic but returning to the topic at hand,
Here's what I don't get; why the heck is this bug present in fusion but not in every other vertualisation software? I mean, utm, parallels etc don't have this particular bug, and yeah they don't have the login items bug every time you start the program either, so then, why? Bad design, or what? and yeah, I’m seconding the broadcom point. Just look at the minor bug which has been present for years, that being the every time you launch the program, you get the login items added notification. This happens like out of 10 times? Eight or nine. and it hasn’t been fixed. For years. We’re talking about this bug is a minor inconvenience. And yet, it hasn’t been fixed. If that minor bug has been sitting around for years, not fixed, what makes you think that a major program breaking bug is gonna get fixed when the minor bugs do not get addressed? I don’t think it’s gonna happen.

VMware chose to design their software, which remember was once a commercial product that ran great for years on many Macs, around a self-contained app bundle which launched privileged helper programs on demand to provide virtualisation services. This meant they had complete control over the stack and there were basically no moving parts when the app wasn't running, both attractive when you're being used in corporate environments alongside their server software. UTM, by contrast, uses Apple's own entitlements to provide for virtualisation, whether or not it uses the qemu backend or Apple VF and therefore requires no added privilege escalation; Parallels does the same thing using their own hypervisor. This means using Apple's frameworks and effectively delegating the privileged operations to Apple's own processes. Both are available in the Mac App Store as a result, which is marvellous, but it means they don't have to deal with Apple's dicy security lockdowns that are affecting us when invoking a third-party privileged helper.

I obviously hope Broadcom will eventually get around to fixing this. Meanwhile, yes, your options are UTM and Parallels. I think UTM is adequate for Linux (I actually think Apple's own Virtualization framework is adequate for Linux, so long as you don't need access to external hardware, regardless of the frontend used) but Windows support is only really viable through Parallels if you intend to take full advantage of your hardware.

The only way is to make a activity that turns on voiceover when the app isn't focussed and turns it off when vmware is focussed which comes with its own downsides but its a possible workaround.