12

I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.

The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application

I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.

After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)

Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).

If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!

Etienne Pellegrini
  • 738
  • 1
  • 5
  • 11
  • 3
    0xC000007B STATUS_INVALID_IMAGE_FORMAT {Bad Image}. Almost certainly your application is trying to load the 64-bit DLL. I would hazard a guess that the problem started occurring after a change to the PATH environment variable, which put the 64-bit DLL ahead of the 32-bit one. (Note that depending on context, such a change might not have taken effect immediately.) Consider changing PATH, or putting a copy of the 32-bit DLL in the same folder as the executable that needs it. – Harry Johnston Aug 04 '14 at 21:35
  • @HarryJohnston Thanks. And we're talking about the windows wide PATH variable, or a MinGW specific PATH? Also, according to Dependency Walker, it would be this libquadmath-0.dll which is responsible right?Or could it be another of the ones listed above? (in case I have to download the 32 bit version and put it in the same folder...) – Etienne Pellegrini Aug 05 '14 at 01:19
  • Yes, I would expect the warning shown by Dependency Walker to be correct. It would be the Windows PATH variable, unless MinGW is doing something extremely strange. If a change to PATH is indeed responsible, the correct DLL should still be present; try `where libquadmath-0.dll` at the command line. – Harry Johnston Aug 05 '14 at 01:44
  • Ok, I think indeed the problem is with libquadmath-0. I only have this file in one location (the Anaconda folder), but the libgfortran-3.dll that uses libquadmath is in two locations: the minGW folder and the Anaconda folder. I now suspect that somhow the 32-bit libquadmath-0 which must have been in the minGW folder went missing, and that's why the 64-bit one from Anaconda is getting used. I will have to try and find this dll online! – Etienne Pellegrini Aug 05 '14 at 02:49
  • Odd; when you reinstalled MinGW, the installer shouldn't really have installed libgfortran-3.dll without its dependency. Perhaps there's a bug in the setup, could be worth reporting if you can reproduce it. – Harry Johnston Aug 05 '14 at 03:14

6 Answers6

3

I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.

Jimbo
  • 2,886
  • 2
  • 29
  • 45
  • 1
    I have already added the path of mingw.64 to windows path but it did not solve the problem – AAEM Jul 14 '21 at 08:52
1

I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue. So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it. That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237

To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.

Community
  • 1
  • 1
mmortal03
  • 491
  • 4
  • 4
1

I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:

  1. Open CMD
  2. cd C:\MinGW\bin to navigate to the bin directory of mingw
  3. now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe

alternatively if u want to automate the process u can make a batch file to automatically do it for you. here's the batch file if anyone needs it

@echo off

C:

cd \MinGW\bin\

gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!

pause

EpicCon
  • 11
  • 3
0

I had a similar error but over came it by editing my environment variables. I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared

Konrad Krakowiak
  • 12,285
  • 11
  • 58
  • 45
Isaac Sekamatte
  • 5,500
  • 1
  • 34
  • 40
0

I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.

My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.

ChrisZZ
  • 1,521
  • 2
  • 17
  • 24
0

Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:

Path=c:\msys64\mingw64\bin;%PATH%

The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.

Justin
  • 1