Windows: build OK but exec fails because of missing DLL


I am adding Windows to the CI of the TSDuck open source project. The project is written in C++ with about 300 kloc. The CI script compiles the project (several shared libraries and executable) and then run a few test procedures. This works fine with Linux and macOS.

On Windows, the build complete successfully. It uses MSBuild and Visual C++. The EXE and DLL are all present in the output directory. Seen here using “ls -l” in the script.

But when I run any of the generated EXE, the command fails because of a missing DLL. But I cannot see which one. See here the command and its output:

$ if [[ "$TRAVIS_OS_NAME" == "windows" ]]; then
    ls -l build/msvc/$BINDIR/tsversion.exe build/msvc/$BINDIR/tsduck.dll
    build/msvc/$BINDIR/tsversion.exe --version=all 2>&1
    source src/tstools/release-x86_64/ && tsversion --version=all

-rwxr-xr-x 1 travis 197121 5722112 Jan  8 14:16 build/msvc/Release-x64/tsduck.dll
-rwxr-xr-x 1 travis 197121  120320 Jan  8 14:21 build/msvc/Release-x64/tsversion.exe
C:/Users/travis/build/tsduck/tsduck/build/msvc/Release-x64/tsversion.exe: error while loading shared libraries: tsduck.dll: cannot open shared object file: No such file or directory

You can see that tsduck.dll is here, in the same directory as the executable. So, it must be another DLL but there is no clue about it.

Additional remarks:

  • The build completes successfully, no library was missing at build time. Only some unknown DLL is missing at run time.
  • Running the same build and run commands on my local system works.
  • I have reproduced a small test project which builds an EXE and a DLL. The build and execution are fine on Travis-CI. So, building an EXE calling a DLL works on Travis. This was expected but I wanted to be sure.
  • In the same test project, I added a directory containing the tsversion.exe and tsduck.dll that I built locally on my system and try to run them on Travis-CI. I get the same missing DLL error.
  • The TSDuck EXE and DLL reference a larger number of Windows system DLL’s than a basic “hello world” test but it does not use any third-party DLL. Only Windows DLL’s. And remember that the build completes without error.

Does anyone have an idea on how to troubleshoot this one? How can we figure out which DLL is missing? Why does the execution fail on Travis-CI while it builds successfully?

Thanks for your help.

Try to diagnose DLL load issues.

dumpbin (part of winsdk, should be present on a builder) can also be used but it doesn’t check for presence or recursively.

Thanks for the advice. If I compare the missing DLL in the set of dependencies for my application between the Travis VM and my local Win10 system, the following DLL are missing on the Travis system:


Is there any Chocolatey package to install? I have never used Chocolatey, so I am ignorant about what is provided.

This is quite worrying that the Travis system is so different from a regular Win10 systems. We do not have the same issue with Linux or macOS. With these OS, the base Travis system is identical to a regular system. Any apt or homebrew package to install, you already had to install them on your local system. So, you know them. With Windows, we spend quite a huge amount of time trying to figure out why it does not work.

Since some missing DLL are related to DirectX, I tried to install it with Chocolatey. But it fails (

Output from “choco install -y directx”:

Download of directx_Jun2010_redist.exe (95.63 MB) completed.
Hashes match.
Installing directx...
directx has been installed.
Installing directx...
ERROR: Running ["C:\ProgramData\chocolatey\lib\directx\tools\DXSETUP.exe" /silent ] was not successful. Exit code was '-9'. See     log for possible error messages.
The install of directx was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\directx\tools\chocolateyInstall.ps1'.
See log for details.
Chocolatey installed 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

The log file chocolatey.log is not helpful. It ends with:

2020-01-09 09:49:29,959 4740 [DEBUG] -  Found 'C:\ProgramData\chocolatey\lib\directx\tools\'
  with checksum '09AD0F82D92213B7D7EAA9E3B2268FE5'
2020-01-09 09:49:29,974 4740 [DEBUG] - Attempting to create directory "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.2    0180606".
2020-01-09 09:49:29,974 4740 [DEBUG] - There was no original file at 'C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.20    180606\.files'
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.201806    06\.arguments".
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.201806    06\.extra".
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.201806    06\.version".
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.201806    06\.sxs".
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\.chocolatey\directx.9.29.1974.201806    06\.pin".
2020-01-09 09:49:29,990 4740 [DEBUG] - Sending message 'HandlePackageResultCompletedMessage' out if there are subscribers...
2020-01-09 09:49:29,990 4740 [ERROR] - The install of directx was NOT successful.
2020-01-09 09:49:29,990 4740 [ERROR] - Error while running 'C:\ProgramData\chocolatey\lib\directx\tools\chocolateyInstall.ps1'.
 See log for details.
2020-01-09 09:49:29,990 4740 [DEBUG] - Attempting to create directory "C:\ProgramData\chocolatey\lib-bad".
2020-01-09 09:49:29,990 4740 [DEBUG] - Moving 'C:\ProgramData\chocolatey\lib\directx'
 to 'C:\ProgramData\chocolatey\lib-bad\directx'
2020-01-09 09:49:31,999 4740 [DEBUG] - Attempting to delete file "C:\Users\travis\AppData\Local\NuGet\Cache\directx.9.29.1974.20    180606.nupkg".
2020-01-09 09:49:32,014 4740 [WARN ] - 
Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
2020-01-09 09:49:32,014 4740 [INFO ] - 
2020-01-09 09:49:32,014 4740 [ERROR] - Failures
2020-01-09 09:49:32,014 4740 [ERROR] -  - directx (exited -9) - Error while running 'C:\ProgramData\chocolatey\lib\directx\tools    \chocolateyInstall.ps1'.
 See log for details.
2020-01-09 09:49:32,014 4740 [DEBUG] - Sending message 'PostRunMessage' out if there are subscribers...
2020-01-09 09:49:32,030 4740 [DEBUG] - Exiting with -9

If it’s DirectX that you need then you are out of luck, I’m afraid (you can vote on that feature request though):

FWIW you should be able to show the part of the log with DirectX installation with

sed -n '/directx/,/==============/p' /C/ProgramData/chocolatey/logs/chocolatey.log

The chocolatey log does not show anything. I have included it in a previous reply. The only visible symptom is dxsetup exiting with status -9 (or 4294967287 in unsigned version). I tried to manually reproduce every installation steps for DirectX on a local system. Even in “silent” mode, the installation program shows a progress bar GUI. So, that may explain that it fails on a server edition. I also tried to replace choco install directx by all these individual steps (download from MS, expand files, run setup, etc). It fails with the same symptom on the Travis Windows server.

The funny part is that my application uses the console subsystem only, there is no GUI at all. However, it links against DirectShow to access the DVB tunning framework. This application is typically a server application but, on Windows, it ironically cannot run on a server edition…

I understand that Windows support is currently experimental on Travis. How can we vote for new features?

Clearly, the current system is suitable for building only, not testing. A Windows Server Core environment is not suitable for most Windows applications. To be very pragmatic, all open source developers who work on Windows use a desktop edition. I have never seen an open source programmer using a Windows server edition. So, providing a test environment which is not compatible with all open source developers environment will probably lead to complaints like this one again and again.

Is there is specific reason for limiting Windows environment to server core on Travis or is it just because it is experimental and waiting for users’ feedback?

You didn’t show the relevant part. You tried to cat it and it was too long and started with an unrelated setup. In any case, the cause you already identified seems probable.

You can vote on the linked feature request.

I can only conjecture on that. Maybe they thought it would be enough, and it wasn’t, and upgrading needs different licenses.

I just discovered the recent “GitHub Actions” features. It is functionally equivalent to Travis-CI. I will let experienced users comment the respective advantages of the two. But the Windows platform runs in the Microsoft Azure cloud and does not have the same restrictions as the Server Core environment. I can build and run the full test suite of my project without installing anything else. I will probably switch my CI to GitHub Actions.