Cant Connect Windows 11 Arm VM using Remote Desktop on Host Machine MacOS M1

[NC CH]

Hi Guys,

I have just created a Windows 11 ARM VM on my Macbook M1 Pro using VMWare Fusion 13.6.2 . Everything runs fine until I tried to make a remote session using Window App (formally known as Microsoft Remote Desktop) on my Macbook and I getting the following error message

Unable to connect

The graphics display components in the remote session failed to start up.

Error code: 0x11

And sometimes I just get a black screen. 
Basically, connection is ok cos I am able authenticate the remote machine successfully.

Any Ideas., kindly advise. 
NC

 

[Technogeezer]

I tried to reproduce your issue on my system, but have been unable to.

Can you check the version of VMware Tools in the VM?

What's the build of Windows 11 that you're running in the VM?

What's the version of your Windows App on the Mac? 

I'm running the following:

• M1 Mac mini
• macOS 15.3.1
• Fusion 13.6.2
• Windows 11 ARM VM, build 26100.3194
• VMware Tools 12.5.0 installed in the VM (that's the latest version downloaded from the Broadcom software download site - 12.4.5 is the version bundled with Fusion)
• Windows App on macOS version 11.0.6 (2417).

[NC CH]

many thanks for your prompt response.

following are my setting

M1 Macbook Pro
MacOS 15.3 (24D60)
VMWare Fusion Player Version 13.6.2 (24409261)

Windows 11 ARM VM, Ver 24H2, build 26100.3194
I got this from the VMware where there's option to getWindows ISO and download to WMWIsoImages.
filename is Windows11_26100.2033_Professional_en-us_arm64

VMware Tools 12.5.0-24276846
side note, previously was 12.4.XXXX when I firstly installed from the VMfusion menu > install VM Tools, then I found out that there is a link https://packages.vmware.com/tools/releases/latest/windows/arm/ has the latest version.. so I used this instead.
I have tried both 12.4 and 12.5 vm tools but to no avail.

Window App on macOS Version 11.1.0 (2508).

any advise? cos I even tried using parrallel to create a win11 arm vm and it works when I tried to remote desktop from macos host using windows app.

[NC CH]

FYI. I am connecting via my host IP. eg 192.168.10.138 using Window App

on the windows 11 arm vm is configured as follow
Connect Network Adapter
Share With My Mac

Added following in the session[incomingtcp] in /Library/Preferences/VMware Fusion/vmnet8/nat.conf

3389 = 172.16.117.132:3389  --- I got this ip via the ipconfig from the windows 11 arm vm

[Technogeezer]

I'd upgrade the Windows App - you're running a lower version than I am. 

I also just noticed that the Windows App has been updated to 11.1 - I'm downloading that and seeing if things still work. 

The other thing I'd try is to uninstall VMware Tools in the VM, reboot the VM, then re-install VMware Tools 12.5.0.

[Technogeezer]

If you're connecting to that VM only from the local Mac, the best way to do that is to configure Windows App to connect to the address of the VM in the NAT network, which in your case would be 172.16.117.132. No changes to NAT port forwarding are necessary.

If you want to connect to the VM from another system on the network, I'd suggest configuring the VM for Bridged networking. It will have its own IP address on the network.  The default port connection of 3389 will work.

If you want to connect to the VM from another system and want to use NAT networking, then you'll need to configure NAT port forwarding. I generally don't advise editing vmnet8/nat.conf -- instead create a custom virtual network similar to this (with a different IP range than the default NAT network):

As you can see here, I've configured a new virtual network vmnet4 - with NAT, DHCP, and connecting the host Mac to this network. That's similar to what vmnet8 (the default NAT network) does. I then configure the VM to use vmnet4 for the virtual adapter instead of "Share with my Mac".

However, unlike the default NAT "Share with my Mac", this custom network now has GUI support for NAT port forwarding. If configuring port forwarding, I'd recommend using an unused port of your choosing (I chose 17501 as an example). The VM IP address will be that of your VM and port 3389. This also gives you the ability to configure RDP into another VM running in the NAT network (just use another host port and point the VM destination port to port 3389 of the addiitional VM).

Then you can use <host ip>:17501 as the PC name to connect to the VM.

Just prototyped this, It all works.

[NC CH]

I have tried reinstalling the VM Tools and it still not working.. getting the following message

Are you able to create a new VM just to isolate the issues to see if this actually works.

Start VMware Fusion
File > New Get Windows From Microsoft and following through the Windows 11 setup. *Side Note. I am using Local Account for the creation of user using oobe\bypassnro
Once Windows 11 Arm VM Created,

 go to VMMenu Virtual Machine > Install VM Tools and reboot the Windows 11 Arm VM 
 once Windows 11 Arm VM rebooted,
 go to Settings > System > Remote Desktop and Enabled it.
Open Windows App on the Mac Host and Connect

I did this Windows 11 Arm set up several times and just not able to connect to the VM. getting the above error screenshot.

[Technogeezer]

My VM was built from scratch as well. I did not go through the OOBE\bypassnro hack to get a local account - I instead chose to use a school or work account instead of a Microsoft Account, then specified that I was going to domain join the system. That let me create a local account.

I do note that you have the "Optimize for Retina Displays" checked in your Windows App configuration. I don't have a Retina display, so mine is unchecked. You might want to uncheck that option to see if it makes a difference (I'm wondering if the option tries to set HiDPI in the guest, which the VMware video driver doesn't support).

I did a little research in Microsoft forums and found a similar issue reported on physical systems. The solution in those instances were to disable Remote Desktop in the VM, uninstall the video driver (e.g. uninstall VMware Tools), re-install the video driver (e.g. install VMware Tools)), then re-enable Remote Desktop.

