getFileId() error in windows docker container

We are using cppcheck in a Windows Docker container (windowsservercore-20H2) and have noticed that the function simplecpp::FileDataCache::getFileId() does not work.

This is because the Windows API function GetFileInformationByHandleEx is not available in the Docker container (Error 50: ERROR_NOT_SUPPORTED). We also tested this on windowsservercore-ltsc2025, but the problem persists there as well.
Because of this problem, cppcheck cannot find files and therefore does not work.

However, it works when using the simpler API function GetFileInformationByHandle (without Ex).
Here is my fix for the problem:

#ifdef DOCKER
// New implementation
    BY_HANDLE_FILE_INFORMATION fileInfo;
    const BOOL ret = GetFileInformationByHandle(hFile, &fileInfo);
    if (ret) {
        id.fileIdInfo.VolumeSerialNumber = static_cast<std::uint64_t>(fileInfo.dwVolumeSerialNumber);
        id.fileIdInfo.FileId.IdentifierHi = static_cast<std::uint64_t>(fileInfo.nFileIndexHigh);
        id.fileIdInfo.FileId.IdentifierLo = static_cast<std::uint64_t>(fileInfo.nFileIndexLow);
    }
#else
// Old implementation
    const BOOL ret = GetFileInformationByHandleEx(hFile, FileIdInfo, &id.fileIdInfo, sizeof(id.fileIdInfo));
#endif

The problem can also be reproduced using testrunner.exe.

Thanks for reporting.

The documentation of the function does not give any indication it might not be available in certain configurations - see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getfileinformationbyhandleex.

I reckon the way to get that image is docker pull mcr.microsoft.com/windows/servercore:ltsc2025 according to https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images.

Thank you for your quick response.
Yes - you can pull the image with docker pull mcr.microsoft.com/windows/servercore:ltsc2025.

When I run testrunner.exe inside this image, several tests fail — for example, the TestPreprocessor::testMissingInclude test.
However, with my modification above (specifically, using a different API call), the test runs successfully.

I also tested the mcr.microsoft.com/windows/server:ltsc2025 image, since Microsoft states that it provides full API access. Unfortunately, the same problem occurs there as well.

