GeezerVison is showing github.com — getFileId() error in windows docker container · Issue #583 · cppcheck-opensource/simplecpp
getFileId() error in windows docker container #583DescriptionWe 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));
#endifThe problem can also be reproduced using testrunner.exe. Activityfirewave commented on Nov 4, 2025 willenbr24 commented on Nov 4, 2025 ContributorAuthor More actions 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.) firewave commented on Nov 4, 2025
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. firewave commented on Nov 4, 2025 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 firewave commented on Nov 6, 2025 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. danmar commented on Nov 7, 2025 firewave commented on Nov 7, 2025
@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. danmar commented on Nov 7, 2025
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). firewave commented on Nov 7, 2025
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. firewave commented on Nov 10, 2025 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. firewave commented on Nov 10, 2025
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. danmar commented on Nov 29, 2025
So it seems you need a different OS to be able to run such containers.
did you try with ltsc2022 ? danmar commented on Nov 29, 2025 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.
firewave commented on Nov 29, 2025 Thanks. I will take look later today. danmar commented on Nov 29, 2025 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
danmar commented on Nov 29, 2025 @willenbr24 do you have suggestion how I can reproduce? firewave commented on Nov 29, 2025 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. added 2 commits that reference this issue on Nov 29, 2025This issue will close once commit 5badd89 is merged into the 'master' branch.5badd89 This issue will close once commit ed84cbe is merged into the 'master' branch.ed84cbe firewave commented on Nov 29, 2025 added a commit that references this issue on Nov 29, 2025This issue will close once commit 7ac711b is merged into the 'master' branch.7ac711b willenbr24 commented on Dec 1, 2025 ContributorAuthor More actions firewave commented on Dec 1, 2025 Does this mean that the latest trunk still fails for you? willenbr24 commented on Dec 1, 2025 ContributorAuthor More actions
Does this mean that the latest trunk still fails for you?
No, I haven't tested the latest trunk yet. willenbr24 commented on Dec 1, 2025 ContributorAuthor More actions 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! Reacted by Oliver Stöneberg
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|