windows-2025 label is serving the windows-2025-vs2026 image (VS 2026 path layout); breaks VS 2022 paths

[Fedr]

Description

As of approximately 2026-05-05 12:36 UTC, jobs using runs-on: windows-2025 are being scheduled onto the windows-2025-vs2026 image (Visual Studio 2026 at C:\Program Files\Microsoft Visual Studio\18\Enterprise) instead of the documented windows-2025 image (Visual Studio 2022 at C:\Program Files\Microsoft Visual Studio\2022\Enterprise).

This silently breaks workflows that target the VS 2022 path layout — including a very common pattern: copying NVIDIA CUDA's MSBuildExtensions\* into <VS-root>\MSBuild\Microsoft\VC\<vXXX>\BuildCustomizations\ so MSBuild can build CUDA projects.

The windows-2025-vs2026 label is itself documented as a separate, beta image (see #13638 / #13986). Routing the non-beta windows-2025 label to that beta image is what's causing the regression.

Platforms affected

• GitHub Actions - Standard Runners

Runner images affected

• Windows Server 2025

Image version and build link

Failing job (uses runs-on: windows-2025, gets served vs2026 image):

• Run: https://github.com/MeshInspector/MeshLib/actions/runs/25379948034/job/74425308134
• Reported runner image:

  Image: windows-2025-vs2026
  Version: 20260419.77.1
  Image Release: https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260419.77
  

• Another failing run a few minutes later, served a different vs2026 build:

  Image: windows-2025-vs2026
  Version: 20260428.85.1
  Image Release: https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260428.85
  

• The matrix entry that requests the runner is unambiguous: https://github.com/MeshInspector/MeshLib/blob/master/.github/workflows/matrix/windows-standard-config.json#L9 — "runner": ["windows-2025"].

Is it regression?

Yes. The same runs-on: windows-2025 request was correctly served the windows-2025 image earlier the same day:

• Last successful run on master at 2026-05-05 12:04 UTC: https://github.com/MeshInspector/MeshLib/actions/runs/25375209757
• Reported runner image:

  Image: windows-2025
  Version: 20260419.89.1
  Image Release: https://github.com/actions/runner-images/releases/tag/win25%2F20260419.89
  

• First failing run on master, ~32 minutes later (2026-05-05 12:36 UTC): https://github.com/MeshInspector/MeshLib/actions/runs/25376730406 — the only relevant change between these two runs is the runner image label-to-tag mapping.

Expected behavior

runs-on: windows-2025 should be served the windows-2025 image (currently win25/20260428.110, with Visual Studio Enterprise 2022 17.14.x at C:\Program Files\Microsoft Visual Studio\2022\Enterprise), per the Windows-2025 readme. The VS 2026 image should only be served when explicitly requested via runs-on: windows-2025-vs2026.

Actual behavior

runs-on: windows-2025 is being served the windows-2025-vs2026 image. That image installs Visual Studio at C:\Program Files\Microsoft Visual Studio\18\Enterprise\ instead of C:\Program Files\Microsoft Visual Studio\2022\Enterprise\. Any path string referring to the 2022 location now points at a directory that doesn't exist, e.g.:

gi 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\*\BuildCustomizations'

Cannot find path 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC'
because it does not exist.

(See the failing job log around the Install Visual Studio Integration step.)

Repro steps

1. Create a workflow with:

   jobs:
     probe:
       runs-on: windows-2025
       steps:
         - shell: pwsh
           run: |
             "Image label requested: windows-2025"
             Test-Path 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise'
             Test-Path 'C:\Program Files\Microsoft Visual Studio\18\Enterprise'

2. Run it.
3. Observe: Image: windows-2025-vs2026 in the job's "Runner Image" group, and the \2022\Enterprise path test returns False while the \18\Enterprise path returns True.

Workaround

Pin the matrix to a specific image build number rather than the floating windows-2025 label, or update the workflow's hardcoded VS paths to be VS-version-agnostic (resolve via vswhere -property installationPath). Neither is a substitute for the floating label routing to the documented image.

[Meakk]

We also noticed a regression on our side. Jobs running on windows-2025-vs2026 (labelled as windows-2025) consistently fail when running two specific tests.
These two tests are checking failures when loading a dynamic library, so it may (or not) be related to that.

https://github.com/f3d-app/f3d/actions/runs/25375946580/job/74452338292#step:3:4641

[Pierreluc14]

@v-sergei-pyshnoi windows-2025 will be replaced to windows-2025-vs2026 on May 12 ?