(To run the application in the Docker container, you naturally need the necessary runtime libraries. In my case, that's vc_redist.x64.exe.)

I also tested the mcr.microsoft.com/windows/server:ltsc2025 image, since Microsoft states that it provides full API access. Unfortunately, the same problem occurs there as well.

I did not expect that.

I drilled further into the documentation regarding the requested information class FileIdInfo: https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_id_info. That states that it is only supported by Windows Server and not by the client. So it should actually be the other way around that it should only be working on your setup.

Since the documentation of the call in question refers to several filesystems I wonder if it is tied to that. Maybe the Docker container is not using NTFS?

There is a discussion here which seems to support my assumption: python/cpython#104820.

IIRC the windows-* GitHub runners recently switched from the C:\ to the D:\ so the build is done on a drive different from the one the actual system lives on.

@glankk

Ugh. GitHub only supports Docker images with Linux-based runners and the images cannot be deployed on such. So that requires manual work (or some existing action) to be able to integrate it into the CI.

I think the way to fix this is to call the the *Ex() function first and fallback to the more generic one if it fails.

I would also like to get the implementation out of the header first since spill platform-specific stuff into all code. I have a local branch for that already.

CC @glankk

I am not able to get this to work.

Out-of-the-box you can only run Linux containers (I am getting the same message in the CI):

> docker container run mcr.microsoft.com/windows/servercore:ltsc2025 .\simplecpp.exe
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2025' locally
docker: Error response from daemon: no matching manifest for linux/amd64 in the manifest list entries: no match for platform in manifest: not found

To be able to run Windows ones you need to switch the daemon to the Windows one (see https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/run-your-first-container#pull-a-container-base-image).

After that I am still not able to run it locally:

> docker container run mcr.microsoft.com/windows/servercore:ltsc2025 .\simplecpp.exe
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2025' locally
ltsc2025: Pulling from windows/servercore
docker: no matching manifest for windows(10.0.19045)/amd64 in the manifest list entries

So it seems you need a different OS to be able to run such containers.

@firewave

@firewave Maybe the docker engine is running in "Linux mode" and you need to switch to "Windows".

https://stackoverflow.com/questions/65149702/docker-desktop-cannot-switch-to-windows-container

As far as I know.. if it is able to start a linux container then it runs in "Linux mode".

@firewave Maybe the docker engine is running in "Linux mode" and you need to switch to "Windows".

That is exactly what I did and outlined above with the daemon switch.

That is exactly what I did and outlined above with the daemon switch.

aha. understood. I am surprised that it's not supported. if you see some option to pay for some external VM and solve this let me know (AWS would be preferable).

if you see some option to pay for some external VM and solve this let me know (AWS would be preferable).

We should not pay for this. I also do not think it is necessary as the amount of Windows API usage is next to none.

It might be possible to reproduce this locally by using files non-NTFS filesystems like SMB/CIFS via a network share or FAT32 via an USB stick (I have both handy). And maybe that can be done within a GitHub action as well. And maybe WSL can be leveraged (still need to look into that regarding the absolute path stuff anyways). I will give it a go after the weekend since I will be out most of the day.

I can reproduce it on an exFAT filesystem but not an a network share (I was access the machine itself via the share so that might not have actually gone through SMB).

We should probably extend GetFileId() to return a more detailed error.

I can reproduce it on an exFAT filesystem.

I am actually getting a different error code for GetFileInformationByHandleEx(). It fails with 87 which is ERROR_INVALID_PARAMETER. So we are dealing with different causes. The fix is probably the same but it would be nice if I could reproduce your issue as well.

refs cppcheck-opensource#583 - report `CACHE_ERROR` when `simplecpp::…

So it seems you need a different OS to be able to run such containers.

did you try with ltsc2022 ?

I believe I managed to run ltsc2022 in a github action: #592

Please note the "Hello from Windows container" message

Run docker run --rm mcr.microsoft.com/windows/servercore:ltsc2022 cmd /c "echo Hello from Windows container && dir C:\"
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2022' locally
ltsc2022: Pulling from windows/servercore
425c2915a651: Pulling fs layer
ea2e635f63c8: Pulling fs layer
ea2e635f63c8: Verifying Checksum
ea2e635f63c8: Download complete
425c2915a651: Verifying Checksum
425c2915a651: Download complete
425c2915a651: Pull complete
ea2e635f63c8: Pull complete
Digest: sha256:3a2a2fdfbae2f720f6fe26f2d7680146712ce330f605b02a61d624889735c72e
Status: Downloaded newer image for mcr.microsoft.com/windows/servercore:ltsc2022
The filename, directory name, or volume label syntax is incorrect.
Hello from Windows container 
Error: Process completed with exit code 1.

Thanks. I will take look later today.

I fail to reproduce locally. Is there a suggestion what I should do? i.e. this command works fine in my windows docker container:

simplecpp\build\debug\simplecpp.exe simplecpp\simplecpp.cpp

and the integration tests are successful in my docker container also, as far as I know these tests should test out the inclusions:

C:\danie\simplecpp>python -m pytest integration_test.py

The top of the Dockerfile I used to build my docker image says:

FROM mcr.microsoft.com/windows/servercore:ltsc2022

@willenbr24

@willenbr24 do you have suggestion how I can reproduce?

We cannot use these Docker images in the CI - they are ginormous.

mcr.microsoft.com/windows/servercore   ltsc2025   79967dce01f9   2 weeks ago   7.62GB

mcr.microsoft.com/windows/server   ltsc2025   aec1b9526eb7   2 weeks ago   17.9GB

I think trying to address the issue using manual testing via exFAT should be sufficient for now. We should file a follow-up ticket to try to automate that test.

fixed cppcheck-opensource#583 - fall back to `GetFileInformationByHan…

I think trying to address the issue using manual testing via exFAT should be sufficient for now. We should file a follow-up ticket to try to automate that test.

This should be possible using a virtual hard disk. See
https://learn.microsoft.com/en-us/powershell/module/hyper-v/new-vhd
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/gg252579(v=ws.11)

fixed cppcheck-opensource#583 - fall back to `GetFileInformationByHan…

@willenbr24 do you have suggestion how I can reproduce?

I identified the issue in the cppcheck project (https://github.com/danmar/cppcheck.git) and was able to reproduce it using the unit tests (testrunner.exe). And there you can see that several tests fail, which work with my workaround.

To reproduce the problem, you need to compile the cppcheck project inside the container and then run testrunner.exe.
We use the Microsoft Build Tools for compilation. Instructions for installing them in Docker can be found here:
https://learn.microsoft.com/en-us/visualstudio/install/build-tools-container?view=vs-2022

Does this mean that the latest trunk still fails for you?

Does this mean that the latest trunk still fails for you?

No, I haven't tested the latest trunk yet.

I just tested your changes from commit 7ac711b using the cppcheck project at commit cppcheck-opensource/cppcheck@a9f88d4, running the tests with testrunner.exe in a Docker container. The test was successful!
Thank you!

Navigation Menu

Repository navigation

getFileId() error in windows docker container #583

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

getFileId() error in windows docker container #583

Description

Activity

firewave commented on Nov 4, 2025

willenbr24 commented on Nov 4, 2025

firewave commented on Nov 4, 2025

firewave commented on Nov 4, 2025

firewave commented on Nov 6, 2025

danmar commented on Nov 7, 2025

firewave commented on Nov 7, 2025

danmar commented on Nov 7, 2025

firewave commented on Nov 7, 2025

firewave commented on Nov 10, 2025

firewave commented on Nov 10, 2025

3 remaining items

danmar commented on Nov 29, 2025

danmar commented on Nov 29, 2025

firewave commented on Nov 29, 2025

danmar commented on Nov 29, 2025

danmar commented on Nov 29, 2025

firewave commented on Nov 29, 2025

firewave commented on Nov 29, 2025

willenbr24 commented on Dec 1, 2025

firewave commented on Dec 1, 2025

willenbr24 commented on Dec 1, 2025

willenbr24 commented on Dec 1, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions