Runtime Library error. The app doesn't start
When you start the application, an error occurs: 
I wrote an application in C++ and Qt 5.9.1. Wrote in QtCreator, compiled using MinGW 5.3.0 32bit, Windows 7 64 OS. I compiled it into a release, ran Windeploy, and added the necessary libraries according to Qt for Windows-Deployment. 
I tested it on 5 computers and 3 virtual machines. It runs on my computer. On a computer with an almost clean win7 64, it also works. On virtual machines with clean win7 64 and win10 64 does not work, on three more real computers with win7 and win10 also does not start. There was also a virtual machine, but I did not do it, on win10 64, the program worked there.
I tried to put all possible ones .Net and Visual C++ libraries-doesn't help. I tried to rebuild the project - it didn't help. I wrote a test application, also in QtCreator - it works.
Pro project file -
#-------------------------------------------------
#
# Project created by QtCreator 2018-02-06T14:45:04
#
#-------------------------------------------------
QT += core gui
QT += axcontainer
QT += concurrent
LIBS += -lmpr
LIBS += -lwbemuuid
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = second_Net_Please
TEMPLATE = app
# The following define makes your compiler emit warnings if you use
# any feature of Qt which has been marked as deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS
# You can also make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0
SOURCES += \
main.cpp \
... (мои файлы)
HEADERS += \
... (мои файлы)
2 answers
The mechanism of occurrence of such an error
The message "This application has requested the Runtime to terminate it in an unusual way " is output when:
- an unhandled exception occurred in a C++ application
- Visual C++ Standard Library version-2010 or later
- the application is built using the debug version of the standard library
If the version of the Visual C++ standard library is 2012 or newer, it will instead be another message is displayed, slightly more meaningful ("abort() has been called " - see below) and allows you to activate the just-in-time debugger if it is installed on the system by pressing the Retry button.
If the application is built using the release version of the standard library, a message will be displayed instead asking you to send a report to Microsoft, and the Application Error event will be logged in the system log. If the just-in-time debugger is installed, it will, most likely, it is activated automatically and prompts you to perform debugging.
It may seem strange why such an uninformative message is displayed. This is due to the exception handling mechanism adopted in C++. If the exception is not handled by any handler in the user code, a special crash handler will be called. It has such a prototype:
void terminate(void);
As you can see, no error parameters are passed to it at all, so output an informative message the message is not possible. The default implementation of this handler simply calls the abort function. This function outputs an error message (in debug mode), calls the SIGABRT signal (which allows the debugger to start working), and then shuts down the application. This handler can be overridden by calling set_terminate, but it usually doesn't do any good.
Read more: Unhandled C++ Exceptions
Note. This error almost never occurs it is connected with the lack of some libraries. If there are no libraries linked via a LIB file, it usually outputs something like " The application could not be started because it is not configured correctly".
How to debug such an error
Usually the answer is simple-handle all exceptions and display detailed information about the error on the screen and / or in the log (you can also log the entire progress of the program, so that it is easier to determine at what stage the problem occurred). In the case this question, it was enough.
However, sometimes more complex situations may arise. What if the program crashes with a mysterious error deep inside a function of a third-party library that has no source code? Then you will need to use the debugger-the standard one from the studio or WinDbg. To get the maximum effect from the debugger, you need to:
- Attach symbol files (*.pdb) to all modules that have them
- Configure the debugger to use Microsoft symbol servers (there are symbols from the standard library and OS libraries)
- Enable automatic stop on exceptions
This will allow you to extract some information from the error code, where it occurred, and the call stack at that moment.
References:
The error was that I did not catch one exception, which caused the error. I didn't know that with such an error, Runtime error might pop up, so I didn't immediately guess. When the program starts, it works with the registry, and there was an exception