Qt 5.15.9, MinGW 32-bit compiler, "Application was unable to start correctly (0xc0000142)".

orsini29

I downloaded MSVC 2019 32 and 64 bit compilers just to see if anything will change and I received the following

Error with MSVC 64 bit
![5ec5dd91-6176-4ec9-862b-ba0fd5fd146d-image.png]

Error with MSVC 32 bit

As for building in release mode, I received the same error as above for both of the compilers. This is the same for MinGW 32/64 as well, except I received the "Application was unable to start correctly (0xc0000142)" error.

hskoglund

Hi, if you build one of Qt's example apps, like the "Application Example", does it run correctly? (Jiust want to check that your compiler toolchains are up to scratch).

orsini29

@hskoglund

Yup, I just compiled on of my former applications and it compiled okay

hskoglund

Ok the compiler(s) work with a vanilla Qt program with no external libs dependencies.

So what happens if you reduce the number of external libs you are depending on: right now you are trying to link with both Fwlib32.lib and IDAQmx.lib.
(If one of them has another bitness (32 instead of 64 or the other way around) that's enough to cause those linker errors above.)

Could you try a smaller program that is only dependent on one of them? I.e. links only with just one of them? Either only Fwlib32.lib or only NIDAQmx.lib?

orsini29

@hskoglund

So the above error messages are with a program just linking to NIDAQmx.lib, I put the code for my *.pro and *.cpp below

test.pro

QT       += core gui
QT       += widgets

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

CONFIG += c++11

# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
    main.cpp \
    mainwindow.cpp

HEADERS += \
    NIDAQmx.h \
    mainwindow.h

FORMS += \
    mainwindow.ui

# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

LIBS += \
    ./NIDAQmx.lib

mainwindow.cpp

#include "mainwindow.h"
#include "ui_mainwindow.h"
#include "./NIDAQmx.h"

MainWindow::MainWindow(QWidget *parent): QMainWindow(parent), ui(new Ui::MainWindow) {
    ui->setupUi(this);

    TaskHandle taskHandle;
    DAQmxCreateTask("", &taskHandle);

}

MainWindow::~MainWindow() {
    delete ui;
}

The error messages I receive are as above with the screenshots.

I also ran this in release mode, as well as debug mode too.

When compiling the application without making any calls to a method within the library (ex: DAQmxCreateTask(...)), the project will compile perfectly fine. Though once I uncomment the line, it gives me that same error

orsini29

@hskoglund

I started to dive deeper into the NI folder from the installation and found some *.h and *.lib files that were not in the original path mentioned above, I added these in because they actually have a lib32 and lib64 folder containing the libraries. Upon adding the 32 bit libraries I edited my *.pro file, and now instead of receiving any application/compile output console errors, I am just receiving the "Application was unable to start correctly" error again...

So I ran the new cleaned/rebuilt application within Dependency Walker, and I noticed that the NICAIU.dll is now not read (assuming that the red square denotes an issue), as seen below

Although, QT5WIDGETSD.DLL and QT5CORED.DLL have the question mark next to them. I do not think this is where the issue is stemming from though..Also it is still fetching System32 dlls rather than the SysWOW64 dlls, although I am compiling the application with the MSVC 32 bit. When I tried to compile with the 64 bit libs, I received the same error message although dependency walker showed red squares next to all the DLLs.

When I press F7 within Dependency Walker to profile the .exe, I received the errors saying these two DLLs are unavailable.

I went into the MSVC2019 bin and grabbed them explicitly and moved them into the debug folder with the dummy.exe

and received this on dependency walker, which looks better/more promising.

Then I being profiling again, and I do not receive any error messages but Dependency Walker stops responding and will not load anything after a short bit of time.

The logging window when Dependency Walker crashes is looking like this

jsulm

@orsini29 said in Qt 5.15.9, MinGW 32-bit compiler, "Application was unable to start correctly (0xc0000142)".:

LNK4272: library machine type 'x86' conflicts with target machine type 'x64'

You are mixing 32bit and 64bit. This will not work. If you want to build 64bit application then all libraries used have to also be 64bit.

orsini29

@jsulm

Yeah I realized that by using this 64 bit compiler, I was trying to see if maybe the 64 bit would work because the bitness of the library was unknown, until I did a deeper dive into the folder structure and found another set of *.libs that told me which bitness they were with a parent folder named lib32 or lib64. Although, even building with the 32 bit lib I still receive the error marked on the question.

"Application was unable to start correctly (0xc0000142)"

jsulm

@orsini29 said in Qt 5.15.9, MinGW 32-bit compiler, "Application was unable to start correctly (0xc0000142)".:

"Application was unable to start correctly (0xc0000142)"

This is another error. Now your app is building but not starting. I guess the library is not found. You can either copy it into the same folder (build folder) where you app executable is or set PATH variable in Run environment in QtCreator, so that it points to the folder where the lib is.

orsini29

Fixed the issue.

Turns out it was something with my laptop. I had gotten a secondary laptop that had the same environment, all Windows 10, downloaded the NIDAQmx software, and it connected to my Qt application perfectly fine. Very odd, unsure why this happened. I went about the installation process the same on both laptops.

I hope nobody ever has to go through this issue again, but if you are, might want to try on a new laptop..Worked for me!