Missing libgcc_s_seh-1.dll starting the .exe on Windows

Question

Intro

I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).

Problem

When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.

I have the following questions

If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?

Additional information

I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.

What I have did so far?

I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.

The dll is probably in a directory near your compiler, clion is probably adding that directory to the path environment variable when running your program — Alan Birtles, Jun 03 '22 at 16:25
Side note: If you want to pass the program around and not have to worry about shipping dlls with it, consider static linking. The executable will explode in size because it builds in the stuff it needs from the DLL, but you don't have to worry about the DLL. Sometimes it's a coin toss which is the better option. — user4581301, Jun 03 '22 at 16:43
***I found this dll does not exist in the MinGW installation folder*** It should be in the bin folder of mingw. if it is not I am not sure how your mingw is working. — drescherjm, Jun 03 '22 at 17:41
@drescherjm see my replay to this post. I found the DLL in the Tor Browser dir ^.- — Dawid, Jun 03 '22 at 18:09
That is very odd. I would say your current Mingw is not properly installed in that case. — drescherjm, Jun 03 '22 at 18:29
You may want to uninstall your Mingw and reinstall it using msys2: [https://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2](https://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2) — drescherjm, Jun 03 '22 at 18:33

score 1 · Accepted Answer · answered Jun 03 '22 at 19:16

I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.

score 0 · Answer 2 · answered Mar 04 '23 at 09:47

I had the same problem. For me, the issue was that I was running windeployqt.exe from a batch script I wrote for myself so that I wouldn't have to open the MinGW console and navigate to my deploy direectory every time.

When I run windeployqt.exe from the dedicated MinGW64 console that is installed with Qt, it works as expected. The previously missing dll is added and I can run my application on another Windows PC with no Qt installation without a hitch.

score -1 · Answer 3 · answered Jun 03 '22 at 17:55

This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).

If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.

Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.

Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.