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

orsini29

Actually this is interesting... I used the *.exe from the installed version of the program on my local computer, and this is what I got

I will be honest...I do not know how to decipher this, I assume it means something is not being fetched correctly with the DLLs?

hskoglund

Hi, for Windows 10 the downloaded Ni-DAQmx sofrware can be either 32-bits or 64-bits flavored. Since you're using a 32-bit Qt version the Ni-DAQ files should have the same bitness.

For 32-bit apps they load their system dlls from C:\Windows\SysWOW64 directory but in the trace output above they're loading them from C:\Windows\System32 (which is where the 64-bits version of the system dlls are stored).

Usually this 32-bit/64-bit mixup should return error 0x0000007b and not 0xc0000142 so I'm not sure this is the problem but you could check anyway :-)

orsini29

@hskoglund

Interesting... I will switch I assume the PATH variable within the Qt environment to add(?)

C:\Windows\SysWOW64

or should I just append this path at the end of the PATH variable? Thanks again, hopefully it works!

Also, why is it that 32 bit DLLs reside in SysWOW64, and 64 bit DLLs reside in System32, is this not confusing to anyone else :)

Edit: also, I do not think changing my PATH variable within Qt is doing much.. I changed it to the following

C:\Qt\5.15.9\mingw81_32\bin;
C:\Qt\Tools\mingw810_32\bin;
C:\Qt\5.15.9\mingw81_32\bin;
C:\Qt\Tools\mingw810_32\bin;
C:\Program Files\Common Files\Oracle\Java\javapath;
C:\Program Files(x86)\VMware\VMwarePlayer\bin\;
C:\Qt\Tools\mingw810_32\bin\;
C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
C:\Windows\System32\OpenSSH\;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;
C:\Program Files (x86)\Vim\vim82;
C:\Users\Sorsini\apache-maven-3.8.6\bin;
C:\Program Files\Git\cmd;
C:\ProgramFiles\dotnet\;
C:\Users\Sorsini\AppData\Local\Microsoft\WindowsApps;
C:\Users\Sorsini\AppData\Local\Programs\Microsoft VSCode\bin;
C:\Users\Sorsini\AppData\Local\Programs\mongosh\;
"C:\Program Files;C:\Winnt;C:\Winnt\System32";
C:\Qt\Tools\mingw810_32\bin\;
C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2022.2.3\bin;
C:\Windows\SysWOW64; //added this
C:\Windows\System32

and whenever I run the installed program, after packaging it through Qt, it still says on dependency walker it is receiving the DLLs from System32

hskoglund

Hi, what happens if you try building your app with the MinGW 64-bit compiler?

orsini29

@hskoglund

I tried to do that earlier today, but I think there is a configuration issue with my MinGW 62-bit compiler. I looked at the properties for it and for the qmake (if I remember correctly), it is accessing the MinGW 32-bit compiler rather than the 62-bit one. I do not have access to my PC until Monday, so I can give some more information on what that configuration looks like exactly. But I was having troubles trying to set the 62 but one up earlier today.

I’ll give a reply Monday with what my configurations look like, thanks again for trying to help me out. Means a lot, I’ve been banging my head against the wall on this issue for a little over a week now

orsini29

@hskoglund

I set up the MinGW 64 bit compiler and now I'm receiving the

undefined reference to DAQmxCreateTask

I rechecked my *.pro file, and I am using Fwlib64, and that is pulling all the functions correctly, without any errors. I am referencing the DLL/LIB/*.H files the same within the *.pro file, and include them both in the *.cpp file I am referencing them in. I decided to see if upgrading to Qt 6.* would make any difference? I was originally on Qt 5.15.9 because it was easier to make 32 bit builds on, which I originally thought was the best route for this project, but I will change if I can get this other NIDAQ library working on the 64-bit build. Any suggestions on other things to look at for the above error? Thanks again.

This is the compiler error I am receiving, not sure if this will give a little bit more insight...

C:/Qt/Tools/mingw1120_64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: debug/mainwindow.o: in function `MainWindow::MainWindow(QWidget*)':
C:\Users\Sorsini\Documents\Qt Prototypes\Test\test/mainwindow.cpp:13: undefined reference to `DAQmxCreateTask'
collect2.exe: error: ld returned 1 exit status
mingw32-make[1]: Leaving directory 'C:/Users/Sorsini/Documents/Qt Prototypes/Test/test'
mingw32-make[1]: *** [Makefile.Debug:74: debug/test.exe] Error 1
mingw32-make: *** [Makefile:45: debug] Error 2
11:01:36: The process "C:\Qt\Tools\mingw1120_64\bin\mingw32-make.exe" exited with code 2.
Error while building/deploying project test (kit: Desktop Qt 6.3.2 MinGW 64-bit)
When executing step "Make"

hskoglund

If you rebuild in Release mode (instead of Debug) you still get the same error?

orsini29

@hskoglund

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!