I have a perfectly working application (exe with around 16 DLLs) when building in Debug mode. However, as soon as I switch to Release, get the exe and all DLLs built, all required DLLs copied over from the QtSDK bin, I'm getting a runtime error.
How exactly am I supposed to troubleshoot what's happening? Is this a common issue? I don't get any entry points, etc., to even start from.. just a generic runtime error.
The only similar question I've found is here, but this is from a much older version of Qt. 4.7.4 only has one bin folder.
Edit 1 - I've commented everything out of my main.cpp except creating my MainWindow object, and everything out of my MainWindow constructor, so it should just be opening an empty window - still the Runtime Library issue.
Note - Keeping it in release mode and starting the debugger launches the application fine.
Debug -> Start and Debug External Application also results in this Runtime Library error.
Add also libEGL.dll.
See this bug for details: https://bugreports.qt-project.org/browse/QTBUG-28766
My apologies everyone. It appears the QtSingleApplication libraries aren't working correctly. I had implemented this to force any files I open to open into the one instance. I've recompiled it and it still isn't working, but just using a QApplication seems to have resolved the Runtime Library. I'll have to look into the QtSingleApplication a bit more and see why it's being a pain.
Thanks for the quick comments regardless :)
Related
I am learning how to code in Qt and made a semi-Notepad like application.
It is working like a charm in my PC, but when I sent the executable file (I sent the whole debug folder with all the necessary .dll files in it) to my friend, their OS shows the following error:
[This application has requested the Runtime to terminate it in an unusual way.]
I compiled it using MinGW compiler and really can't see where the fault is.
First of all, you will prefer to do a Release compilation to provide a smaller executable and smaller set of DLLs.
As specified here http://doc.qt.io/qt-5/windows-deployment.html you will need several DLLs located in your Qt/MinGW/bin/ folder.
Most notably :
platforms\qwindows.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
You may also need the following, but you can try without :
icudtXX.dll
icuinXX.dll
icuucXX.dll
Trying to "Rebuild All" helped me to solve the issue. Although I had a runtime issue on the system where my application was built.
I'm using QtCreator with the visual studio 2015 kit on windows 8.1 to build a program I developed and tested on Linux, on linux it works correctly, but on windows it's just crashing immediately, and I have no idea what to look for.
The only external libraries, aside from QT I'm using are opengl and glew, so I don't think it's those.
Is there anything that's known to work in GNU C++ but crash immediately in MSVC?
Usually this kind of crashes have absolutely nothing to do with your program. It's an external library linking issue. I had this issue recently with the OpenSplice DDS library. I linked to a library that caused a segmentation fault before anything started. I resolved the issue by linking the pre-compiled libraries 1-by-1, and check each if that fixes the program.
What I recommend you to do is: Remove the libraries and resources you're linking to gradually, until your program starts and prints "Hello world" from the first line of main().
Another way to go is, make a new empty program, and link the same resources you're using in your program. This is easier, as it doesn't involve modifying your program.
This is what I would do.
Start by rebuilding the entire solution or project from a clean state. Just in case this is just some weird dependency issue that resulted in something not getting recompiled. Never hurts.
As Neil said in the comments for the question, the crash is possibly coming from a global variable who's constructor runs before main or WinMain. Are you sure you don't have something declared as "static" or at global scope that might have a constructor?
Now do the following:
Open Visual Studio.
From the menu, select File->Open->Project/Solution...
When the file open dialog pops up, select the EXE produced by Qt
Creator. (That's right - you are opening the EXE as a project). This directory is typically one folder level above the Qt project (..\build-yourapp-Desktop_Qt_5_7_0_MSVC2015_32bit-Debug\debug)
Now press the green arrow to start debugging (menu->Debug->Start
Debugging). If all goes well, your program will fail early and
Now chances are high that the program is not going to run at all under Visual Studio because Qt Creator doesn't copy all the Qt*.dll binaries to your build directory. You'll get a bunch of dialogs popping up saying that "The program can't start because Qt5-XYZ.dll can't be found". This is easily fixed by updating your PATH environment in any of the following way to include your Qt5.x.0\5.x\msvc2015\bin folder to your PATH.
You add it from the command linke and then re-launch devenv.exe from the command line.
You can add it globally from Control Panel->System->Advanced. Then restart Visual Studio from the Windows desktop.
With the EXE debug project open from within Visual Studio, just right click on the project name (not parent solution) and a dialog will popup that allows you to edit startup settings. One of which is the Environment.
And that should do it. From there you can start the debugger on your EXE, set breakpoints as needed, and analyze the call stack on crash.
It's really easy: build all the libraries you use, including Qt, with debug information (those can be release builds as long as the PDB files are generated). Then run your application under a debugger (e.g. F5 under Qt Creator), and it will stop at the point of the crash.
The code that runs before main and is known to cause trouble will be the global object initialization: you're likely running into the static initialization order fiasco.
Another cause for the problem could be stackoverflow. In Linux, the stack size by default is usually 8 MB whereas in Windows it's just 1 MB.
Try to link with /STACK:8388608 switch. If it works, you might consider allocating more data on the heap and stay with the default stack size of 1 MB.
I have a Qt application, which runs fine when I execute it from Qt Creator. However, on running it by manually clicking the generated exe, I get the following error :
I would understand if it would ask for missing DDLs (which I could then place in the same folder). But how should I proceed to handle this (in general) ?
P.S. It is not giving any line number in my source code which I could try testing this assert for. I tried using the release mode as well, but the same error.
We don't know what the problem with your code is; you'll need to use a debugger to find that out. I think that the pre-built Qt libraries that you download come with debug symbols, but if they don't, you can always build Qt yourself to get them using the -force-debug-info configure option.
You can also use DebugView to see debug output of deployed applications.
However, in general, you should use the windeployqt tool that is included with Qt.
The Qt for Windows - Deployment page has more information about deploying Qt applications to Windows machines, but windeployqt should do everything you need.
My qml files were not getting deployed properly and thus this error (this assert is probably on the variable storing the main qml file name, i.e. it should not be an empty string, which in case of missing main.qml, it was). Placing the qml files at correct paths solved the issue.
Also, as #mitch has pointed out in his answer, use windeployqt to find out the dependencies. Although, I have also realized that it doesn't cover all the dependencies (MSVC runtimes for example and other compiler related files sometimes). In that case run the dependency walker and place the missing files manually along with the exe.
I am trying to use a library (.dll) in my project. Everything seems to
be set up fine. It all works in release mode.
When I go debug on it, I get this darn error on startup:
ldr: ... application couldn't be initialized error (or similar, I translated it)
I learned that this has to do with manifest files.
I fumbled around a bit, in the project settings, but nothing really worked / I couldn't get my head around it.
The error persists.
Does anyone know a quick solution to this?
I don't care if it is dirty.
I think I liked dll-Hell better than manifest-Hell!!
The solution:
The wrong version of the .dlls got loaded. I didn't know that they were still
lying around on the system. Depedency Walker is a great tool and set me on the right track. So I will accept this answer.
Thanks a lot!
I always use Dependency Walker for debugging this sort of thing. It will tell you which dependencies your dll is missing.
Are you trying to run Debug-mode executables on a PC without Visual Studio installed? If so, you'll need to copy the Debug CRT DLLs onto it. See here: http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx
Probably has something to do with dependent DLLs that are not available in debug mode (but are there in release mode). Make sure the debug DLLs you need are available (e.g. in the path).
I'm using boost for several C++ projects. I recently made a upgrade (1.33.1 to 1.36, soon to 1.37), since then I cannot run any debug-builds anymore.
To be sure that no other project issues remain, I've created a minimum test-project, which only includes boost.thread, and uses it to start one method. The release build can be started, the debug build cannot, although the Dependency Walker shows that all required libraries are found (this also means that the required MS Debug CRT is found in the SxS directory).
On startup I only get:
Die Anwendung konnte nicht richtig initialisiert werden (0xc0150002).
Klicken Sie auf "OK", um die Anwendung zu beenden.
Which means nothing more than "failed to initialize app". An internet research primarily lead to an MS Office installation problem, which recommends to perform a repair of WinXP.
So, beside the repair setup (which I think will not help as I'm talking about debug-dll issues), any ideas?
Ah, before I forget: Absolutely the same source-code leads to no errors on the build-machine (i.e., DLLs can be registered, means executed). So it's obviously an installation problem, but as the DLLs are there, and dependency-walker finds it, what else have I forgotten?
(edit) Well, I have not yet resolved my problem, but thanks to deemok I'm a step further. For the sake of reducing misunderstandings I give some clarifications below:
The program fails to run on the developer-machine
I am working with an installed VS2005 (it's a VC++8 project)
I used the boost-setup from BoostPro, compiled all possible build-versions, and I double-checked that they are there (otherwise I'd already get linker-errors during build).
and I double-checked any corner of include/lib/bin configuration I can think of -- as boost uses auto-linking on windows, with a special naming convention, the build or start-up would have failed, with a much more comprehensible error-message.
I cannot use static linking, as boost.thread requires dynamic linking for DLL projects (I maybe could mess around here, but as this problem seems to happen only on my machine, I do not want to mess with this, as I'm sure the boost-guys had a reason to place that check in there in the first place)
As I wrote, I checked with Dependency Walker, and it says everything is just fine.
Currently it seems to be an error in the boost-dll (maybe incorrect Manifest), will check that.
It's a Side-by-Side (SxS) issue – simply copying the DLLs is not enough anymore.
Regarding your specific problem concerning the Debug build, see: Running vc2008 debug builds on non-dev machines
Short answer:
You can't, because there's no installer redist for the debug runtime (and in fact the software license forbids distributing it, so you'd be breaking the EULA even if you did get something put together).
So, you'll need to install Visual Studio there.
However, if you still want to try without taking that path, you could read puetzk's answer in its entirety.
Or, you could try to link everything statically.
So you are using the pre-built libraries from BoostPro? If so, your environment might somehow be slightly different to the one they were built in (TR1 feature pack or not, etc). Perhaps best to try building Boost yourself in your specific environment.
This might turn out to have nothing to do with SxS. I suggest checking the Event Log for SxS error messages and using dependency walker to check for most probable DLL dependency issue, or one of the DLLs is returning FALSE from its DllMain (for whatever reason).
Also, enabling loader snaps:
gflags -i yourapp.exe +sls
might shed extra light when run under debugger (or dependency walker for that matter).
Note: gflags is part of Windows debugging tools.
Get yourself the dependency walker. Open your application exe in it. It will show you all the dlls that your application needs but can't load/access.
If that's not enough, you can also profile your app with the dependency walker, which will give you a lot of output to find out where the problem is.
[edit]
since you only have problems with the debug build:
make sure that when you upgraded boost, you also rebuilt not just the release binaries but also the debug binaries of boost. And of course, make sure that the debug build was built with the same version of VisualStudio than you're using now.
And make sure that the include paths (tools->options->projects and solutions->VC++ directories) are correct: the paths to the latest boost version must be there, not maybe to an older version.