Missing atlbase.h file in windows-2022 runner

Description

We have a CI pipeline that stopped working from 16hrs ago. It is in a private repository and there is no code change in it for weeks.

This is the error we are getting -

fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory

It uses windows-2022 runner

worked yesterday: https://github.com/actions/runner-images/blob/win22/20240421.1/images/windows/Windows2022-Readme.md
broken today: https://github.com/actions/runner-images/blob/win22/20240514.3/images/windows/Windows2022-Readme.md

Since there was no recent changes to our repository there must be some changes to the windows-2022 runner that made altbase.h no longer available when compiling
I see the package name in win22/20240514.3 is Microsoft.VisualStudio.Component.VC.ATL which is different from the previous release.

We also filed an issue with microsoft for this - microsoft/setup-msbuild#127

Platforms affected

Azure DevOps
GitHub Actions - Standard Runners
GitHub Actions - Larger Runners

Runner images affected

Image version and build link

Image: windows-2022
Version: 20240514.3.0
Included Software: https://github.com/actions/runner-images/blob/win22/20240514.3/images/windows/Windows2022-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/win22%2F20240514.3

Is it regression?

Yes, it was working in version 20240421.1.0

Expected behavior

We should not see 'atlbase.h' not found error.

Actual behavior

Seeing error that 'atlbase.h' file is not found.

Repro steps

Run a workflow like this and try to build any C++ Visual Studio project which imports this header file -

name: CI
on:
  push:
    branches: [ 'main', 'releases/**' ]
  pull_request:
    branches: [ '**' ]
  workflow_dispatch:
  # Allow manual trigger for debugging the workflow.
jobs:
  CI-checks:
    runs-on: windows-2022
    steps:
      - name: Disable git autocrlf
        run: git config --global core.autocrlf false

      - uses: actions/checkout@v4

      # The msbuild version is dictated by the Windows image provided by GitHub.
      - uses: microsoft/setup-msbuild@v2
      - uses: darenm/Setup-VSTest@v1.2
      - name: Build and test with Sonar Wrapper
        shell: cmd
        run: test-all.cmd

@kanak-clumio

Hey @kanak-clumio!

