Qt Project doesn't work anymore on the same system (Qt 5.5, Windows 8.1, x64)

maroney

Hi everyone,

I had a Qt Project running on a workstation. But after some changes in the network system and I guess some little updates on the OS (Windows 8.1 Pro, x64) the project throws following error message upon initialisation on the same system:

Unhandled exception at 0x00007FFC9C7F7EC6 (Qt5Gui.dll) in main.exe: 0xC0000005: Access violation reading location 0x00000000000000D8.

I ran the Dependency Walker on the release exe with following result:

alt text

All missing DLLs are connected to the system32 DLLs in the dependency tree. But I can hardly figure out how to solve the problem. Also I couldn't even find those DLLs (like "EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL") on the system itself.

I would highly appriciate every hint on how to solve the issue.

Thanks!

[SOLVED] Look here.

maroney

Just to show how I already tried to solve the issue based on former posts:

copied the missing DLLs to my release folder
--> Dependency Walker Log : " At least one module has an unresolved import due to a missing export function in a delay-load dependent module" (refers to more the than the copied DLLs)
Installed the Redistributable Package (x86/x64) from Microsoft
Deleted the Qt DLLs (Qt5Gui.dll, Qt5Core.dll...) from the project folder and ran windeployqt

SGaist

Hi,

Access violation ? Did you try to run the application through the debugger ?

maroney

Yes, the debugger throws the same error

Unhandled exception at 0x00007FFC923DA79A (Qt5Guid.dll) in main.exe: 0xC0000005: Access violation reading location 0x00000000000000D8.

(well, changes Qt5Gui.dll to Qt5Guid.dll) and stops in the main thread at stack

Qt5Guid.dll!QOpenGLFunctions_3_3_Core::glEnable(unsigned int cap)

Here d_1_0_Core (QOpenGLFunctions_1_0_CoreBackend) and this and all undelying variables can't be read from memory (VS: "Unable to read from memory" respectively for this: "Information not available, no symbols loaded for main.exe").

SGaist

Did you use windeployqt to do the deployment part ?

It looks like you might be missing a plugin/plugin dependency.

maroney

Yes. I also used windeployqt. But this didn't change anything. Also the same setup with the same Qt related DLLs already worked on the same machine. To be honest I was just told so, that it was all working half a year ago and now after some month without usage the error occurs.
Because it's also not working on a similar machine, I rule hardware failure out. My guess is on some windows or driver updates. Hoped this may be a problem some other Qt developers already had to face.

SGaist

What kind of graphic card do you have ?

maroney

I'm using a nvidia geforce 980. already updated the driver.

SGaist

Strange... Can you update to a more recent version of Qt ?

maroney

Already updated to Qt version 5.7. Still not working.

SGaist

5.8 has just been released.

ambershark

@maroney I've seen this when you don't have your platform plugins installed properly.

What does the directory structure of your application look like? It should be something like this:

app/
   app.exe
   libs/
      qt*.so
   plugins/
      platforms/
         *.so

It doesn't need to look exactly like that, i.e. libs and where your exe is but the location of your platform plugins is very very important. And sometimes it doesn't tell you it can't load one it just crashes like that.

You can also make sure it is looking in the right place with a qt.conf file:

[Paths]
Plugins = ./plugins

maroney

[SOLVED]
I was able to solve the problem. Maybe someone else comes along similar issues...

The compiling failure didn't come from the code, but from the system itself. Most propably the graphic card was damaged during a transport. I setup a different workstation with the exact same specs as the previous one and I was able to compile the code.

Also some issues came from the Windows Remote Desktop connection to the workstation, which has it's difficulties with OpenGL.

Thanks for all the answers.

ambershark

@maroney Wow... I hate it when it ends up being hardware related. It's something I almost never suspect because it is so rare and so hard to track down.

Glad you got it fixed though. :)