When testing this out, I'd try to connect with Windows App directly to the IP of the VM (not use the host IP). The host Mac is connected to the "Share with my Mac" virtual network, so connecting to the IP of the VM for testing will remove one component from the debugging path. Not that I think that the NAT redirection you've configured is a problem - I've been able to get that to work.

[NC CH]

I have tried both your methods on Retina Display Option Unchecked and also disable Remote Desktop in the VM, uninstall the video driver (e.g. uninstall VMware Tools), re-install the video driver (e.g. install VMware Tools)), then re-enable Remote Desktop.

none of those works. 

I tried using ur VM Setup Method using personal acct and let u know the outcome.

[NC CH]

I am totally confused now.. lol.

Senario 1. 
I did ur method using personal account. it works and hardly failed when I tried doing the RDP again so I tried create a local account on that machine and it also works..  no issues for both account type when trying to RDP VM again..

Senario 2 - Local Account 
Once Windows 11 arm installed and loaded. I go to the VM menu install VM Tools
Reboot the VM
Go enabled Remote Desktop Settings.
Connect VM using Windows App on Mac Host
After the login. Spinning Icons just stop spinning.. Hang.
I tried connect again and get the error message The graphics display components in the remote session failed to start up.

Senario 3 - Local Account 
Once Windows 11 arm installed and loaded. I straight off go to https://packages.vmware.com/tools/releases/12.5.0/windows/arm/ and install the VM tools
Reboot the VM
Go enabled Remote Desktop Settings.
Connect VM using Windows App on Mac Host
FINALLY it works. but once I close the window App and try remote again I will get the error message The graphics display components in the remote session failed to start up.
if I create another account and remote again it works.. but will failed when u try again

[Technogeezer]

That is strange, indeed.

I'm going to rebuild my Windows 11 Pro VM using what I think are the steps you did.

• Use Get Windows from Microsoft in the Fusion "Choose the installation source" dialog.
• Use the OOBE\bypassnro hack to create a local user
• Download the VMware Tools from the link you posted and install them.

Let me know I've gotten this wrong....

I'll report back on what I find.

[Technogeezer]

VM rebuilt - for some reason the OOBE hack didn't seem to change much. I still had to go through the path to use a work or school account, then when the Microsoft Account prompt window was displayed, selected Other options, and then selected the domain join option. Then it would let me create a local user.

Everything seems to work. Even when I make che change to vmnet8 to allow port 3389 on the host to be NAT port forwarded to port 3389 of the VM.

Logging in and out via the Windows App works fine every time for me.

I assume that

• you provided a hostname for your VM during installation
• when you installed VMware Tools,  you chose the "Complete" option.

Unfortunately I don't have a system with a Retina display so I can check out whether that's a consideration here.

[NC CH]

for some reasons, you need to disconnect ur Network Adapter before issuing the oobe\bypassnro cmd. Basically before booting from the CD.
I had experienced your issues as well.

• you provided a hostname for your VM during installation - Yes
• when you installed VMware Tools,  you chose the "Complete" option. -Yes

as for Retina Display.. I don't think that an issues as I am able to the same but using Parallels as my virtual machine  all works fine..

