Windeployqt modifying DLL files?

terryfryar

On Win10, using Qt 5.6 (I built from source) with MSVS2013. I have a 32 bit Qt QML app that runs fine inside creator. If I hand copy all the Qt DLL's, or put all Qt paths in PATH, it runs fine. However, if I run windeployqt, when I run the app from the resulting tree that windeployqt built, I get this error on startup:

Debug Error: Qt5Cored.dll Module 5.6.1 File qglobal.cpp Line 3007
ASSERT failure in QList<T>::operator[]: "index out of range"

Now, here's the wierd part. The Qt5Cored.dll that windeployqt copied is NOT the same file that's in my Qt folder?? If I manually copy my Qt folder Qt5Cored.dll file into the tree over the top of the windeployqt one, the app runs just fine? Why is windeployqt modifying a DLL file?

I did a global search on my drive and there is NO other DLL by that name anywhere on the system. Here is what windeployqt changed:

Comparing files Qt5Cored.dll and \USR\LOCAL\QT-5.6.0-I386\BIN\QT5CORED.DLL
004D43A4: 2E 63
004D43A5: 00 3A
004D43A6: 00 2F
004D43A7: 00 75
004D43A8: 00 73
004D43A9: 00 72
004D43AA: 00 2F
004D43AB: 00 6C
004D43AC: 00 6F
004D43AD: 00 63
004D43AE: 00 61
004D43AF: 00 6C
004D43B0: 00 2F
004D43B1: 00 51
004D43B2: 00 74
004D43B3: 00 2D
004D43B4: 00 35
004D43B5: 00 2E
004D43B6: 00 36
004D43B7: 00 2E
004D43B8: 00 30
004D43B9: 00 2D
004D43BA: 00 69
004D43BB: 00 33
004D43BC: 00 38
004D43BD: 00 36

Anyone have any idea why windeployqt is modifying my DLL files? Thanks!

Chris Kawa

I think it's patching some paths to make sure they don't point to your local directories (which can happen when you build Qt yourself). It helps to test your deployment. See for example here.

Does it work if you use windeployqt and then overwrite only that one dll manually?
I doubt this is the source of your problem. If I had to guess I'd say you've got some uninitialized variable that happens to point to the right kind of garbage when you use one dll and wrong with the other.

Have you tried to run some static analysis tools on it? Since you use a debug build (I hope you're not deploing that to your users) have you tried to run that deployed version under a debugger?

Paul Colby

@Chris-Kawa said:

I think it's patching some paths to make sure they don't point to your local directories (which can happen when you build Qt yourself).

Just supporting that suggestion, I ran the following AWK commands on the Qt5Cored.dll differences @terryfryar included above:

cat tmp.txt | awk '{printf "%c", strtonum("0x"$2)}'
cat tmp.txt | awk '{printf "%c", strtonum("0x"$3)}'

And the output is:

.
c:/usr/local/Qt-5.6.0-i386

So yep, looks like it's changing . to c:/usr/local/Qt-5.6.0-i386.

@Chris-Kawa said:

have you tried to run that deployed version under a debugger?

+1

Cheers.

Chris Kawa

So yep, looks like it's changing . to c:/usr/local/Qt-5.6.0-i386.

It's the other way around ;) It puts . there so that the dll doesn't refer to the paths that are not there (on other users machines).

terryfryar

Ah! Excellent guys, thank you! Makes sense...since there are a number of localized resources that Qt involves, qml stuff, etc. What I think was happening is that the deploy has missed something, hence the error. If I copy the original core.dll, then Qt looks to my dev Qt folder, which has everything in it. I just need to see what's missing during the deploy.

Thank you guys!!

terryfryar

Ok, found out what was happening. The "windeployqt" tool misses several qml folders and DLL's. I copied all the qml folders over manually. Even though this was a debug build against a debug Qt, for some reason the webengine stuff all wanted the release version of the qt DLLs. So I manually copied about 9 of the release DLLs over. The reason this is hard to see is that a lot of the webengine/webview stuff is dynamically loaded and so you get thrown exceptions or errors that make it hard to see what's actually missing.

The app works great! This deployment attempt was on WinXP, and is a full QML app using QWebView, ZMQ middleware, and a bunch of other wierdo stuff. But it works 100%! Had to build Qt with the "-target xp". Even the qml screens and the webview is being rendered correctly using Qt's "-opengl dynamic" setting. Excellent!

I now have this app compiled and deployed on like 7 or 8 different platforms and it's working well!

Thanks again all!

Chris Kawa

Cool, great that you figured it out.
Just a question - why are you deploying a debug version of your app?

terryfryar

That's a good question! On some platforms (we support Win32 on WinXP, Win32/64 on Win7/8/10, Apple OSX/iOS, Android, and Linux (i386/x64/arm)....deployments don't go as planned. So, if we run into platform specific issues, we keep test VMs for each and deploy and debug actually on the platform where possible. Sometimes, Qt's behavior changes depending on the underlying platform SDKs, and we have to observe what happens on that particular platform. So often, we will deploy using debug builds so we can "crack open the egg" on occasion and see what's going on under the hood.

In this case, it was a challenge since the QWebView uses several layers as well as the embedded chromium (or host browser) engine, and there's a buttload of dynamic loading of resources and libraries. If something is missing in this type of app, you don't always see the "correct" error message since a resource or lib fail deep in an SDK can cause seemingly unrelated error messages to occur at the app level.

This particular app now runs fine on WinXP, Win7, Win8, Win10, Apple OSX, Apple iOS, Android, and Linux. As much weird stuff as it has, this was no small feat to accomplish! Especially since it compiles with NO changes on all these platforms (you should see the PRO file...whew!). You basically check it out of the repo, open the project, pick your kit and compile!

Great job Qt guys!!