Brtdku

I created a platforms directory next to my exe location and put qwindows.dll inside, but I still received the "Failed to load platform plugin "windows". Available platforms are: windows" error.

I had copied qwindows.dll from C:QtQt5.1.1ToolsQtCreatorbinpluginsplatforms, which is not the right location. I looked at the debug log from running in Qt Creator and found that my app was looking in C:QtQt5.1.15.1.1mingw48_32pluginsplatforms when it ran in the debugger.

When I copied from C:QtQt5.1.15.1.1mingw48_32pluginsplatforms, everything worked fine.

I found an unexpected but intuitive fix. If you copy and paste the qwindows.dll, found in the bin of whichever compiler you used to release your application, into a folder named "platforms" you can then move that folder into the same directory as your application and like magic it works.

Also another helpful tip, Qt comes with platform console applications that will add all dependencies (including ones such as qwindows.dll and libEGL.dll) into the folder of your deployed executable. The application for windows is called windeployqt and the documentation can be found here http://doc.qt.io/qt-5/windows-deployment.html . This application saved me so much time and it's really the proper way to deploy your executable, so as not to miss anything.

Setting the QT_QPA_PLATFORM_PLUGIN_PATH environment variable to %QTDIR%pluginsplatforms worked for me.

It was also mentioned here and here.

I ran into this and none of the answers I could find fixed it for me.

My colleauge has Qt (5.6.0) installed on his machine at:
C:QtQt5.6.05.6msvc2015plugins

I have Qt (5.6.2) installed in the same location.


I learned from this post: http://www.tripleboot.org/?p=536, that the Qt5Core.dll has a location to the plugins written to it when Qt is first installed.
Since my colleague's and my Qt directories were the same, but different version of Qt were installed, a different qwindows.dll file is needed. When I ran an exe deployed by him, it would use my C:QtQt5.6.05.6msvc2015pluginsplatformsqwindows.dll file instead of the one located next to the executable in the .platforms subfolder.

To get around this, I added the following line of code to the application which seems to force it to look next to the exe for the 'platforms' subfolder before it looks at the path in the Qt5Core.dll.

QCoreApplication::addLibraryPath(".");

I added the above line to the main method before the QApplication call like this:

int main( int argc, char *argv )

{

    QCoreApplication::addLibraryPath(".");

    QApplication app( argc, argv );

    ...

    return app.exec();

}

create dir platforms and copy qwindows.dll to it, platforms and app.exe are in the same dir


cd app_dir
mkdir platforms
xcopy qwindows.dll platformsqwindows.dll


Folder structure

+ app.exe
+ platformsqwindows.dll


I found another solution. Create qt.conf in the app folder as such:

[Paths]

Prefix = .

And then copy the plugins folder into the app folder and it works for me.

I had this problem while using QT 5.6, Anaconda 4.3.23, python 3.5.2 and pyinstaller 3.3.
I had created a python program with an interface developed using QTcreator, but had to deploy it to other computers, therefore I needed to make an executable, using pyinstaller.

I've found that the problem was solved on my computer if I set the following environment variables:

QT_QPA_PLATFORM_PLUGIN_PATH: %QTDIR%pluginsplatforms

QTDIR: C:Miniconda3pkgsqt-5.6.2-vc14_3Library

But this solution only worked on my PC that had conda and qt installed in those folders.

To solve this and make the executable work on any computer, I've had to edit the ".spec" (file first generated by pyinstaller) to include the following line:

datas=[(
'C:Miniconda3pkgsqt-5.6.2-vc14_3Librarypluginsplatforms*.dll',
'platforms' ),]

This solution is based on the answers of Jim G. and CrippledTable

I had the same problem and solved it by applying several things.
The first, if it is a program that you did with Qt.

In the folder (in my case) of "C: Qt Qt5.10.0 5.10.0 msvc2017_64 plugins" you find other folders, one of them is "platforms". That "platforms" folder is going to be copied next to your .exe executable. Now, if you get the error 0xc000007d is that you did not copy the version that was, since it can be 32bits or 64.

If you continue with the errors is that you lack more libraries. With the "Dependency Walker" program you can detect some of the missing folders. Surely it will indicate to you that you need an NVIDIA .dll, and it tells you the location.

Another way, instead of using "Dependency Walker" is to copy all the .dll from your "C: Windows System32" folder next to your executable file. Execute your .exe and if everything loads well, so you do not have space occupied in dll libraries that you do not need or use, use the .exe program with all your options and without closing the .exe you do is erase all the .dll that you just copied next to the .exe, so if those .dll are being used by your program, the system will not let you erase, only removing those that are not necessary.

I hope this solution serves you.

Remember that if your operating system is 64 bits, the libraries will be in the System32 folder, and if your operating system is 32 bits, they will also be in the System32 folder. This happens so that there are no compatibility problems with programs that are 32 bits in a 64-bit computer.
The SysWOW64 folder contains the 32-bit files as a backup.

Most of these answers contain good (correct) info, but in my case, there was still something missing.

My app is built as a library (dll) and called by a non-Qt application. I used windeployqt.exe to set up the Qt dlls, platforms, plugins, etc. in the install directory, but it still couldn't find the platform. After some experimentation, I realized the application's working directory was set to a different folder. So, I grabbed the directory in which the dll "lived" using GetModuleHandleExA and added that directory to the Qt library path at runtime using

QCoreApplication::addLibraryPath(<result of GetModuleHandleExA>);

This worked for me.

For a MinGW platform and if you are compiling a Debug target by a hand made CMakeLists.txt written ad hoc you need to add the qwindows.dll to the platform dir as well.
The windeployqt executable does its work well but it seems that for some strange reason the CMake build needs the release variant as well.
In summary it will be better to have both the qwindows.dll and qwindowsd.dll in your platform directory.
I did not notice the same strange result when importing the CMake project in QtCreator and then running the build procedure.
Compiling on the command line the CMake project seems to trigger the qwindows.dll dependency either if the correct one for the Debug target is set in place (qwindowsd.dll)

Use this batch file: RunWithQt.bat

@echo off

set QTDIR=C:QtQt5.1.15.1.1msvc2012bin

set QT_QPA_PLATFORM_PLUGIN_PATH=%QTDIR%pluginsplatforms

start %1

• to use it, drag your gui.exe file and drop it on the RunWithQt.bat in explorer,


• or call RunWithQt gui.exe from the command line

If you have Anaconda installed I recomend you to uninstall it and try installing python package from source, i fixed this problem in this way

The application qtbase/bin/windeployqt.exe deploys automatically your application. If you start a prompt with envirenmentvariables set correctly, it deploys to the current directory.
You find an example of script:

@echo off

set QTDIR=E:QT5110vc2017



set INCLUDE=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726ATLMFCinclude;S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726include;C:Program Files (x86)Windows KitsNETFXSDK4.6.1includeum;C:Program Files (x86)Windows Kits10include10.0.14393.0ucrt;C:Program Files (x86)Windows Kits10include10.0.14393.0shared;C:Program Files (x86)Windows Kits10include10.0.14393.0um;C:Program Files (x86)Windows Kits10include10.0.14393.0winrt;C:Program Files (x86)Windows Kits10include10.0.14393.0cppwinrt



set LIB=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726ATLMFClibx86;S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726libx86;C:Program Files (x86)Windows KitsNETFXSDK4.6.1libumx86;C:Program Files (x86)Windows Kits10lib10.0.14393.0ucrtx86;C:Program Files (x86)Windows Kits10lib10.0.14393.0umx86;



set LIBPATH=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726ATLMFClibx86;S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726libx86;S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.15.26726libx86storereferences;C:Program Files (x86)Windows Kits10UnionMetadata10.0.17134.0;C:ProgramFiles (x86)Windows Kits10References10.0.17134.0;C:WindowsMicrosoft.NETFrameworkv4.0.30319;



Path=%QTDIR%qtbasebin;%PATH%

set VCIDEInstallDir=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseCommon7IDEVC

set VCINSTALLDIR=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVC

set VCToolsInstallDir=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.11.25503

set VisualStudioVersion=15.0

set VS100COMNTOOLS=C:Program Files (x86)Microsoft Visual Studio 10.0Common7Tools

set VS110COMNTOOLS=C:Program Files (x86)Microsoft Visual Studio 11.0Common7Tools

set VS120COMNTOOLS=S:Program Files (x86)Microsoft Visual Studio 12.0Common7Tools

set VS150COMNTOOLS=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseCommon7Tools

set VS80COMNTOOLS=C:Program Files (x86)Microsoft Visual Studio 8Common7Tools

set VS90COMNTOOLS=c:Program Files (x86)Microsoft Visual Studio 9.0Common7Tools

set VSINSTALLDIR=S:Program Files (x86)Microsoft Visual Studio2017Enterprise

set VSSDK110Install=C:Program Files (x86)Microsoft Visual Studio 11.0VSSDK

set VSSDK150INSTALL=S:Program Files (x86)Microsoft Visual Studio2017EnterpriseVSSDK

set WindowsLibPath=C:Program Files (x86)Windows Kits10UnionMetadata;C:Program Files (x86)Windows Kits10References

set WindowsSdkBinPath=C:Program Files (x86)Windows Kits10bin

set WindowsSdkDir=C:Program Files (x86)Windows Kits10

set WindowsSDKLibVersion=10.0.14393.0

set WindowsSdkVerBinPath=C:Program Files (x86)Windows Kits10bin10.0.14393.0

set WindowsSDKVersion=10.0.14393.0

set WindowsSDK_ExecutablePath_x64=C:Program Files (x86)Microsoft SDKsWindowsv10.0AbinNETFX 4.6.1 Toolsx64

set WindowsSDK_ExecutablePath_x86=C:Program Files (x86)Microsoft SDKsWindowsv10.0AbinNETFX 4.6.1 Tools



mkdir C:VCProjectsApplicationBuildVS2017_QT5_11_32-Releasesetup

cd C:VCProjectsApplicationBuildVS2017_QT5_11_32-Releasesetup

copy /Y ..Releaseapplication.exe .

windeployqt application.exe

pause

Lets say, you wanted to have some CGAL-Demos portable. So you'd have a folder "CGAL", and in it, 1 subfolder called "lib": all (common) support-dlls for any programs in the CGAL-folder go here. In our example, this would be the Dll-Download: simply unzip into the "lib" directory. The further you scroll down on the demos-page, the more impressive the content. In my case, the polyhedron-demo seemed about right. If this runs on my 10+ yo notebook, I'm impressed. So I created a folder "demo" in the "CGAL"-directory, alongside "lib".
Now create a .cmd-file in that folder. I named mine "Polyhedron.cmd". So we have a directory structure like this:

 CGAL - the bag for all the goodies

  lib - all libraries for all CGAL-packages

 demo - all the demos I'm interested in

[...] - certainly some other collections, several apps per folder...

Polyhedron.cmd - and a little script for every Qt-exe to make it truly portable.

In this little example, "Polyhedron.cmd" contains the following text:

@echo off

set "me=%~dp0"

set PATH=%me%lib

set "QT_PLUGIN_PATH=%me%libplugins"

start /b "CGAL Polyhedron Demo" "%me%demopolyhedronpolyhedron_3.exe"

All scripts can be the same apart from the last line, obviously. The only caveat is: the "DOS-Window" stays open for as long as you use the actual program. Close the shell-window, and you kill the *.exe as well. Whereever you copy the "CGAL"-folder, as the weird "%~dp0"-wriggle represents the full path to the *.cmd-file that we started, with trailing "". So "%me%lib" is always the full path to the actual library ("CGALlib" in my case). The next 2 lines tell Qt where its "runtime" files are. This will be at least the file "qwindows.dll" for Windows-Qt programs plus any number of *.dlls. If I remember rightly, the Dll-library (at least when I downloaded it) had a little "bug" since it contains the "platforms"-directory with qwindows.dll in it. So when you open the lib directory, you need to create a folder "plugins" next to "platforms", and then move into "plugins". If a Qt-app, any Qt-app, doesn't find "qwindows.dll", it cannot find "windows". And it expects it in a directory named "platforms" in the "plugins" directory, which it has to get told by the OS its running on...and if the "QT_PLUGIN_PATH" is not exactly pointing to all the helper-dlls you need, some Qt-programs will still run with no probs. And some complain about missing *.dlls you've never heard off...