Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QT deployed executable crashes on some computers



  • Hei,

    I have a strange issue QT deployed executables which I have been trying to solve since few days. I created an application using QT creator 4.10.2 on QT 5.11.1, using MSVC2015 (OS is Windows 10 Pro, 64 bit). When I deploy the application, executable runs on the development computer without any issue. Then I zip the whole deployment folder and test the same executable (together with the necessary libraries) on 6 different computers. Strangely, executable runs on 3 of them without any issue but crashes on 3 of them (all computers have Windows 10 Pro, 64 bit).

    On the computers where it crashes, I get no error when I double click to run the executable, just crashes without any indication and I only see the executable crashes on the Windows event viewer. There is also no sign about the issue in the event viewer logs.

    Just to be sure, I installed the same vc++ runtime libraries on all computers including the development computer.

    I even tested on 2 different computers which have the same graphic card (though have different driver versions) and same c++ runtime libraries. And executable is running one of them and not running on another.

    What might be the issue here or how can I find out the problem what causes the crash?



  • Hi, just guessing but try to turn off Windows Defender runtime protection and see if it makes a difference.



  • Thanks for your response. All computers have Kaspersky installed hence Windows Defender is disabled.


  • Moderators

    1. Did you deploy using windeployqt?
    2. Does your app rely on 3rd-party libraries?

    @Lati said in QT deployed executable crashes on some computers:

    What might be the issue here or how can I find out the problem what causes the crash?

    Your different PCs might have different (external) DLLs that get loaded into your app. Try using Dependency Walker to load your app on different PCs (one that crashes and one that doesn't crash) and compare the full list of DLLs.



  • @JKSH
    1-Yes, I used windeployqt
    2-There are 3rd party libraries but all of them are provided in the deployment folder at all computers.

    I tried both Dependeny Walker and Dependencies. Both give error on all computers which executable runs and crashes.

    I doubt if it is related to the graphic cards?



  • Are all of the computers running the same version of Windows 10?
    Also, try building your app in Debug mode instead of Release and try that on the crashing PCs (this means you'll have to copy the vc++ debug flavored runtime dlls as well)



  • @hskoglund Yes, they all have Windows 10 Pro with the latest update.
    I tried the Debug mode already and have the same results.



  • Have you tried running your app on the crashing PCs using the Remote Desktop? I.e. turning on the switch "Enable Remote Desktop" in Settings and then remotely running those PCs from your development PC using the Remote Desktop Client


  • Lifetime Qt Champion

    In addition to my fellows, did you compare the hardware of these machines ? Especially on the graphical card side.



  • @hskoglund I use remote desktop at all computers :) (though I tried directly using the computers as well)

    @SGaist , as I mentioned I also doubt about the graphic cards initially. But I tried on two computers with same specifications including graphic cards (GeForce 605) and both have now same nVidia drivers. And executable crashes only on one of them.

    Following is the event viewer log of the crash, maybe someone can take a hint:
    "Faulting application name: svchost.exe_TermService, version: 10.0.18362.1, time stamp: 0x32d6c210
    Faulting module name: ntdll.dll, version: 10.0.18362.267, time stamp: 0xc00f8a30
    Exception code: 0xc0000008
    Fault offset: 0x000000000009fe8a
    Faulting process ID: 0x5b8
    Faulting application start time: 0x01d5a2cd25825160
    Faulting application path: C:\WINDOWS\System32\svchost.exe
    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
    Report ID: 9b7e234e-f934-4cd5-8ad2-6910fae80b34
    Faulting package full name:
    Faulting package-relative application ID: "


  • Lifetime Qt Champion

    @Lati said in QT deployed executable crashes on some computers:

    Faulting application name: svchost.exe_TermService

    From a quick look that might be network related. Are these computer configured exactly the same ? Connected on the same network ? Is your application using the network ?


  • Lifetime Qt Champion

    If possible you should enable minidump creation on one of the computers so you can analyze it later on your system. See e.g. here on how to create them



  • @SGaist, all computers are connected to the company network through LAN.

    I am using "webkit" and "webkitwidgets" might be related to the crash?

    @Christian-Ehrlicher, I will try that but it is not an easy process since I need permission from our system admin :/



  • "Faulting application name: svchost.exe_TermService,.." means as @SGaist says, it's smells network related.

    Try walking up to the crashing PCs, pulling out the network plug and then test your app (but don't tell your system admin about the pulled plug :-)

    Edit: Exception code: 0xc0000008 I've seen that when remote debugging across a network, but you get that code also on a Release build?



  • @hskoglund I plugged out the network cable, no change (admin is on vacation, he will not realise that :))

    I tried again debug executable and I have now following error on the computer where it normally crashes:

    Annotation 2019-11-25 085822.png



  • @Lati
    Suggestion then is that your app does indeed attempt to load something off the network?

    Meanwhile, I don't understand why your program causes svchost.exe_TermService,.. svchost is to do with Windows Services, I wonder why these are involved in running this application?



  • @JonB Yes, it loads a website from internet to a *QWebView * control (it is a small website with few kilobytes).

    App has nothing to do with Windows Services; at least nothing intentionally coded in the app which uses the Windows Services.



  • Hmm error 0xc0000007b means there's a mixup of 32-bits and 64-bits .dlls. If your app is 32-bit, perhaps you've copied the msvc runtime library .dlls from C:\Windows\System32?
    Note that in Windows the 32-bits MSVC runtime .dlls are found in C:\Windows\SysWOW64 and instead C:\Windows\System32 houses the 64-bits one.



  • @hskoglund
    I noted that too. But users says only happens when network cable unplugged! Normally he gets a 0xc0000008 rather than a 0xc0000007b. Strange how that could lead to 32-/64-bit issue?!



  • @JonB No no, I haven't said it happens only when network cable is unplugged. It happens always with or without internet connection.

    @hskoglund I wonder if this is the reason because I use the same deployment on all computers. But, I will check that again.

    I hope I can solve this "mystery" soon :/



  • @Lati

    @JonB No no, I haven't said it happens only when network cable is unplugged. It happens always with or without internet connection.

    Read what you have posted and you do seem to say what I wrote. First earlier:

    Exception code: 0xc0000008

    then later screenshot

    0xc0000007b

    It's what you have pasted!

    Anyway, if you Google for the 0xc0000007b you will come across 32-/64-bit mis-match. I am not certain whether that always applies, but worth investigating.



  • @JonB @hskoglund
    Nope, I have re-deployed using windeployqt.exe and copied the necessary dlls from SysWOW64 (again) and still have the same problem.

    To summarize: I deployed the application created using QT Creator and test the executable on different computers. Deployed files are same on 6 different computers. Executable runs on three computers without any issue and crashes on other three without any indication.

    Additionally, I uninstalled all VC++ Runtime installations on one of the computer and installed the ones in the "C:\Qt\vcredist" and still have the same problem.



  • If you have 2 computers pretty near each other, and one of them is of the crashing kind and the other is one the healthy ones, try swapping the network cables, i.e. unplug the network cable going to the healthy PC and instead plug it into the crashing PC, and the other way around.



  • A couple thoughts:

    • Make sure you are running the correct version of the deploy tool. I had issues with my deploys where I was running it under the 5.12.2 console when I should be running it under the 5.12.5 console.
    • Check for race conditions on when your web data arrives. Is your app relying on the data it grabs and if it doesn't get it in time it will cause a crash.


  • Ok. I decided to install the Qt on one of the computer where executable crashes. I copied the whole development folder and build the application. I can build the application in Debug and Release without any problem. However, when I try to start the debug with F5, I get following error:

    Capture.PNG

    Please note that Qt is installed on D drive. I tried few solutions offered by Google, like copying the Qt dll's in the debug folder which didn't help. I feel very desperate.

    @hskoglund
    Pc's are a bit far from each other :) I use remote desktop most of the time.

    @fcarney
    I checked that, it is v 5.12.1. I don't know how to be sure which version it should be.



  • Finally! I found where the problem is. I received source code of the one of the libraries I use. And there is following code in the library:

    programXRootDirectory = getenv("ProgramXROOT");
    

    And yes, if the environmental variable doesn't exist, executable crashes. Strangely, there is no sign about the crash caused by getenv.

    I will keep this thread, maybe someone else has the same problem.

    I would like to thank you everyone who tried to help me so far!

    Update:getenv is deprecated and _dupenv_s recommended instead. More information about _dupenv_s



  • @Lati said in QT deployed executable crashes on some computers:

    Strangely, there is no sign about the crash caused by getenv.

    Well, it looks like the culprit isn't getenv() but the way the return value from that function is used within the DLL later on. From man getvenv:

    The getenv() function returns a pointer to the value in the environment, or NULL if there is no match.

    so programXRootDirectory becomes NULL when the variable is not set, and the world ends...



  • @Lati
    That file error screenshot is in Qt5Cored.dll. Note the d at the end of the name. That is the version compiled for debug (plus the message). Why are you deploying debug DLLs?

    It would be interesting to see whether the problem across different PCs even occurs any more if you compiled & released for Release instead?

    getenv does not crash when an environment variable does not exist, it returns NULL. If the code fails to deal with that (e.g. dereferences), that's a different matter, and is the only way it could "crash". So you have verified that the environment variable named ProgramXROOT does not/does exist on the machines which crash/don't crash respectively?



  • @Pablo-J-Rogina
    Exactly! No-one would guess the crash is due to getenvsince all indications were showing that it was either false libraries or graphic card issue.

    @JonB
    I am not deploying anything on that screen. The screenshot is after I clicked on F5 to debug the code and the path of the Qt5Cored.dll is from Qt's installation directory (Qt is installed on D: drive, as I mentioned). getenv crashes on my computer, as well as the deployed executable crashes on the computers if the environmental variable doesn't exist. It is very easy to test by writing a small application.



  • @Lati said in QT deployed executable crashes on some computers:

    It is very easy to test by writing a small application.

    char *p = getenv("ProgramXROOT");
    // or
    char *p = getenv("AnythingElseWhichDoesntExist");
    

    won't crash. It will set p to NULL/nullptr.

    If the program continues and does not check for that, assuming that p will not be null, it may crash. That is all @Pablo-J-Rogina and I are saying.



  • @Lati said in QT deployed executable crashes on some computers:

    programXRootDirectory

    It would be interesting to know what the data type is for this variable. I could not get QString to crash or misbehave.

    {
            char* null = nullptr;
    
            QString test = "hallo";
            qInfo() << "before init null";
            test = QString(null);
            qInfo() << test;
            qInfo() << "after init null";
    
            QString test2 = "hallo again";
            qInfo() << "before assign null";
            test2 = null;
            qInfo() << test2;
            qInfo() << "after assign null";
        }
    


  • @fcarney
    You can reproduce the issue with the following example (at least it crashes on my computer:)):

    main.cpp

    #include "mainwindow.h"
    #include <QApplication>
    
    int main(int argc, char *argv[])
    {
        QApplication a(argc, argv);
        MainWindow w;
        w.show();
        return a.exec();
    }
    

    mainWindow.h:

    #ifndef MAINWINDOW_H
    #define MAINWINDOW_H
    
    #include <QMainWindow>
    
    QT_BEGIN_NAMESPACE
    namespace Ui { class MainWindow; }
    QT_END_NAMESPACE
    
    class MainWindow : public QMainWindow
    {
        Q_OBJECT
    
    public:
        MainWindow(QWidget *parent = nullptr);
        ~MainWindow();
    
        // Senex root directory
        std::string notExistEnvVar;
    
    private:
        Ui::MainWindow *ui;
    };
    #endif // MAINWINDOW_H
    

    mainWindow.cpp

    #include "mainwindow.h"
    #include "ui_mainwindow.h"
    
    MainWindow::MainWindow(QWidget *parent)
        : QMainWindow(parent)
        , ui(new Ui::MainWindow)
    {
        ui->setupUi(this);
    
        notExistEnvVar = getenv("notExistEnvVar");
    }
    
    MainWindow::~MainWindow()
    {
        delete ui;
    }
    

    Compiled with MSVC2015 64bit.



  • You are getting an exception because you are assigning nullptr to std::string. Assign to

    char* ptr = getenv("notExistEnvVar");
    if(ptr != nullptr)
      notExistEnvVar = ptr;
    

    getenv is not crashing

    Edit:
    or use QString

    QString str = getenv("notExistEnvVar");
    


  • @fcarney Thank you :)



  • For std::string s = nullptr, see https://stackoverflow.com/questions/10771864/assign-a-nullptr-to-a-stdstring-is-safe/10771938. Accepted answer:

    Requires: s shall not be a null pointer.

    Since the standard does not ask the library to throw an exception when this particular requirement is not met, it would appear that passing a null pointer provoked undefined behavior.



  • @JonB said in QT deployed executable crashes on some computers:

    undefined

    !!!UNDEFINED!!!
    The end is nigh!

    Good find!



  • @JonB said in QT deployed executable crashes on some computers:

    won't crash. It will set p to NULL/nullptr.

    The problem is not the assignment... the problem comes once you have assigned NULL to the pointer and then you try using it



  • @fcarney

    Obviously, the person who wrote the library didn't know this (to be honest, I didn't know it as well, I have never used getenv). And this is how bugs happened, right? :)

    But interesting thing is that there is no sign about the crash and no-one had an idea about it (including me). I would still look at the error somewhere else if I wouldn't test the code on one of the problem computer.

    Anyway, thank you for the clarification.



  • @Lati
    For the record, getenv() has been in the C runtime libraries since the 1970s(!) There has to be a way for it to tell you that the selected environment variable does not exist (without crashing!), and that is of course by returning 0. I and millions of other coders have been using that behaviour ever since :)

    In your case, whoever wrote the code which does not check for that will doubtless have been working in an environment where that ProgramXROOT variable did always exist, and hence never witnessed the unanticipated behaviour.

    OOI, how have you resolved this? Did you actually change that library's code to fix and recompile, or have you just told your end users they must have that environment variable defined?


  • Lifetime Qt Champion

    @JonB @Lati
    Yes, "man getenv" shows this:
    "RETURN VALUE
    The getenv() function returns a pointer to the value in the environment, or NULL if there is no match."
    It is the responsibility of the caller to check its return value and reacting accordingly...


Log in to reply