Application crash on startup : error 0xc0000005
-
Hi all,
I'm experiencing a strange problem. A qt application I've made runs correctly on a windows system for some time, then it suddenly stops running (client says he didn't do anything and that it just stopped working). Once this happens, the application cannot start anymore (tried reinstalling the app but no luck).This is what I get from the Windows event data:
- EventData dvr.exe 0.0.0.0 5bc9a6c8 Qt5Widgets.dll 5.10.1.0 5a7c81df c0000005 0000a5d1 9c0 01d4678f90f8204c C:\Program Files (x86)\MyApplication\dvr.exe C:\Program Files (x86)\MyApplication\Qt5Widgets.dll c1810371-6c4e-40c1-850d-a6d825c11cf9
Any clues to what might be causing this problem?
-
@JonB said in Application crash on startup : error 0xc0000005:
@nwoki
I'll be amazed if anyone can tell you anything from this information! (error 0xc0000005
is "Access violation error", so memory is being accessed wrong, that's about it) But we'll see....I know. And that's about it for the info i get from the application under windows. I can't reproduce this problem on Linux. Anyone got any clues on how I can get more debug info for you guys?
-
@nwoki said in Application crash on startup : error 0xc0000005:
A qt application I've made runs correctly on a windows system for some time, then it suddenly stops running (client says he didn't do anything and that it just stopped working). Once this happens, the application cannot start anymore (tried reinstalling the app but no luck).
How long is "some time"? A few minutes? A few hours? A few days?
What do you mean by "the application cannot start anymore"? What happens when you try to start it?
Finally, how does the crash occur? Does it crash while your client is in the middle of using it, or does it crash at startup?
-
@nwoki Well it would be good to start with a windows vm development environment that you can reproduce the problem. That will let you attach to a debugger and get some useful information.
Another way is to build with map files and debug info. Then based on the crash/memory dump you can find which line of code your app crashed on. This can be daunting and a bit complicated if you've never done it before. And adding debug symbols may change the app enough that it "works" which doesn't really help since you know there's an issue but it gets masked by the debug binary.
Finally, this is why everything I write has massive amounts of logging. I even use kind of a "call stack" type thing in my logging code. So every function that is entered and exited gets a log message. This lets me narrow down a crash on a customer's system with nothing more than a log file they provide. That isn't helpful if you didn't do it from the start though as it would take a lot of time. Something to note for the future.
If I had to throw out a complete guess, you probably have mixed Qt versions on the target system. Try using a dependency walker to see what Qt (and other) DLLs it is linking to and using. That is the usual culprit when something that worked before stops working with no update. It usually means a DLL got updated somewhere and broke it.
-
@JKSH said in Application crash on startup : error 0xc0000005:
@nwoki said in Application crash on startup : error 0xc0000005:
A qt application I've made runs correctly on a windows system for some time, then it suddenly stops running (client says he didn't do anything and that it just stopped working). Once this happens, the application cannot start anymore (tried reinstalling the app but no luck).
How long is "some time"? A few minutes? A few hours? A few days?
A few days/1 week
What do you mean by "the application cannot start anymore"? What happens when you try to start it?
When launched the application doesn't start. From the windows Event viewer i can see the application throw an error there but no window is ever presented. I don't think the application ever gets to launch
Finally, how does the crash occur? Does it crash while your client is in the middle of using it, or does it crash at startup?
On startup. Doesn't even show initial screen
-
Using the profiler as suggested by @ambershark I get the following.
Error: At least one required implicit or forwarded dependency was not found. Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module. -------------------------------------------------------------------------------- Starting profile on 22/10/2018 at 14:03:40 Operating System: Microsoft Windows NT/2000/XP/2003/Vista based Professional (64-bit), version 6.02.9200 Program Executable: c:\users\pcuser\desktop\release_old\DVR.EXE Program Arguments: Starting Directory: C:\Users\pcuser\Desktop\release_OLD\ Search Path: C:\Program Files\Hardwipe\;C:\app\pcuser\product\11.2.0\client_1\bin;C:\Program Files (x86)\Intel\iCLS Client\;C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Intel\iCLS Client\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Users\pcuser\AppData\Local\Microsoft\WindowsApps;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\ Options Selected: Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable. Log DllMain calls for process attach and process detach messages. Hook the process to gather more detailed dependency information. Log LoadLibrary function calls. Log GetProcAddress function calls. Log debug output messages. Automatically open and profile child processes. -------------------------------------------------------------------------------- Started "DVR.EXE" (process 0x1878) at address 0x011B0000. Cannot hook module. Loaded "NTDLL.DLL" at address 0x779E0000. Cannot hook module. Loaded "KERNEL32.DLL" at address 0x76FE0000. Cannot hook module. Loaded "KERNELBASE.DLL" at address 0x77670000. Cannot hook module. DllMain(0x77670000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" called. DllMain(0x77670000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" returned 1 (0x1). DllMain(0x76FE0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called. DllMain(0x76FE0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1). Injected "DEPENDS.DLL" at address 0x08370000. DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called. DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1). Second chance exception 0xC0000005 (Access Violation) occurred at address 0x63D4C000. Exited "DVR.EXE" (process 0x1878) with code -1073741819 (0xC0000005).
This is the first time debugging a problem of this kind (I usually develop under linux). I see there are some problems "hooking modules". Might that be somewhere to start off from?
Any ideas?
-
Hi, the profiler says the crash is inside dvr.exe and not in a Qtxxx dll.
So you could try using Process Monitor.
Start procmon.exe and set it to filter out all events except for your dvr.exe (that way you will not get swamped by thousands of events from other programs like explorer.exe etc.)
Then start dvr.exe and when it crashes, look in procmon.exe's window to see what the last events were before dying... -
@nwoki The hook module issues aren't a problem. That is normal and you can ignore that.
If you can duplicate this crash on a virtual machine or on the customer's machine then you could install a debugger (like WinDbg) and run the application in there to see what the backtrace shows. I'm a linux guy too so I'm not sure WinDbg will do what you need but it sounds like it should.
This would be equivalent to
gdb ./dvr
in linux and then when it crashes doing abt
. That should give you some insight as to what is crashing. If you can't duplicate it on your machine you are stuck with adding logging (a lot of work), or doing the map file and debug info in your exe so you can find where the crash happened based on a crash log from the customer.This may help if you go the pdb/map route:
https://stackoverflow.com/questions/7007874/finding-location-of-crash-using-map-file -
A quick update. I got the client to give me his computer for debugging next week. I'll update you with the info on what @hskoglund and @ambershark advised to do. Thanks
-
@hskoglund Hi, finally got my hands on the client's pc. This is what happens with ProcMon (hope I'm using it correctly. Not a power windows user.)
This is basically what happens when i launch the process and then veiw the process tree. For the events, I have this.
QtCharts having problems?
-
Hi, yeah if you run dvr.exe again a few times and it always crashes after loading the qtchartsqml2.dll, then it could be worthwhile to try a version of dvr.exe rebuilt without any Qt Charts functionality. Simplest would be to comment out those pieces of code, remove "QT += charts" the from the .pro file, rebuild dvr.exe and run the modified version on the client's pc.
But first thing you should do on that client's pc is to update the graphics driver, that might be an easier way to solve the problem :-)
-
Did some more tests, as suggested, removed the QtCharts from the application and tried to force angle with
QApplication::setAttribute(Qt::AA_DisableShaderDiskCache); QApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
Without charts
Now the last thing it seems to load before crashing si the
QWebProcess.exe
file. I tried to run it by itself and it as visible in the process monitor. I then check the process when launched with Qt and I found this:"C:\Users\user\Desktop\GOFORIT\QtWebEngineProcess.exe" --type=renderer --disable-gpu-memory-buffer-video-frames --disable-shared-workers --enable-threaded-compositing --disable-mojo-local-storage --no-sandbox --use-gl=desktop --enable-features=AllowContentInitiatedDataUrlNavigations
Might this have anything to do with the crash?
I'm starting to begin to think that it's a problem related to the intel drivers of the card as i've found others with problems like mine here and here.
Plus, this is the only computer that presents this problem. My windows machine, and that of my collegues that have a dedicated graphics card, run the application without any fuss.
-
Using windows debugger, I get the following error
ModLoad: 5ed00000 5ed58000 C:\Users\user\Desktop\goforit\qml\QtCharts\qtchartsqml2.dll (2a38.880): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\Qt5Widgets.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\user\Desktop\goforit\Qt5Widgets.dll - *** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\app.exe *** ERROR: Module load completed but symbols could not be loaded for C:\Users\user\Desktop\goforit\app.exe eax=004ff830 ebx=606ea6e0 ecx=baadf00d edx=00000000 esi=baadf00d edi=00000005 eip=606ea5d1 esp=004ff7d0 ebp=004ff848 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 Qt5Widgets!QAction::setText+0x1: 606ea5d1 8b7104 mov esi,dword ptr [ecx+4] ds:002b:baadf011=????????
First time I get this sort of error. Anyone know what might be the cause for it?
-
Hi, that baadfood address in ecx is a fallback value for uninitialized objects on the heap, it could be that you're trying to set the QAction text for a bad QWidget/OpenGL window. Again, this could mean that the Intel graphics driver needs to be updated...
-
So, turns out that the only error message that was telling the truth was the one regarding the QAction :
Qt5Widgets!QAction::setText+0x1:
.What was happening was the following:
I've implemented a "Recent files" QMenu where i set the last 5 recent files used by the client. What happened in this particular case was that the client removed some recent files that were stashed by my application (their path url) and so when I want to load them into the menu with:
for (int i = 0; i < recentFiles.count(); ++i) { QAction *rf = m_recentFilesActions.at(i); rf->setText(QFileInfo(recentFiles.at(i)).fileName()); rf->setData(recentFiles.at(i)); rf->setVisible(true); }
the application crashed.
What threw me off was the first part of the debug message
(2a38.880): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\Qt5Widgets.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\user\Desktop\goforit\Qt5Widgets.dll - *** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\app.exe *** ERROR: Module load completed but symbols could not be loaded for C:\Users\user\Desktop\goforit\app.exe
which led me to think it was a problem concerning the graphical driver of the client as he told me he had done some updates lately and that the access error was related to the QWidgets.dll file.
Once I fixed that, the application went back to normal. Thankyou @ambershark and @hskoglund (you're last comment helped me find the problem) for your help. I've also learned a few things on debugging under windows (i'm a linux guy).
-
@nwoki
I really do not understand this, for two reasons:-
When you try to create a
QFileInfo(QString filepath)
it does not fail if the path does not exist. If it did, there would be no point in having e.g. aQFileInfo::exists()
function. AFAIK, theQFileInfo
methods treat the filepath as a string to parse to produce results for extracting segments; they only try to access the file when a function which needs to do so is called. I therefore assumeQFileInfo(recentFiles.at(i)).fileName());
would return the filename part of whatever you passed in. -
Even if that were not true, then either it would throw some exception possibly or it would return, say, an empty string for the filename. You would pass that to your
rf->setText()
, and whatever that did it would not "crash" on trying to set some text.
I should be obliged if a Qt expert would correct me if the above is not true? Otherwise I do not see how in itself it would lead to the behaviour you have previously shown, which is why I asked.
-