Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Deploying Qt5.5: won't find windows platform plugin
JohnRBradshaw last edited by JohnRBradshaw
I was happily deploying my Windows Desktop application up to Qt5.3.
I have an automated build process using a simple batch file which essentially does:
- nmake -f Makefile.release
- windeployqt myexename.exe
- makensis ... to create an installer using NSIS.
Life was good - my app installed and ran on a clean windows install.
Using the SAME automated build process, I then moved to Qt5.4 (msvs2013_opengl) and subsequently Qt5.5 (msvc2013_64) but each of these latter two versions suffer the dreaded:
'This application failed to start because it could not find or load the Qt platform plugin "windows".
Reinstalling the application may fix this problem.'
(of course it doesn't :o( ).
With both versions my work around is to change my nsis installer to install the qwindows.dll into the SAME directory where it lives on my build machine - this then works.
My directory structure is (for my 5.5 attempt):
I have tried copying qwindows.dll in MANY places on the target (clean windows) machine:
- A "platforms" subdirectory in the above windows directories.
To no avail. However it works if the following file is present:
Which is exactly where it is installed on my build machine.
I read a previous report (from a couple of years ago by 'Angivare') where there was NO solution but all the advice worked for a different project so I fear my application has stumbled down the same dead end and will NEVER again work but I thought I would post to see there has been any more insight to this issue over the past few years.
As I mentioned - I have a work around. It's just a rubbish one that I shouldn't have to use.
SIgh, perhaps I'll re-create the project manually when 5.6 is released?
Hi, normally it should work fine to place your qwindows.dll in %installdir%/platforms, Qt should look for it there. One thing that can obstruct that lookup process, is if you do something fishy before
QApplication a(argc, argv);in your main.cpp.
I was defining my QApplication in the following way:
std::unique_ptr<QApplication> a( new QApplication( argc, argv ) );
(Guess who got all excited at the new features in C++11).
I turned it back to the more traditional:
QApplication a( argc, argv );
and unfortunately the problem persists.
Thank you very much for the suggestion though, I hadn't thought about that as a possible cause.
Hi, one thing you could try is to turn on tracing of the plugin loading process, set this environment var in a CMD window:
Then start your app from that CMD window. To see the trace output you need to download and run DbgView
I tried this and simply get the message repeated in the debug log:
 This application failed to start because it could not find or load the Qt platform plugin "windows".
 Reinstalling the application may fix this problem.
I made sure I had turned on capture for everything (ran it as administrator).
Thanks again for the suggestion.
Hmm, your debug output implies Qt cannot find your platforms subdirectory. Maybe some permissions problem?
Anyway, what you can try, place your qwindows.dll next to your app .exe file (i.e. not in the platforms subdirectory).
Then try starting your app from a CMD window and appending the -platformpluginpath switch:
myexename -platformpluginpath .
Well that certainly worked. I can even find it in my platforms directory if I tell it explicitly where to find it.
Thanks you for that - you've given me a much cleaner workaround. I'll build it up tonight and report back...
Nice! I'm still pondering though why you need to "spoon-feed" Qt with that switch to make it load qwindows.dll properly; just checking:
the first thing you do in your main.cpp's main() function is
QApplication a(argc, argv);, right?
Apologies for the delay.
This work around is happily working for me but I agree it is puzzling as to why the spoon feeding is required. With the (hopefully) imminent release of 5.6 I'll switch over to that and if I'm very lucky this will stop being an issue but if it persists (which it did from 5.4 to 5.5) I'll spend some more time pondering it.
Sounds like a plan :-) I'm also on the lookout for 5.6, a release candidate for it should surface any day now...