[NC CH]

May I check somethings with you on the following..

If vm setup for the network is 

and my ip is 

Am I able to use this 192.168.145.130 to connect using Windows App RDP from Mac Host

[NC CH]

I am able to replicate the issues successfully.
out of the box vm creation from VMWare Fusion should works be it local or microsoft account.
connect and reconnect using Window App From Mac Host works at this point.

it will stopped working when windows updates on the following.

After update and reboot. I used Window App and connect the vm and will get the error message.

[MWunder]

I know it worked when I first did it.  I agree with NC CH that an update messed it up.  I was going crazy wondering if I was imagining that it worked.  Hopefully an update from either MS or Fusion will fix it.  Doing VPN and screen share using the Apple built in is not great.  Workaround is using tightVPN.  Not as nice as Windows App but works.

[Technogeezer]

Just for grins, if you have another Windows system, can you RDP from that system into the Windows 11 ARM VM? That would at least isolate whether the issue is with the VM itself or is it more likely an issue with the Windows App on the Mac?

[MWunder]

I'll give it a try.  However, I have another Windows 11 PC that I have no issues with doing RDP from my Mac both on the LAN and via VPN.

[stainless steelrat]

So I also have just started to get the issue. It was working fine yesterday. Today, when I try to rdp it gives me either a black screen or the error code 0x11. 

The only updates that got installed yesterday seem to be new virus/defender updates. 

I'm running windows 11 arm 24H2 (26100.3194)

Host is a M1 pro, with Sonoma 14.7.3

bridged networking. I tried to access from another mac / rdp and same situation. 

Fusion version 13.6.2 & 13.6.3
vmware tools reinstalled for both. 

I can login directly to the console no problem, but of course the full screen is much more of a pain. Rdp used to be great for that.

As I say its very weird that it just started overnight. 

[MWunder]

Tried again with a Windows 10 Surface.  It would log into the Win 11 Arm via RDP but the screen was just all black and would then disconnect.  Seems to be the issue is with the Windows 11 Arm VM.

[Jason Wilinski]

I had been wrestling with this problem for the past week. I fiddled with every RDP-related setting Group Policy Editor to no avail. Just when I was about to give up hope, I noticed that Windows Update was offering this:  2025-02 Cumulative Update Preview for Windows 11 Version 24H2 for arm64-based Systems (KB5052093)

I installed it and now my Remote Desktop works perfectly! I hope this fixes it for you, too!

[Husheng Zhou]

