gcc /g++ produces windows executables that only create output on msys2 bash, not on other terminals

I have three machines running VSCode on Windows 10 set up for C++ with msys2 / mingw64 /gcc.

The Microsoft Compiler cl.exe and the Visual Studio build tools are also installed.

Via Github they share each other's code. On one Machine i have several problems with MSYS2 GCC compiler family (gcc /mingw64, gcc/ucrt64, clang64) on Windows.

Lets say i have two types of cpp files, a.cpp and b.cpp (in fact a whole bunch of .cpp files that consistently behave in exact one of the two ways) On my "normal" PCs, they behave just fine - i can load them in my VSCode, compile and run them, and they produce some simple output on commandline.

I can also run gcc on the commandline, like gcc a.cpp -o a.exe and then call the resulting a.exe, giving me the correct output. Works on "normal" PCs with a.cpp as well as with b.cpp

On my "faulty" pc, just the files of type a.cpp work the same: I can compile them from either vsccode or commandline, from a cmd terminal, powershell or from the according msys bash, and then execute them, getting the correct output.

Now there are the files of type b.cpp

They seem to compile fine like the others in VSCode - no compiler error or something like that - but they simply do not produce any output when executed. Just an empty line, then it returns to the prompt.

It gets even more weird when i go to a cmd window: when i try to run the compiled b.exe on the cmd prompt, a mesagebox comes up with the message

b.exe - Entry Point Not Found
The procedure entry point "_ZST28__throw_bad_array_new_lengthv" 
could not be located in dll "b.exe".

[OK]

(Text is translated to english as it was on a german windows version)

As it was compiled using MigW64 environment, i try the MingW64 bash, running the compiled b.exe from there, and it works: I do get the correct output. It also works on the ucrt64 environment, but not on the clang64 environment.

when i go into the clang64 bash i can compile b.cpp into b-clang.exe, which works and gives the proper output. But this b-clang exe will not work in MingW64 bash nor in UCRT64 bash nor in cmd prompt. in the last one, in cmd, it gives me another popup error messagebox saying

The execution of the code cannot proceed because libc++.dll was not found. 
Reinstalling the program may potentially fix the problem

[OK]

(Text is translated to english)

I tried a complete new install of the MSys2 Environments, but it didn'T change anything.

gcc --version on all machines (the good ones and the faultyone) gives me

gcc (Rev7, Built by MSYS2 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

here is a short sample of a simple a.cpp fle that will do well on all PCs:

#include <iostream>
using namespace std;
int main ( void ) {
    string array [] = { "es", "wie", "geht", "Dir ?" };
    string hilf = " ";
    int i = 0;
    int y = 0;
    while ( i < 3 ) {
        y= i+1;
        while ( y < 4 ) {
            if ( array [ i ] < array [ y ] ) {
                hilf = array [ i ];
                array [ i ] = array [ y ];
                array [ y ] = hilf;
            }
            y++;
        } // end while innen
        i++;
    } // end while aussen
    for ( string s : array ) cout << s << "\n ";
}

and here is a simple file iof type b.cpp that will do strange things on this one PC:

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main() {
    vector<string> msg {"\nHello", "C++", "World", "from", "VS Code", "and the C++ extension!\n"};
    
    for (const string& word : msg) {
        cout << word << " ";
    }
    cout << endl;
    std::cout << "C++ language version : " << __cplusplus << std::endl;
}

Solution

It has been dll issues. The simple sulution was to move the c:\msys64\mingw64\bin entry to the beginning of the path, as first entry. I did have quite a lot in the path, so if somneone stumbles on absurd problems like the ones i described: always be aware that you might get into trouble when there are .dll files that might have same names.

In my case, i still have to watch out carefully if now some other software will not work properly because now it finds the msys2 dlls before the ones that are neede. (None found so far...)