PDA

View Full Version : Windows 7 DLL Conflicts



EF2008
8th March 2010, 19:57
Hey all

I've just ported my system from XP to Windows 7 Professional as a test to see if development there was possible in a 64bit environment.

I installed the complete SDK from the QT downloads page, installed it without a hitch. I'm using Qt 4.6.2 with MinGW, and Qt Creator 1.3.1

After aligning all my other DLL's, I was able to get a full and successful build.

However, when I try to execute the program from within the IDE, I get this error message in the application output tab:



Starting C:\vcpp\admin\bin\admin.exe...
C:\vcpp\admin\bin\admin.exe exited with code -1073741515


And no program loads.

It appears as though this problem has plagued many people, and as much as I've googled around, I haven't found a cohesive answer to the problem, other than that it is an issue with my DLL's.

So I ran Dependency Walker on admin.exe, and in the output pane at the bottom I got this:



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.


At the very top of the module list there are two DLL's that don't seem to be found:



GPSVC.DLL Error opening file. The system cannot find the file specified(2)
IESHIMS.DLL Error opening file. The system cannot find the file specified(2)


I'm not sure how either of these DLL's are supposed to be interacting with my program, particularly the IESHIMS.DLL, which is an Internet Explorer library, though I'm assuming IESHIMS.DLL has a dependency on GPSVC.DLL, which didn't load.


I can run the program from C:\vcpp\admin\bin, where the executable is stored. However, I cannot run it from within the IDE without getting the error message above, which means, among other things, that I cannot run the debug. And more than anything, I'm at a loss as to what to do, or even what I should be looking for so I can proceed to fix the problem.

Any help would be more than welcome! Thank you in advance!

john_god
11th March 2010, 02:54
Just a shot in the dark, chcek this thread (http://www.qtcentre.org/threads/26604-Runtime-problem-in-Release-mode/page2)

ChrisW67
17th March 2010, 23:21
IESHIMS.DLL shows as unresolved on every program I've ever run Depends.exe on. It is not the problem. The other one I've not seen before.

Are you sure you have the correct Qt DLLs in the path or application directory (searched first). Check that you have the files from the Qt you built and not the ones that Qt Creator was built with. You should also check release vs. debug Qt DLLs.

eldecog
5th May 2010, 12:53
I have exactly the same problem except that my program start but is really slow at start up.
With previous installation of Qt I remember my program started very quickly and it can take up to 10seconds to start!!
How can I solve this problem and speed up the starting process of my program? Because after start up, the program runs normally...
Thanks

TorAn
5th May 2010, 18:39
My experience:
I had a similar problem which I spent couple of days solving. It turned out that in the installation of the release build I accidentally included one of the qt dlls that was a leftover from 4.1. So, out of 5 Qt dlls I had 4 coming from 4.2 and 1 from 4.1. It caused my application to fail with the message (I can't recall exactly what was the message) that was cryptic enough that I had to check a lot of other things before I stambled accross the date of this offending dll. Onlly then I realized that it came to the release install from the times of 4.1. So, the advise it - ensure that alll qt dlls that are included in your release are from the same qt build and not from earlier qt releases.

Another issue was the bug in Qt (http://bugreports.qt.nokia.com/browse/QTBUG-10305?page=com.googlecode.jira-suite-utilities%3Atransitions-summary-tabpanel)(which I reported, it was accepted as a bug and the status is that it will be fixed in the future qt releases) is that QLibrary.fileName returns "dll" on Vista and "DLL" on Windows 7. So, if youi application does some manual loading you want to check this. The workaround is to convert the path to lower case prior to call "isLibrary".

Hopefully this information will be useful.