Take a look here, please: #9701
We excluded multiple Visual Studio 2022 VC components from the image due to a bug in VS which blocks other images users. I may recommend you to add necessary components/version in runtime using snippet:

    steps:
      - name: Delete components
        run: |
                Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\"
                $InstallPath = "C:\Program Files\Microsoft Visual Studio\2022\Enterprise"
                $componentsToRemove= @(
                    "Microsoft.VisualStudio.Component.VC.ATL"
                )
                [string]$workloadArgs = $componentsToRemove | ForEach-Object {" --remove " +  $_}
                $Arguments = ('/c', "vs_installer.exe", 'modify', '--installPath', "`"$InstallPath`"",$workloadArgs, '--quiet', '--norestart', '--nocache')
                # should be run twice
                $process = Start-Process -FilePath cmd.exe -ArgumentList $Arguments -Wait -PassThru -WindowStyle Hidden
                $process = Start-Process -FilePath cmd.exe -ArgumentList $Arguments -Wait -PassThru -WindowStyle Hidden
      
      - name: Install components
        run: |
                Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\"
                $InstallPath = "C:\Program Files\Microsoft Visual Studio\2022\Enterprise"
                $componentsToRemove= @(
                  "Microsoft.VisualStudio.Component.VC.v141.ATL"
                  "Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL"
                )
                [string]$workloadArgs = $componentsToRemove | ForEach-Object {" --add " +  $_}
                $Arguments = ('/c', "vs_installer.exe", 'modify', '--installPath', "`"$InstallPath`"",$workloadArgs, '--quiet', '--norestart', '--nocache')
                # should be run twice
                $process = Start-Process -FilePath cmd.exe -ArgumentList $Arguments -Wait -PassThru -WindowStyle Hidden
                $process = Start-Process -FilePath cmd.exe -ArgumentList $Arguments -Wait -PassThru -WindowStyle Hidden

@kanak-clumio

@kanak-clumio
I'll wait for your response. One version of the ATL package must contain a header file:

                  "Microsoft.VisualStudio.Component.VC.v141.ATL"
                  "Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL"

I recommend reporting the bug to the Visual Studio Developer Community to understand why it was excluded in the latest version of Component.VC.ATL.

@erik-bershel

@erik-bershel uninstalling and re-installing the ATL component seems to fix the compilation issue but it add 5-6m to the runs.
We found that the missing header is actually present on disk at:

/c/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.39.33519/atlmfc/include/atlbase.h

So we believe that it was just not installed properly and not added to the import paths of the compiler. If there is a faster way to make the existing atlbase.h discoverable that might be good enough.

@sodul

Hey @sodul!

Glad to hear that we localised bug. Appreciate your effort! Would be very nice if you report this bag to the Visual Studio so they can fix it for other users.

Same time I found a discussion on SO: https://stackoverflow.com/questions/3898287/c-include-atlbase-h-is-not-found

There were mentioned two options:

After that add additional VC++ directories in the project properties:

Include directories: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\atlmfc\include
Library directories: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\atlmfc\lib\x86
The VC++ compiler should now be able to find the ATL source and library files.

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>mklink /d atlmfc "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib>mklink /d amd64 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib\x64

I am sure that the second one will definitely work if you correct a path.

This action might be also a solution (a workaround to be honest) of the issue: https://github.com/marketplace/actions/setup-msvc-developer-command-prompt

@sodul

Hey @sodul!

This #9876 should solve your issue I think.

@erik-bershel

Thanks @erik-bershel for the help!

I've made a change to add the workaround you suggested of deleting and adding components so that our CI goes through. This increases the build time by 7 min but we can manage it till your above change is available in the next windows-2022 runner version.

Had the same issue today when we merged another PR in our project. https://github.com/Phobos-developers/Phobos/actions/runs/9141719975/job/25136537634

Is it possible to somehow revert to the previous runner version where it was working?

Is it possible to somehow revert to the previous runner version where it was working?

Nope. Only to wait for the next release or to update ATL library in runtime.

The developer community issue was closed with exactly the same work-around as this issue, which is no help at all. Could you please figure out whose responsibility it is and come up with an approach to fix it together?

In the meantime, this issue should be reopened.

I would add that the feedback from Microsoft was to make config changes through the Windows UI, even though the issue was specifically mentioning GitHub pipelines. It seems like an issue where the left hand is not talking with the right hand and the final customer is in between. Since GitHub is owned by Microsoft I consider this to be 100% a Microsoft regression that Microsoft and its subsidiaries need to resolve for their paying customers.

🧪 (manually install missing VS components on windows)

Apparently this bug is still here: https://github.com/CnCNet/yrpp-spawner/actions/runs/13531026351/job/37813576891
Please reopen the issue.

The workaround previously mentioned is good for a stop gap measure. It adds quite a bit of time to the pipeline run as it takes quite a while to remove/re-install the components.

I slightly modified the above proposed workaround to the bare minimum install I needed, avoid cmd, and a few additional styling adjustments:
Avasam/pywin32@711ddb1#diff-7829468e86c1cc5d5133195b5cb48e1ff6c75e3e9203777f6b2e379d9e4882b3R65-R82

      - name: Install missing Visual Studio components
        run: |
          Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\"
          $VsInstallPath = vswhere.exe -latest -products * -requires Microsoft.Component.MSBuild -property installationPath
          [string]$ComponentsToAdd = @(
            "Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL" # for windows-2022
            "Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL.ARM64" # for windows-11-arm
          ) | ForEach-Object {"--add $_"}
          $ArgumentList = ('modify', '--installPath', "`"$VsInstallPath`"", $ComponentsToAdd, '--quiet', '--norestart', '--nocache')
          echo "vs_installer.exe $($ArgumentList -join ' ')"
          # should be run twice for some reason
          Start-Process -FilePath vs_installer.exe -ArgumentList $ArgumentList -Wait -PassThru -WindowStyle Hidden
          Start-Process -FilePath vs_installer.exe -ArgumentList $ArgumentList -Wait -PassThru -WindowStyle Hidden

After experimenting, I found that I didn't need to first remove the components. (same speed to remove + install than it is to just call install)
I also found that the exact MSVC + VS version combo of 14.29&16.11 is also what I need, despite vswhere.exe -latest giving me different results.

Adding ~8-12 minutes to every CI run isn't great. I also don't understand why we need to run the installation twice.

Why does vs_installer need to be run twice? And is there anyway to cache this installation across runs? Taking an extra ~8-12 minutes per job is really awful.

We just stumbled onto this issue, because of the deprecation of the windows-2019 runners and the need to upgrade to 2022 oder 2025 runners.
Hitting the same problem. Would be great if those headers were available from the start, without the need to reinstall anything.

Likewise now having trouble with this due to deprecation of windows-2019. The workaround is not acceptable due to the steep amount of extra time it adds to the workflows.

Additional issue with the provided workaround:
Neither Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL nor Microsoft.VisualStudio.Component.VC.14.29.16.11.ATL.ARM64 seem to work for the windows-11-arm runner. Back to having fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory on there: https://github.com/mhammond/pywin32/actions/runs/16503124706/job/46666815444?pr=2581#step:10:101

Work around missing ATL include path on GitHub-hosted Windows runners

Navigation Menu

Repository navigation

Missing atlbase.h file in windows-2022 runner #9873

Description

Platforms affected

Runner images affected

Image version and build link

Is it regression?

Expected behavior

Actual behavior

Repro steps

43 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Missing atlbase.h file in windows-2022 runner #9873

Description

Description

Platforms affected

Runner images affected

Image version and build link

Is it regression?

Expected behavior

Actual behavior

Repro steps

Activity

erik-bershel commented on May 16, 2024

erik-bershel commented on May 16, 2024

sodul commented on May 16, 2024

erik-bershel commented on May 16, 2024

erik-bershel commented on May 16, 2024

erik-bershel commented on May 17, 2024

kanak-clumio commented on May 17, 2024

Metadorius commented on May 18, 2024

erik-bershel commented on May 18, 2024

43 remaining items

h-vetinari commented on Jul 24, 2024

sodul commented on Jul 24, 2024

Metadorius commented on Mar 17, 2025

hudsy13 commented on Mar 21, 2025

Avasam commented on Apr 27, 2025

Avasam commented on May 2, 2025

KerstinKeller commented on Jun 5, 2025

Starkku commented on Jun 10, 2025

Avasam commented on Jul 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions