"procedure entry point could not be located ..."

drmhkelley

Using Qt Creator 4.5.1 and Qt 5.10.1 on Windows 10 - have been doing so successfully for quite some time. Only building apps on Windows 10 for use on Windows 10 platforms.

Today, I can no longer create "release" versions of any projects - including Qt example programs. The debug versions (examples and all apps that I have developed myself) work fine. But release versions give the dreaded "procedure entry point could not be loaded".

Well, actually inside of Qt Creator, the program just crashed with the error:

"The program has unexpectedly finished.
The process was ended forcefully.
C:/Users/Owner/Documents/Mike/src/Qt/menus/release/menus.exe crashed."

I get the entry point error if I run the release version outside Qt Creator.

I have not changed anything (as far as I am aware) about the environment. The Qt tool kit appears to be configured as it should. Am at a loss to see what the difference might be between the debug and release builds that would lead to this problem.

Any suggestions?

SGaist

Hi,

You should check whether you had a Windows update, Visual Studio Update, maybe anti-virus.

JKSH

@drmhkelley said in "procedure entry point could not be located ...":

I get the entry point error if I run the release version outside Qt Creator.

What is the name of this entry point? That's an important clue. Please post the full error message.

ambershark

@drmhkelley I'm betting you have multiple versions of Qt installed and it is trying to use an incompatible version of Qt. I.e. maybe Qt 4.x in the path and you build against Qt 5.x.

That would lead to a bad entry point. This could potentially even happen with an old version of Qt5 versus a newer one.

You can run a find or dir /a /s *qt*core*.dll and check for multiple qt dlls. Run that on all your drives.

drmhkelley

@SGaist
Thanks. I'm sure there has been both Windows and anti-virus updates, along with recent updates for Qt and Qt Creator (but I don't use Visual Studio). I don't think I have details about any specific update.

drmhkelley

@JKSH
The error message from Qt Creator was included in the initial post - not particularly informative. When I attempt to initiate the program outside Creator, I get a dialog with text

"This procedure entry point _ZN10QArrayData10deallocateEPS_jj could not be located in the dynamic link library C:\Users\Owner\Documents.....\Qt\menus\release\menus.exe"

BTW, I think the specific entry point varies from app to app. This is for the Qt example app widgets/mainwindows/menus - though it is possible that I have mucked around a bit with the original source code. It is always the app executable where the entry point can't be located.

drmhkelley

@ambershark

Thanks.

I do have multiple versions of Qt. I have kits configured for binary downloads for 5.9.2 and 5.10.0. I also have 5.10.0 that I built from source using minGW-w64 7.1.0. I need the latter because my Qt apps rely on a significant collection of other libraries that are built using minGW-w64.

I get the same entry point error for the menus example program using all three kits.

hskoglund

Hi, it seems you got the wrong Qt5Core.dll in your path, not the MinGW-flavored one but the MSVC one. If you copied the Qt libraries to your .exe file's folder, perhaps you copied them from C:\Qt\Tools\QtCreator\bin?

P.S. Because Windows10 has "improved" the error message (compared to prev. Win versions) it says "the entry point could not be located in ...\menus.exe". What it really means it that the entry point (requested by menus.exe) could not be located in Qt5Core.dll. Microsoft's helping hand :-)

drmhkelley

@hskoglund
Thanks. But sorry, I don't understand what you're suggesting. Does it make sense to you that there is different behavior for the debug and release apps? And this has all been working smoothly for months - something changed but I haven't a clue what.

Out of desperation, I downloaded/installed Qt-5.10.1 (only MinGW 5.3 version). I then removed anything MinGW related from my path and updated the Qt-related items to the 5.10.1 locations.

I still get the same behavior. The debug version works, the release version gets the same error.

Now I'm really stumped.

hskoglund

Hi, when you're running the debug version of menus.exe Qt is looking for DLL files with other names compared to when you're running the release version of menus.exe. For example, the debug version of the Qt5Core.dll is called Qt5Cored.dll. So (just a guess) if you have copied the wrong flavor of Qt5Core.dll but the correct version of Qt5Cored.dll then it makes sense that the debug version of menus.exe works fine but the release version goes south.

drmhkelley

@hskoglund
Well, I haven't actually "copied" any .dll files - apart from whatever the Qt installer does at install time.

When I manually compile apps (not within Qt Creator), I have set up the appropriate Makefile to load explicit libraries instead of just setting the library search paths so they can be found. So for those apps, I'm pretty confident I'm using the correct libraries.

hskoglund

You can look at your PATH environment variable, perhaps in the list of directories there is a directory entry for a ..\Tools\QtCreator\bin before the MinGW version.

Edit: also, to be sure, you could do as @ambershark suggests above: open a CMD window and type "dir c:\qt5core.dll/a/s" and see how many hits you get.

drmhkelley

@hskoglund

my PATH variable does not include the QtCreator directory - the shortcut I use to run Creator includes the full path to the executable. I do include the path for the mingw libraries, and if I want to run Qt application outside the Creator environment, I have to include the relevant Qt paths in the PATH variable - and I have to keep those up-to-date for the relevant versions of mingw and Qt. I'm pretty confident that is all done correctly.

Were I to run the suggested dir command, I would find about 7 sets of relevant libraries. There would be the binary downloads for Qt 5.92 and Qt 5.10.0, the versions I compiled with mingw-w64 for those two versions of Qt, the installed versions of both of those, and the binary download for 5.10.1 that I installed this morning. I do have to pay attention that the PATH variable, the Creator tool chain, and the various makefiles all line up correctly.

I worry that we might actually need to be running down some other rabbit hole.

hskoglund

