Error on Windows 11 ARM with latest Visual Studio 2022 Community components (17.14.3)

All my recent Swift configurations on Windows 11 ARM ran smoothly with Visual Studio 2022 Community 17.13.3.

Now, using the latest version of Visual Studio Community 17.14.3, a simple Swift Hello World app returns errors like the following:

....

C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um\winnt.h:5845:11: error: reference to '_ARM64_BARRIER_ISHST' is ambiguous
 5843 |     )
 5844 | {
 5845 |     __dmb(_ARM64_BARRIER_ISHST);
      |           `- error: reference to '_ARM64_BARRIER_ISHST' is ambiguous
 5846 |     __yield();
 5847 | }

....

C:\Program Files (x86)\Windows Kits\10\\include\10.0.26100.0\\um\winnt.h:6164:11: error: reference to '_ARM64_BARRIER_ISH' is ambiguous
 6162 |
 6163 | {
 6164 |     __dmb(_ARM64_BARRIER_ISH);
      |           `- error: reference to '_ARM64_BARRIER_ISH' is ambiguous
 6165 |     return;
 6166 | }

Since it's not possible to install an older version of Visual Studio Community, this is very annoying.

Is this a problem with the MSVC compiler and should we wait for a fix from Microsoft? Or is it a future fix for the Swift installer for Windows ARM?

This is on the Swift side due to the use of clang over cl/MSVC as the C/C++ compiler (and/or potentially the ClangImporter). I would suggest that you test a more recent than the most recent nightly (which is about 2 months old now - CC: @mishal_shah).

I would grab something from GitHub - thebrowsercompany/swift-build: Swift toolchain builds by The Browser Company as that has more recent builds and test that.

Just installed 20250602.1

swift --version
compnerd.org Swift version 6.2-dev (LLVM 5e7837820b1c886, Swift d49dd182ed79c1d)
Target: aarch64-unknown-windows-msvc
Build config: +assertions

With the same result.

Today I tested how updating Visual Studio Community to the latest version (17.14.3) behaves on Windows 11 Intel.

My original Swift setup on Windows 11 Intel was Swift 6.0.3 with Visual Studio Community 17.13.3, and everything worked fine.

After updating to Visual Studio Community 17.14.3, Swift app no longer compiles, with errors as follows:

C:\Users\admin\AppData\Local\Programs\Swift\Toolchains\6.0.3+Asserts\usr\lib\swift\clang\include\mm_malloc.h:13:10: error: cyclic dependency in module 'ucrt': ucrt -> _Builtin_intrinsics -> ucrt
11 | #define __MM_MALLOC_H
12 |
13 | #include <stdlib.h>
| `- error: cyclic dependency in module 'ucrt': ucrt -> _Builtin_intrinsics -> ucrt
14 |
15 | #ifdef _WIN32

I then removed Swift 6.0.3 and installed today's build 20250603.1. And the app compiles fine again.

I tried the same thing on a Windows 11 ARM setup with ARM build 20250603.1, but the same issues I mentioned above still occur.

What I've learned in general is that a Swift installation version on Windows is dependent on a specific version of Visual Studio components. We can't simply install Visual Studio Latest and be sure Swift app compiling will work. Furthermore, the Swift installers for Windows ARM and Intel may depend on different versions of Visual Studio.

If what I mention is correct, I strongly recommend mentioning on the Windows installation page the specific required version of Visual Studio for each version (latest and older) of the Swift installers for Windows Intel and ARM. This will save us from trial-and-error iterations trying to find the right combination.

Sadly Microsoft broke this with the latest Windows 11 SDK release. You can only use up to Windows SDK 10.0.22000.0. Using a newer SDK causes problems.

There is a regression on Windows ARM64 that we did not know about. This was due to our internal tests using a pinned SDK version.

This is an unsolvable problem - just like on Linux. Apple tests and ships a SDK that is known to work with modules. Microsoft and arbitrary vendors (aka Linux) do not ensure that their headers are modularised or even if they can be modularised. We retroactively modularise the headers. If their changes in a release include changes to the header structure that does not work with the existing module definition, the older Swift SDKs will not be able to consume the Windows SDK. This is just the plain reality of Clang modules which are required for interoperability.

It is not the version of Visual Studio, it is the SDK version. The best option that we have to address this is to have toolchains become even more expensive and increase developer friction. We could build and ship ~10 different Windows SDKs (e.g. Windows-10.0.22000.0.sdk, Windows-10.0.26100.0.sdk, Windows-10.0.26100.3461.sdk), and then require that you specify the SDK or use tcrun to select the SDK.

Just for the record, you can always install older VS versions using the fixed bootstrappers here: Visual Studio 2022 Release History | Microsoft Learn

But @compnerd, just for clarity, are we saying that VS 17.14.3 works, so long as you install an older Windows SDK (e.g. 22000)? Just want to make sure that the instructions are clear.

(Just adding to the record: To my knowledge not for the community versions.)

Yes this is my actual workaround. Using the 17.13.3 Build Tools.

https://download.visualstudio.microsoft.com/download/pr/9b2a4ec4-2233-4550-bb74-4e7facba2e03/00f873e49619fc73dedb5f577e52c1419d058b9bf2d0d3f6a09d4c05058c3f79/vs_BuildTools.exe

In my tests cases this work with Swift 6.0.3 to the latest on Windows 11 ARM and Intel.

I think too we need clear installation instructions according to MSVC and SDK versions.

I would suggest testing, I know that there was at least one VS Tool Set that did introduce an issue as well.

I've definitely been able to use the versioned bootstrappers to do this in the past.

Note that there is a second class of issues that show up: namely that we use clang rather than cl. More importantly, we are normally using an old clang (at least 1 year old), and the Microsoft STL headers often aggressively use new features.

1 Like

Technically, 6.0.3 isn't a supported release. Windows basically has a 3 version window:

  1. stable (currently 6.1.x)
  2. beta/rc (currently release/6.2)
  3. development (main)

The amount of work that it takes to keep main stable means that we cannot realistically support a wider window.

Your right, just resolved my problem on Windows 11 Intel with latest VS Community 17.14.3 by using the Windows SDK 10.0.22000.0.

I take note about current stable is 6.1.x and will adjust our Swift dev setup according.

On the ARM side, I stick on VS Build Tools 17.13.3 for now.

Update on the ARM side: Just tried Swift latest build 20250603.1. with VS Community 17.14.3 and Windows SDK 10.0.22000.0 with success ! So common denominator seams to use SDK 10.0.22000.0.

Btw Microsoft just updated Visual Studio Community to.. 17.14.4.
To continue..,