QT environment generates dump to solve abnormal crash

background

For regular use C/C++ For my partner , If there is a problem with the procedure, the problem of strike collapse is simply not familiar . For example, local tests are released through packaging release edition Qt Program , Abnormal crash may still occur in the customer environment . Generally, through customer feedback and analysis of system operation logs , Basically, all problems can be solved quickly . But there will always be some bug Hard to locate , In this case, by generating dump file , combination winDbg Program positioning will be a good solution .

Specific operation

One 、 Generate dump file

stay QtCreator Generation... Is not supported by default in dump file , And release release The mode does not contain debugging information , Therefore, the following two steps are required .

1. stay .pro Add the following statement to the file , To generate debugging information and pdb file

QMAKE_CXXFLAGS_RELEASE = $$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_LFLAGS_RELEASE = $$QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO
LIBS += -lDbgHelp

2. Adding in the program file can produce dump File code . Code can be copied directly , No more meaning

LONG crashHandler(EXCEPTION_POINTERS *pException)
{
    
    QString curDataTime = QDateTime::currentDateTime().toString("yyyyMMddhhmmss");
    QString dumpName = curDataTime + ".dmp";

    HANDLE dumpFile = CreateFile((LPCWSTR)QString("./" + dumpName).utf16(),GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if(dumpFile != INVALID_HANDLE_VALUE)
    {
    
        MINIDUMP_EXCEPTION_INFORMATION dumpInfo;
        dumpInfo.ExceptionPointers = pException;
        dumpInfo.ThreadId = GetCurrentThreadId();
        dumpInfo.ClientPointers = TRUE;

        MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(),dumpFile, MiniDumpNormal, &dumpInfo, NULL, NULL);
        CloseHandle(dumpFile);
    }
    else
    {
    
        qDebug() << "dumpFile not vaild";
    }
    
    return EXCEPTION_EXECUTE_HANDLER;
}

// prevent CRT（C runtime） Function error may not be caught 
void DisableSetUnhandledExceptionFilter()
{
    
    void* addr = (void*)GetProcAddress(LoadLibrary(L"kernel32.dll"), "SetUnhandledExceptionFilter");
    if(addr)
    {
    
        unsigned char code[16];
        int size = 0;

        code[size++] = 0x33;
        code[size++] = 0xC0;
        code[size++] = 0xC2;
        code[size++] = 0x04;
        code[size++] = 0x00;

        DWORD dwOldFlag, dwTempFlag;
        VirtualProtect(addr, size, PAGE_READWRITE, &dwOldFlag);
        WriteProcessMemory(GetCurrentProcess(), addr, code, size, NULL);
        VirtualProtect(addr, size, dwOldFlag, &dwTempFlag);
    }
}

int main(int argc, char *argv[])
{
    
    // Register exception capture function 
    SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)crashHandler);
    DisableSetUnhandledExceptionFilter();

    QApplication a(argc, argv);
    Widget w;
    w.show();

    return a.exec();
}

3. Clear and re qmake function , produce pdb Documents and running procedures . In this case, the application crash will occur at the predetermined location dump file .

Two 、 Use dump file

1. Suppose the program crashes and gets dump file , open winDbg Software ( You need to download , Easy to install ), Set the source code paths respectively 、pdb File path 、dump route , After confirmation, the software jumps to the analysis interface .

2. Click auto analysis （!anasyle -v）, Generate stack information , Then you can see the number of error source code lines

matters needing attention

The above provides an idea to solve the abnormal crash , Not the ultimate solution , Although there is no guarantee 100% solve the problem , But it may have miraculous effects , Personal suggestions are still based on logical analysis , Problems can be basically solved , It can also exercise the ability of analysis , Avoid writing similar bug.

Here are some points to note ：
1. It should be packed exe,pdb, The source code version is consistent , Otherwise, there may be deviation in debugging .
2.dump Documents are not guaranteed to produce , Some errors may not be caught .
3.!anasyle -v After automatic analysis , Most of the time, you can directly locate the number of error lines , intuitive . But there are also cases where the number of rows cannot be found , But having clear stack information can help analyze the problem .