Yes, a mix of multiple Qt versions and multiple settings/editing of the PATH variable could be a potent mix or a dangerous one...

I've only been doing Qt dev. for a couple of years but I never touch my PATH setting, instead I use a program called windeployqt.exe, it copies the Qt libraries (Qt5Core.dll etc.) into the same folder where your menus.exe file resides. That way you never have to change the PATH, Windows always looks for a Qt5Core.dll in the same directory as the .exe file.

Also, when you have a pristine PATH setting, running your program from Qt Creator always works :-)

ambershark

@drmhkelley Yea you are most definitely mixing Qt dlls. So what you can try is to clear your path and then run your binary. It will want dlls to support it, it will tell you which at each run. Copy those specific ones into your local dir and keep running until you get it all set up.

This will prove that it is working properly and that you are mixing dlls, however figuring out where you are mixing dlls, you will need to find where they are in your PATH variable.

To clear your path, just open a cmd and type set PATH="". Then type path, it should show you PATH="". Now you can run your binary from that cmd window i.e. mybinary.exe and it will pop up an error telling you which dlls are missing (1 at a time).

After you figure that out just go through with that dir command I put above, or using find figure out where all the Qt dlls are on your system and find which ones are in the PATH.

Should be nice and easy. Good luck! :)

drmhkelley

@ambershark
I'm pretty sure this thread has gone off-track somewhere and that I need to be considering other directions for solution.

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

I have a newly downloaded and installed Qt package, Qt 5.10.1, located in c:/Qt-5.10.1
PATH variable is clean, making no reference to mingw. to Qt. or anything else now required for Windows to work.
New copy of the widgets/widgets/lineedits example app.
Two .bat files, one to build the app and one to run the resulting executable.
The build .bat file appends the following to the clean PATH in order for "mingw32-make" to work: c:/Qt-5.10.1/Tools/mingw530_32/bin.
The run .bat file appends c:/Qt-5.10.1/5.10.1/mingw53_32/bin to my clean PATH variable so the Qt libs can be found. It then runs either the debug or the release version of the app.

The debug version works, the release version doesn't.

I don't see where in this process there is any opportunity for .dll confusions. If you do, please enlighten me.

drmhkelley

@hskoglund
Well, may not always work for qtcreator.

New installation of Qt 5.10.1, "pristine" PATH, run QtCreator, load example .pro. Build debug, works. Build release, fails.

I'm really at a loss to see where I've hidden the trap I'm tripping over.

ambershark

I'm pretty sure this thread has gone off-track somewhere and that I need to be considering other directions for solution.

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

That's good, however the error you are getting is from mixing dlls. We just need to figure out where/why they are being mixed.

Two .bat files, one to build the app and one to run the resulting executable.

Can you share these 2 batch files?

The debug version works, the release version doesn't.

2 different sets of dlls. This doesn't surprise me as you may have dirty release dlls but clean debug ones.

I don't see where in this process there is any opportunity for .dll confusions. If you do, please enlighten me.

Possibly in the build itself then. Maybe linking with libs from one Qt which don't match the DLL that is being used at run time. Hard to know without seeing the build process or environment.

JKSH

@drmhkelley said in "procedure entry point could not be located ...":

I am quite familiar with how to keep paths and libraries straight, so lets start from scratch and consider the following.

I have a newly downloaded and installed Qt package, Qt 5.10.1, located in c:/Qt-5.10.1

PATH variable is clean, making no reference to mingw. to Qt. or anything else now required for Windows to work.

New copy of the widgets/widgets/lineedits example app.

Two .bat files, one to build the app and one to run the resulting executable.

The build .bat file appends the following to the clean PATH in order for "mingw32-make" to work: c:/Qt-5.10.1/Tools/mingw530_32/bin.

The run .bat file appends c:/Qt-5.10.1/5.10.1/mingw53_32/bin to my clean PATH variable so the Qt libs can be found. It then runs either the debug or the release version of the app.

This procedure looks very solid. However, for some reason your release build is still not linking to the correct version of Qt5Core.dll. We know this because _ZN10QArrayData10deallocateEPS_jj is from the MinGW version of Qt5Core.dll.

We need to figure out if something in your system is interfering with your DLL linking process, or if your copy of Qt5Core.dll itself has been corrupted.

Questions:

How did you install Qt 5.10.1?
What is the size (exact number of bytes) or MD5 checksum of your copy of Qt5Core.dll? (I'm not in front of a PC at the moment, but when I get home I can check my copy. Or someone else on this forum can check)

Another check: While your debug build is running, use Process Explorer or ListDLLs (both tools by SysInternals) to see the exact paths of the DLLs used. Repeat this while the error dialog is open for your Release build. Are all of your Qt DLLs being loaded from c:/Qt-5.10.1/5.10.1/mingw53_32/bin ?

hskoglund

Hi, just to add to @JKSH, usually the reason why the debug version works (but not the release) is that the Qt5Cored.dll (i.e. the debug flavor) is not as widely spread/deployed as Qt5Core.dll (the release version). Qt5 is quite popular among Microsoft's developers, for example.

I've encountered the same problem (the release version tanks but not the debug) due to OneDrive from Microsoft also having copy of the Qt libraries (MSVC version, not MinGW). And OneDrive was listed in the PATH from a factory installation, so when you tried to run your MinGW Qt program it failed, because OneDrive was listed in the PATH before the MinGW Qt libraries so the wrong Qt5Core.dll was picked up :-(

You could try: in your .bat file used to run your Qt program, instead of appending ";c:/Qt-5.10.1/5.10.1/mingw53_32/bin" try prepending it so it listed in the PATH as the first directory...