PDA

View Full Version : Is APPCRASH caused by QtCore4.dll with red Link Checksum in Dependency Walker?



papayaqt
29th August 2016, 10:20
My developing environment is like this:
*Windows 7 Ultimate 64 bit (later I also tried on Windows 7 Ultimate 32 bit in virtual machine)
*Qt Creator 2.8.0 (qt-creator-windows-opensource-2.8.0.exe from download.qt.io, which is based on Qt 4.8.4, MSVC 2010,32bit shown in about dialogue window), installed in C:\Qt\qtcreator-2.8.0.
*Qt 4.8.5 (qt-win-opensource-4.8.5-mingw.exe from download.qt.io), installed in C:\Qt\4.8.5.
*mingw gcc 4.4 (MinGW-gcc440_1.zip), installed in C:\Qt\mingw.

And Qt Creator are configured like this:
* Qt version: C:\Qt\4.8.5\bin\qmake.exe
* Compiler: C:\Qt\mingw\bin\gcc.exe

I built my own program well and deployed the application both in my computer with Qt environment and other computers without Qt environment. It contains myapp.exe, libgcc_s_dw2-1.dll, mingwm10.dll, QtCore4.dll, QtGui4.dll, QtNetwork4.dll, phonon4.dll, some 3rd party DLLs and plugins like phonon_backend and imageformats. It seemed to run well until I found an APPCRASH problem:

Problem Event Name: APPCRASH
Application Name: myapp.exe
Application Version: 0.0.0.0
Application Timestamp: 56ed4592
Fault Module Name: QtCore4.dll
Fault Module Version: 4.8.5.0
Fault Module Timestamp: 51cc9d40
Exception Code: c0000005
Exception Offset: 0005d13c
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 2052
Additional Information 1: 0a9e
… …

The crash occurs randomly especially after long term running (one day or more). Sometimes when crash happens, myapp still works normally (show other dialogs or communicate with cloud server).

I have seen the myapp.exe through Dependency Walker (v2.2 for x86) also and it shows me red color in Link Checksum field of QtCore4.dll (and IESHIMS.dll missing). The help contents of Dependency Walker tell it means that checksum does not match the actual module checksum, or the module has been modified after it was built.

But I do copy Qt library DLLs from C:\Qt\4.8.5\bin\. I am also sure MinGW 4.4 is used as compiler.

So what is wrong about APPCRASH? Is link checksum issue related to that problem? Or some platform confusion over 32 bit and 64 bit system? Are there any solutions? Thanks a lot.

P.S.1
I also tried compiling a Qt example (named books) on Windows 7 Ultimate 32 bit in virtual machine and deploying on other virtual machine without Qt environment. But link checksum field of QtCore4.dll is red. I also tried changing developing environment to this:
*Qt 4.8.7 (qt-opensource-windows-x86-mingw482-4.8.7.exe from download.qt.io), installed in C:\Qt\4.8.7.
*mingw gcc 4.8.2 (i686-4.8.2-release-posix-dwarf-rt_v3-rev3.7z from download.qt.io), installed in C:\Qt\mingw32.
But still link checksum field of QtCore4.dll is red.

P.S.2
I noticed that modify datetime of QtCore4.dll and QtCored4.dll in C:\Qt\4.8.x\bin varied to the datetime of its installing, while other DLLs’ remain as when they complied. Is this normal?

d_stranz
29th August 2016, 16:01
c0000005

This is an access violation. It means your program has tried to use a pointer that is NULL or points to an invalid memory location, has walked off the end of an array, or has otherwise tried to read or write to an invalid memory location.

If you are writing a server app of some sort and you have a memory leak (eg. allocate memory for something that never gets deleted) then your program could simply be running out of memory after "long term running". The next time it calls "new" to create an object and the memory is not available, it returns a null pointer. If you don't check for that and try to use it, your program will crash with the access violation.

d_stranz
30th August 2016, 15:35
The next time it calls "new" to create an object and the memory is not available, it returns a null pointer. If you don't check for that and try to use it, your program will crash with the access violation.

By the way, if this is the case, it doesn't have to be -your- code where the crash actually happens. It could be -any- place where "new" fails to allocate memory. The trace indicates it is inside of QtCore4.dll. But if there -is- a memory leak, it is almost certainly your code that's at fault for causing it. So look at your code first and don't put the blame on Qt.

papayaqt
31st August 2016, 04:02
I really appreciate your help! Yes, a code mistake may causing memory leak is found. I am testing. And I realize I should carefully check my whole program right now before its growing. As a beginner in Qt, I never put the blame on it. I’m only curious about what I found. : )

I still want to know if it is normal or not about red color in Link Checksum and modify datetime of QtCore4.dll different from other Qt DLL files in the same bin directory. Did I make any mistakes in Qt installation or program building?

And thanks a lot again for your kind help.

d_stranz
31st August 2016, 15:52
I still want to know if it is normal or not about red color in Link Checksum and modify datetime of QtCore4.dll different from other Qt DLL files in the same bin directory. Did I make any mistakes in Qt installation or program building?

The Link Checksum problem may mean that "depends" is finding a different version of QtCore4.dll in your PATH than the one you linked to when building your project. It should tell you the location, so check that to see if it is the same as the one you build against. Also make sure that the import library (QtCore4.lib) and runtime DLL (QtCore4.dll) are the same Qt version.

In my mingw install of Qt 5.4.1, -most- of the Qt DLLs have the same date / time stamp, but not all of them. I don't think this is anything to worry about.