MinGW C++11 app compiles, can't run outside IDE: 0xc000007b

[Grault]

Windows 7 64-bit
Visual Studio 2012, Update 3
MinGW 4.8 32-bit
Qt Creator 2.8.1
I'm not using the Qt libraries in this project.

Current problem (from bottom): How can I fix my Qt MinGW installation?

For this project I use both Qt Creator and Visual Studio to edit it, with MinGW g++ and CL as the compilers. (I know I can hook up either IDE to both compilers, but I just haven't bothered.) The other day while I was debugging, I had made the project pass all test cases. Windows Update apparently came up behind a window I was using, counted down, and restarted my computer. When it booted again a couple of test cases were failing. I couldn't find the problem and needed to go to work; when I got there I opened up my laptop and found the project now passed the test cases.

I'm not certain the test cases are actually relevant to the issue, but I should describe them anyway. I only saw this behavior in MinGW; compiling with CL always resulted in a clean bill of health. I was inserting and removing to an std::unordered_map<unsigned long long int, std::unique_ptr<CustomType>>. I found that the key was always garbage and the value was always null. I couldn't find an explanation for this in the code, but that's been true of countless bugs that were my fault.

For this kind of problem, I turn to Valgrind memcheck or, on Windows, Dr. Memory. So I dragged the app onto the shortcut and met a dialog:

The application was unable to start correctly (Oxc000007b). Click OK to close the application.

I later found that I get that message from just running the app directly, too. It still works inside Qt Creator and breaks outside of it. The Visual Studio build works in VS and standalone.

A search result suggested using Dependency Walker to investigate this. It said the app was looking for these DLLs, which were missing:

API-MS-WIN-CORE-COM-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-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL

(Dependency Walker said all of the missing dependencies were children of a dependency on USER32.DLL.)

Someone else had exactly the same problem and was advised to try uninstalling the Visual Studio 2010 redistributable package and installing the Windows 7 SDK. I did so and saw no improvement, then noticed the OP had posted the answer in an edit to his question (well, some of it; a lot of it seems to have been lost in a private conversation he had with another SO member.):

After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLLs reported missing by the dependency walker tool, nameley those* API-MS-WIN-CORE-...

type DLLs were not part of the actual problem.
In my case the registration of 3 OCX files was missing and after that everything was just fine, BUT dependency walker tool still listed all the very same DLLs as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.

I'm not familiar with OCX files. I found some basic info on Google, but I don't think I'll gain anymore useful ground on my own. What are they and how are they related to my issue? Or maybe my issue has nothing to do with OCX files? How might the Windows Update reboot have harmed my computer? Why the heck does MinGW depend upon .NET? I would like to know all that, but I'll be happy if I can just have my app working again!

EDIT: An empty main function with no includes does not show these symptoms. (A previous edit to the contrary was wrong.) I'm looking into which headers are relevant.

EDIT2: I also forgot to mention that I used System Restore to go back to before Windows Update rebooted the system, and it didn't help.

Help would be most appreciated!

[Grault]

I reinstalled Qt and now the issue is consistent; even for the absolute simplest possible C++ program, I get a dialog with the error in the first quote. This is only under MinGW outside of Qt Creator. I wonder how Creator modifies the environment...

EDIT: The above is only true for EXEs compiled from within Qt Creator, which is bizarre. I even used the makefiles generated from Creator's call to qmake; only the mingw32-make call was external when it worked. So apparently I need to stop using Creator until I find a solution.

EDIT2: The EXEs that work are compiled for 64-bit, according to Dr. Memory (which is its explanation for why it can't profile them). I'm not sure what I can do to make mingw32-make do 32-bit. (The main.o generated by Creator is 1 byte smaller, and the .exe is 4 bytes smaller.)

EDIT3: The makefile is accidentally grabbing my 64-bit MinGW installation. Oops. How should I tell it where to look for g++?

[Grault]

By placing this Batch script in my build directory and running it after qmake, I consistently get the error at issue:

setlocal

set PATH=C:/Qt/Tools/mingw48_32/bin/;%PATH%


mingw32-make -f Makefile.Debug

endlocal

I'm not sure what to do from here...

[AceInfinity]

MinGw doesn't depend on .NET at all... For that batch file, why not just navigate to the directory? For my MinGw installation, I've put the bin directory path in my Environment variables through the system configuration. Have you tried re-installing MinGw?

What does your makefile look like? What does the system %PATH% environment variable look like by default?