I am facing a problem during the deployment of my Qt Program. This is a cross-platform program (Linux/Mac/Windows) and I am facing an issue when trying to deploy my Win32 version built with Visual Studio 2015 on Windows 10.
I have no problem with building and running the program on the production computer, but when I try to run it on an other computer with a similar configuration it just crashes.
Deployment Specification
Let me be more specific with my deployment method and the error.
As usual I have added the following dll to my release executable :
platforms (Qt folder)
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
and the Visual Studio 2015 redistributable (x86)
Error message
The crash message I obtain is :
Unhandled exception at 0x56E5D96A (Qt5Core.dll) in snapr_exe.exe:
0xC0000005: Access violation reading location 0x00000000.
If there is a handler for this exception, the program may be safely continued.
When I try to debug the program on the target computer with Visual Studio 2015, I obtain the following call stack :
Qt5Core.dll!56e5d96a() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for Qt5Core.dll]
Qt5Gui.dll!572eb949() Unknown
snapr_exe.exe!013c4ae1() Unknown
[External Code]
Qt5Core.dll!56e3d964() Unknown
Qt5Gui.dll!57269edf() Unknown
Qt5Gui.dll!5725bdc5() Unknown
snapr_exe.exe!013f453c() Unknown
snapr_exe.exe!013c1305() Unknown
[External Code]
Other relevant information
At a previous step of the development I could generate an executable that integrated Qt5 and that would work on both computers. Since this time, I have linked the caffe deep learning library, and I have highly-customized the Qt5 user interface.
What's more, I double checked with Dependency Walker that the DLLs I included were really X86 dll.
Any help on this issue would be very appreciated.
Thank you in advance !
platforms Qt5Core.dll Qt5Gui.dll Qt5Widgets.dll are definitely not enough for deployment. depends.exe may show you more missing direct dependencies (as proposed by Chris), but Qt also loads plugins dynamically and depends.exe won't show them. As far as I remember, there's at least the "imageformat" plugins folder that is also required (for png, jpg formats to work properly).
Either you can use windeployqt command, either you figure out what you need by yourself. To do that, I personnaly run the program from Visual Studio. Then, the "Output" window of Visual Studio will list all the dlls being loaded (linked or loaded dynamically as plugins at runtime). You'll most likely see here the ones that are related to Qt that you did not deploy.
I have no problem with building and running the program on the production computer
Tip: rename the folder where Qt was installed/compiled on the production computer and run your program. It will most likely start failing. This is because Qt libraries look for plugins in the current path first and if not found it goes pick them from the folder it was compiled from (absolute path being saved somewhere in the binaries). That's why it almost always works perfectly on the production computer...
Related
I'm writing a project in C++ with SDL2 on 64-bit Windows 10 using Visual Studio 2015. I recently purchased a new Windows 10 laptop and cloned my project from github. My project compiles correctly, but I get the following error when I run it:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
Based on my research so far, this error is usually caused by loading an incompatible DLL, e.g. a 64-bit version instead of 32-bit. Suggestions I've found so far include:
Checking that I'm using the 32-bit versions of the SDL2 DLLs
Installing/reinstalling the x86 version of the Visual C++ Redistributable for Visual Studio 2015
Using Dependency Walker to troubleshoot which DLL is failing
My project is set to build for Win32, and I've ensured that I'm using the 32-bit versions of all DLLs I'm explicitly linking (libfreetype-6, libpng16-16, SDL2, SDL2_image, SDL2_mixer, and SDL2_ttf). I have confirmed that the x86 VC++ Redistributable is installed on my machine.
Finally, I've attempted to use Dependency Walker to determine what DLL might be causing the problem (although I've read caveats that Dependency Walker has a lot of false positives). These were the results:
Dependency Walker static analysis
Dependency Walker profiling results
After that point, the profiler freezes and never continues. Note that the SDL components and the VC runtime are loading without error.
The program compiles and loads correctly on my two older machines, one running 32-bit Windows 7 and one running 64-bit Windows 10.
Now for the actual question. What other steps can I take to debug this crash? Or does anyone see from the information I've provided what I'm doing wrong?
Related questions:
The application was unable to start correctly (0xc000007b)
Win 7, 64 bit, dll problems
Using SDL_image in Visual studio 2010, with error "application was unable to start correctly 0xc000007b"
Edit:
As rflobao suggested, I was using the 64-bit version of Dependency Walker on a 32-bit exe. Here is the new output of my profiling run:
At this point, as before, Dependency Walker freezes. I'm still totally lost and don't feel like I'm any closer to being able to determine what's causing the problem.
Note that Dependency Walker has 32 and 64 bit version. If your application is 32-bit you should use the 32 bit version. Otherwise the Dependency Walker will see the libs to System32 and not SisWOW64.
You image show 32bit and 64bit libs mixed, where 64 has error.
This is by no means completely reliable, but you can give it a try. It requires dumpbin.exe, which is included with Visual Studio.
First, get a list of dependent DLLs for your program, resolved against your path:
del dlls.txt
for /f %d in ('dumpbin /dependents Questless.exe ^| findstr /ic:".dll"') do #echo %~$PATH:d >> dlls.txt
Then get the bitness of each:
for /f "delims=" %d in (dlls.txt) do #echo %d & dumpbin /headers "%d" | findstr /c:"machine (x"
This will produce output like:
C:\Windows\System32\kernel32.dll
8664 machine (x64)
C:\programs\ed23\bin\hydra.dll
14C machine (x86)
Note that this is incorrectly using the kernel32.dll from System32, rather than the WOW6432 one, so it shows that as x64. That's because it just used the path, when the Windows loader will actually use the WOW6432 mapper, SxS, the application manifest, and only fall back on the path if none of those resolve the dependency. It also doesn't find dependents of dependents (you could script recursing through the dependents, but be sure to filter out duplicates), and of course doesn't know anything about run-time explicit dynamic loads.
Nevertheless, it's a quick way to get a short list to check, and might identify your problem.
I feel profoundly dumb, but I finally figured out the real problem. I'm using the SDL font library SDL2_ttf, and I simply hadn't copied zlib.dll from the SDL2_ttf lib directory into my build directory. I don't understand why the error message was so cryptic; in the past missing DLLs have given me a helpful "foo.dll is missing" error message.
Anyway, thank you all for your help. At least I've learned a useful lesson: always make sure all the required DLLs are present before suspecting a more complex problem.
I received the error "The application was unable to start correctly (0xc000007b)" after attempting to run my exe file of my C++ SFML 32-bit program I built in Visual Studio 2012. I statically linked the SFML dlls in my project, but incorporated the following dlls along with my program:
libsndfile-1.dll
openal32.dll
msvcp110.dll
msvcp110d.dll
msvcr110.dll
msvcr110d.dll
What is the problem?
The actual error code that you encountered is 0xC000007B. That is the NTSTATUS error code STATUS_INVALID_IMAGE_FORMAT. That error arises, almost invariably, because the application is 32 bit and attempted to load a 64 bit module, or vice versa. In your case, you state that your application is 32 bit, so it seems that it is attempting to link to a 64 bit DLL. Use a tool like Dependency Walker to diagnose the module which has the wrong bitness.
I don't understand why you are distributing both release and debug versions of the MSVC runtime. You only need one, and that one should be the release versions. The files that end d are the debug versions. You are not permitted to redistribute them.
Error code 0xC000007B can also result if you run an application that has erroneously been statically linked with a .lib file that is an import library corresponding to a .dll (as opposed to a .lib file that is a static library). If you want to know more about the differences between a static library and an import library, see Why are LIB files beasts of such a duplicitous nature?
I was also facing the same problem yesterday. Then I installed the Redistributable setup for VS i.e. vc_redist.x86 for 32-bit machine, after that application start running. You can use either 32-bits or 64-bits setup according your machine.
May it'll help you.
Thanks
I have a simple application which reads a few text files does some calculations and writes a few text files. Works perfect on my development machine (Server2008R2 VC++ 2010). I can't get it to run on a Win7 machine even thought I have installed/run the vs2010 redistribute x86.
The first error I got was missing mfc100ud.dll (yes, I'm using debug, if I try the release it just crashes, as debug tells you what's wrong). I put mfc100ud.dll in the application's directory, now fgets asserts as shown below. str is not null and the file did open successfully.
What have I missed?
My goal here is to just run the MFC app on the Win7 machine without have to install vs2010.
Another consideration, the only reason I am using MFC is for the COleTimeDate functionality. I've looked for alternatives but haven' found anything workable or as simple to use.
Thanks.
Assertion Error
This error occures if the file stream pointer (provided by fopen) is NULL.
Is it possible that you don't have any error checking after you used fopen?
Basically use "static linking" to the MFC and CRT. Than there is no Need to install and copy any runtime files.
Redistributable assemblies are only available for release builds. If you really want to distribute a debug build, you have two options:
link your app statically, so you don't need any shared DLL (such as mfc100ud.dll)
distribute together with your app (in your app folder) all the dependent DLLs. you can check the dependencies with depends.exe
I am running a Qt C++ Project in Visual Studio 2008 and I got this error message:
"The program can't start because QtCored.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtCored4.dll from C:\Qt\4.8.0\bin to the exe program
I run it again, I got:
"The program can't start because QtGuid4.dll is missing from your computer. Try installing the program to fix this problem".
Then I copy: QtGuid4.dll from C:\Qt\4.8.0\bin to the exe program
Then I run it again, I got:
"the application was unable to start correctly (0xc015002). Click OK to close the program.
Then I check the Event Viewer, I see this:
Activation context generation failed for "D:\rest\rrpT.exe". Dependent
Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
could not be found. Please use sxstrace.exe for detailed diagnosis.
First of all, it is very strange to me because I am building and debugging the application on VS2008 but it asks for the dll files form VS2005. Then I copied those files from VS2005:
msvcm80d.dll - msvcp80d.dll - msvcr80d.dll
to the program folder but it is still the same error :(
And I think there is also something interesting:
Activation context generation failed for "C:\Bin\QtSolutions_PropertyBrowser-2.5d.dll". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.
why is that PropertyBrowser is dependent on VS2005?
Any idea?
It sounds like your copy of Qt was compiled with VS2005, thus it probably has a dependency on the version 8 runtime DLLs. But your application is built with VS2008 and thus has a dependency on the version 9 runtime DLLs. In general, you can't get both versions of the runtime DLLs into one process. VC++ tends to break binary compatibility between major versions.
You need to recompile your own copies of the Qt DLLs with VS2008 or develop your application with VS2005.
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).