We observed the same issue on Win11-ARM64-24H2 with recent Windows update too. It seems like a Windows session manager issue (just a theory, we haven't confirmed with Microsoft yet). Without any change at VMtools side (VMtools-12.5.0 is recommended). Do sign out TWICE can sometimes resolve the issue. Try this on your Win11-ARM-VM: Sign out -> login -> Sign out again, leave it not signed in. Then use RDP from another machine (physical or VM) to connect to the VM.

If it doesn't work, can you help to narrow down the scope. Uninstall SVGA driver from Device Manager by Device Manager ->  Display Adapters -> VMware SVGA 3D -> right click -> Uninstall device -> Check "Attempt to remove the driver for this device" -> Uninstall. Then reboot and make sure the current display driver is Windows basic display driver. Then try RDP to this VM again. If still not working, then it should not be VMtools issue.

[MWunder]

Signing out twice did not work.  It got a little closer by giving me a black screen.  Trying again doing double sign out then gave the normal error 0x11.

Changing the display driver and verifying that it was the basic driver also did not work and produced the same error 0x11.

[Technogeezer]

Microsoft has released the latest cumulative update preview for Windows 11 (KB5052093 - OS Build 26100.3323). It just showed up as I have the "get the latest updated" enabled. 

The notes for this preview release indicate that there are two fixes for Remote Desktop:

[Remote Desktop]

• • Fixed: There are display rendering issues when you connect to certain PCs.
  • Fixed: It stops responding. ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

Might be interesting to see if this has any impact on the problem. 

[MWunder]

Did not resolve the error.  No change.  :-(

[Technogeezer]

@stainless steelrat - The 2025-02 Cumulative Update Preview for Windows 11 Version 24H2 for arm64-based Systems (KB5052093) update that i noticed and that @Jason Wilinski also found will only appear if you have "Get the latest updates when available" is enabled in Windows Update. 

If you don't have that enabled, try turning it on and see if you're offered the preview. You can then install it and see if it solves the issue. 

[Jason Wilinski]

I was wondering why KB5052093 resolved my problem, but it didn't work for @MWunder, so I double-checked my group policy settings. It turns out, I accidentally left this one set to Enabled:

Local Computer Policy> Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Select network detection on the server - set to Enabled, then choose "Turn off Connect Time Detect and Continuous Network Detect" from the dropdown menu in the lower panel.

I switched that setting back to Not Configured and then ran gpupdate /force. Lo and behold, the Error Code 0x11 came back!

Unfortunately...  now I'm completely broken again and toggling the group policy setting no longer helps. I even tried removing and reinstalling KB5052093, but that didn't help either.

Maybe someone else will have another idea based on my results.

[stainless steelrat]

@technogeezer

I create a snapshot prior to trying the recommended preview update file, however, no matter how I install it. It makes no change (other than always producing the error 0x11 (vs blank screen or error). I am currently in a "restored state".

I checked the local group policy editor, and it shows the "default", not configured for all the rdp settings.

I haven't seen anything that jumps out in the eventvwr as well, but maybe I need to go through the rdp events again.

[Husheng Zhou]

One workaround of this issue is to use VM's build-in VNC. To enable Fusion's build-in VNC, shut down your VM, and then go to VM's settings -> Advanced -> Check "Remote display over VNC" -> Change port or password as needed. Boot your VM and then use any VNC client to connect to the VM using VM's IP:PORT (5900 by default). Make sure your VNC client and the VM are within the same subnet (using bridged network for VM makes things easier).

[LUYAO PENG]

Same issue, I tried to install KB5052093 but with failure. 

So I joined windows insider beta channel, and upgrade to 26120.3360, remote desktop works fine.

Updated: After reboot, I could not connect to Windows 11 beta via Windows App again. I reinstalled another vmware system by ISO which downloaded from microsoft website, and the build number is 26100.3476, no issue occurred.

I guess, bug code was introduced by microsoft in previous updates and fixed now.

[Technogeezer]

@LUYAO PENG - that sure seems to indicate that it's a Microsoft problem if the Beta channel build works but the release channel version doesn't. 

Have you tried the latest release channel build, Another user with this problem (see https://community.broadcom.com/vmware-cloud-foundation/discussion/remote-desktop-error ) seemed to indicate deleting the "Windows Remote Desktop Display" device in the Windows Device Manager,  then rebooting the VM to allow the device to be re-created got around the issue.

[MWunder]

Technogeezer's find about the remote display adapter worked for me.

Steps that I did.

Go to Device Manager and select View>Show hidden devices

Go to Display adapters and expand.  You will notice a slightly faded out new driver listed

I selected it and right clicked on it.  Then Uninstall device

I then restarted Windows.  When it boots back up it will not automatically add that driver back in and "Scan for hardware changes" didn't help.  Disabling and enabling Remote Desktop feature did nothing too.  What finally did add it back in was initiating an RDP to that computer, in this case the VMWare session running.  Worked like a charm.

Now I just need to see if it sticks when I try via VPN.

[stainless steelrat]

I had to shutdown my guest instance the other day. When I restarted it, it started to exhibit the same 0x11 symptoms again. Just removed the virtual display adapter again, and then rdp started to work normally. Will monitor, since I had to shut the guest down again today.

[MWunder]

Verified that I can use RDP via my VPN connection too.  Yay!

[MWunder]

@stainless steelrat For reference:  I restarted windows, shut down guest, even updated Fusion.  RDP still worked.

[MWunder]

Update.

I had one instance where I had to delete the MS Remote Display Adapter to get RDP access again.

Second instance was updating to cumulative update KB5055523 broke it again.  I did discover all you have to do is delete the MS Remote Display Adapter and then try RDP access again.  No reboot was necessary and it worked right away.

Conclusion...not fixed but pretty easy workaround if you can get access to the Windows session by other means.  I use MacOS built in screen share over VPN.

[stainless steelrat]

FYI.... 

I installed the patch Tuesday patches for april this morning. RDP which had been working ok, gave me a blank screen. But after accessing through the console directly, it installed one more patch:

Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.427.153.0) - Current Channel (Broad)

After putting that on, rdp continued to work normally. Will continue to monitor. 

Hopefully I'll be able to access from a windows 10 machine to this guest again. It worked find from another mac (older rdp client).

[MWunder]

Unfortunately, this issue seems to be getting worse than better.  I am having to delete the MS Remote Display Adapter almost every other time I try to connect.  Bummer.  Anyone else notice this?  Any other options other than a third party VNC program?

[Blagovest Karakashev]

I am having the same issue, and uninstalling the RDP Display driver only works once. After I log in and end the session, the RDP Display driver is back, and the remote access doesn't work. 

[stainless steelrat]

Just installed the july 2025 patches into my vm guest, and on first reboot. RDP was able to connect but not draw the desktop. (blank screen with mouse, old windows95 death pause days). After disconnecting and retrying it. The good old 0x11 error was back. Deleted the device from device manager, and it starts to work properly. 

@MWunder -- I find that if you connect over rdp from one device, it will continue to work. If you connect from a different device, (so the client monitor has a different resolution) it will require you to delete the display adapter. 

@Technogeezer -- I haven't tried it yet to know, but I just downloaded fusion 13.6.4..... to try it. Do you know if there's a newer vmware tools package to use yet?

[Technogeezer]

Fusion 13.6.4 sees to be bundling VMware Tools 12.5.3. That's the latest of the VMware Tools 12.5.x release series. 

There is a newer version of VMware Tools that just became available. VMware Tools 13.0.1 looks to contain a security fix. It does have a newer video driver for Windows ARM than 12.5.3. Whether that fixes this particular issue has not been determined. 

[MWunder]

@stainless steelrat I have noticed that too.  I also have noticed that deleting the RDP video driver doesn't always work.  I have found if I go in and delete the video driver and it doesn't work, I then turn off RDP and back on.  Then I can connect.  I do this remotely by first logging into my Mac via screen share, do the work with a jumpy mouse in Windows Arm.  Then use RDP on that Mac to make sure the RDP works.  Then connect via the remote PC via RDP.  Not too many hoops to jump through.  I reverted back to using Tight VNC for now as I was getting annoyed with it.

Going to check out the updates.  Though I feel this is a MS issue not VMWare issue.  That is just a guess though.

[stainless steelrat]

@Technogeezer -- thanks. I have installed the 13.0.1 vmware tools package now. I used the windows arm exe inside the guest. I haven't upgraded to fusion 13.6.4, I'm still on 13.6.3 for now.

@MWunder -- While I haven't played from different clients yet. July patches + the 13.0.1 vmtools seems to be helping. 

I've been having fun trying to get a "work" account setup over the last day or so. That is not relevant to this discussion though. "new thread" here we go.

[Technogeezer]

@stainless steelrat if you're having problems setting up that work account, you might want to post in the Water Cooler community for help. You're more likely to get a helpful answer there than here as some of the Broadcom community managers hang out there.

[MWunder]

@stainless steelrat I just wish Fusion would autoupdate like it used to.  Figured out how to get updated tools and will be trying RDP out later.

[stainless steelrat]

@Technogeezer -- thanks for the tips. The only reason I would post here, would be to see if anybody has been able to do it. I keep getting an error that implies even though I'm using the tpm, with a pin.... its not really recognized.

@MWunder -- this manual updating is a pain, I agree.

[Technogeezer]

@stainless steelrat I think I misunderstood your account creation question. I thought you meant a Broadcom account - which would be appropriate for the Water Cooler. From what you last posted, it sounds instead like you’re talking about a Windows account in the VM. 

[MWunder]

@stainless steelrat What are you trying to do with the work account?  We have Office 365 but I do not log into my work account on the VM machine since I am already logged in on my Mac.  I also enter a pin when logging in.  Maybe I can help, but I don't understand what you need.

[stainless steelrat]

@Technogeezer -- thanks. I hope I didn't cause any trouble. ;-) I got a few people from vmware who are going to help... maybe engineering can use it as a good test case.

@MWunder -- Thanks. I have company portal installed on the mac, and it's been working well. The problem is the corporation has bought some customized technical writer software which only works in windows, with the full desktop copy of word. So I need to be able to access the sharepoint from the guest to be able to test / work through the configuration.

I was able to make it work, by doing an "entra join", which allowed me to "sign in" as my work account. I wasn't planning on working that way. And I would prefer to just use a work account but I can do what I need. 

If I try company portal under my personal while joined, its fine then. If I disjoin it from the entra, it goes back to the same problem. So it's either a problem with my personal profile.... or something else really weird.

[B Beh]

Has anyone been able to find a solution to this? Seems like an update in windows has created this issue for me, never had a problem before.