Im trying to deploy a C++ AMP application to another Windows 7 machine.
I have tried to include the vcamp110.dll in the same folder, and also compiled with /MT do get rid of dependency on msvcp110.dll and msvcr110.dll.
Also tried both x64 and win32 release of the application.
On the computers i have tried it on whitout VS11 installed, the program stops responding.
I tried to do a simple test with the hello world application and i have the same problems there.
The files can be downloaded from here http://www.2shared.com/file/IofZlrJs/amptest.html (source, binary and the dll).
Any suggestions to how this can be fixed?
Deployments like the one you tried are definitely supported – full details here:
http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/12/deploying-apps-built-with-c-amp.aspx
There are a few things you can do to diagnose the issue you are facing yourself:
The bitness of vcamp110.dll has to match the bitness of your app, so 32bit for one means 32bit for the other.
Ensure that there are no other instances of vcamp110.dll in some central location (e.g. system32)
Attach a debugger and see what DLLs are loaded and what exception gets thrown.
Most important of all, for all your apps, surround your parallel_for_each call with try…catch to see what runtime_exception you are getting. More on C++ AMP exceptions can be found here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/01/c-amp-runtime-exceptions.aspx
For the specific repro you shared, we tried that under the debugger on a clean Windows 7 machine and indeed a rutime_exception is being thrown: “The binary for the parallel_for_each is incompatible with this version of runtime.”, which indicates a mismatched runtime version (either mixing bitness or mixing Developer Preview with Beta or something like that).
Related
I am developing my QT application on windows 10 . The development is complete (as for now).
After run the application in debug mode from QT-creator, I am trying to run the executable from the build directory. But it shows me an "Application Error" dialog with the following message:
The application was unable to start correctly (0xc000a200). Click OK
to close the application.
What is the problem and How to fix it ?!
The error codes are given to you in the error message for a reason. They don't mean anything to regular users, but we're programmers and we are the intended audience. Now that Google has been invented, you have absolutely no excuse for not taking the 5 seconds to Google the error code and see what it means.
In this case, 0xc000a200 is an error code that corresponds to STATUS_NOT_APPCONTAINER. The master list of COM error codes is in the Windows SDK headers, specifically ntstatus.h. If one looks this one up, one sees the following description:
This operation is only valid in the context of an app container.
Now, admittedly, once you get to this point, you may discover that you are in well over your head. You may not have any idea what an app container is, and certainly no clue about how to fix it. But at least then you would be able to ask a good question, which will go a long way to getting you a good answer.
But let's see if you can get lucky this time anyway. This error is most commonly encountered when an application that is not inside of an app container tries to load a DLL that is marked as being part of an app container. It is the linker that is responsible for marking a DLL as being or not being part of an app container, controlled by a series of options for whatever linker you're using. On Microsoft's linker, it is /APPCONTAINER:YES and /APPCONTAINER:NO that control this. I'm not sure what toolchain Qt Creator uses, but if it is not Microsoft's, this should at least get you started looking in the right place in that linker's documentation. Make sure that all DLLs used by your application are not being marked as part of an app container.
The option should be off by default for a regular C++ desktop application project, but it's possible that one of the DLLs started out life as part of a Windows Store app. Or it's possible that the switch just got thrown accidentally.
I had the same error, but the approved solution wasn't the cure. What I found is that I had installed the wrong Qt compiler support packages. For me it was Qt 5.9.1 on Windows 10 64 bit to use with Visual Studio 2017. When installing Qt I selected the "msvc2017 64-bit" option. Sound good, right? Wrong: what I wanted was the "UWP x64 (MSVC2017)".
here is some information to understand my situation better.
OS: windows 8.1
IDE: Visual Studio 2008 Pro
Language: C++
i have just my Firefox reinstalled and after this(maybe it was not the reason),
my visual studio Project compiled only with 9.0.30729.6161 VC++ Runtime DLL.
Until yesterday it always compiled with 9.0.30729.8387 VC++ Runtime DLL.
Because of this (or maybe other reason), now i cannot start my Project.exe.
Nothing is changed in source-code. Project-Property and all other things are also unchanged.
I just get the error number 0xc000007b suddenly.
How can i fix this?
It was because of an 32bit DLL, which should not be loaded for my 64bit Project.exe.
I have found this with Process Monitor.
I don't know why, but anyway is the "path" is changed and the 32bit DLL(which has the same name with 64bit DLL) is loaded..
If you have the same Problem, check whether there is a problem between your application and its dependencies using dependency walker.
Entered the answer in another place, but figure it could be helpful for folks who badly need some help:
It has been mentioned in other answers that using dependency walker is the way to go, in my case (my application keeps failing with the error code), dependency walker showed a few dll that are NOT relevant!
Finally figured out that I can run profiling by going to "profile" menu and it will run the application and stop at the exact dll that's cause the problem! I found out a 32bit dll was picked because of path and fixed it.
-Turn off your antivirus software before starting the installation.
-Accept any additional software offered during installation process, since it may be crucial for running your application properly. You can skip things such as search bars, antivirus scanners, registry cleaners and the other software which isn’t directly related to the application.
-Install an application to the system partition (C:). Although this shouldn’t matter, it’s been proven that some apps may return an error if installed on a logical partition.
There is more than one way to solve it. This link might also be helpful.
http://finally-found-the-solution.blogspot.com/2015/02/how-to-fix-0xc000007b-application-error.html
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
This question already has answers here:
Unable to load DLL (Module could not be found HRESULT: 0x8007007E)
(20 answers)
Closed 1 year ago.
I have a 32 bit .Net application winform that invokes a C++ dll. We package the app into an installer and it installs and runs fine on at least 20 or so machines. The app was originally developed and runs fine on a Win 7 x64 machine (mine).
However when I run it on my bosses desktop (Win 7 x64) the application will not launch.
oh yeah...
When I try to launch the application I get a JIT dialog with
System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
When I run depends on the exe on the bosses machine it says that app exe is x86 but that all the dependent dll at x64 and flags it as an error. When I run depends on the app on my machine the exe and dll are all marked x86.
How could this change between machines? The installer is just unpacking and copying in the normal way and works fine on plenty of other x64 machines...
naturally it only breaks on his machine which is two hours away and we have a trade show coming up. sigh.
very confused...
================= solved ==================
So we fixed it. Finding the missing the dll was a bit tricky.
First of all we goofed and we ran the wrong version of depends for an x64 box. So it was incorrectly reporting that the app was looking for x64 dll. If we had run the correct version I think we would have caught the issue sooner.
What solved it for us was looking at the log of Process Monitor from System Internals. It logs every file access and registry read. The log quickly showed a failed read on a Direct X 11 dll.
It turns out that a previous installer from some other app had installed some of the DX11 dll. That fooled our installer, and it skipped the DirectX 11 step so we had a missing dll.
Thanks for the help guys!
It is a simple "file not found" kind of error, but with the very awkward behavior that it doesn't tell you what DLL could not be found. Which might be the C++ DLL but also any implicit DLL dependencies it might have. Like the runtime support DLLs, very commonly missed, you can deploy them with the vcredist installer. Or deploying the Debug build of the DLL, that can't work.
Getting a decent diagnostic requires turning on loader snaps and a debugger. Invariably hard to do on a machine that doesn't have tools installed. The SysInternals' ProcMon utility is an excellent alternative, you'll see the program searching for the DLL. Albeit that you'll drown in the amount of trace data it generates. Work from the bottom of the trace backwards.
I have searched and found no answer to this
I have a weird problem when running executables through developer studio (2008): a basic 'hello world' exe works OK when created through the usual dev studio project creation mechanism, but when trying to run a library based program the software crashes with STATUS_BAD_NETWORK_PATH. The program uses Qt and zlib behind the scenes and is written in C++, but (as far as I'm aware) is not dependent on any particular network locations on initialisation; we do have Sophos installed on the PC too.
The weird thing is that one cant even step into the main: the program fails well before this with the error. If we plug the network in, it starts up just fine ... The odd thing is this only occurs on a specific 64 bit Windows 7 machine.
Does anyone have any tips as to how to trace where the issue is? We've tried tracking using procmon but it is not very revealing; no obvious failures up to the point where the program crashes.
We have now figured out the answer. It transpired that there were 2 issues:
Firstly a wrapper .bat script that was launching developer studio was setting the PATH environment variable: a location in this path was being specified using a UNX style path (e.g. \\a\location\somewhere) rather than a mapped drive. The executables were not actually using this location but when the network was unplugged this it seems that this was disrupting things from dev studio
This, in tandem with a network configuration error on the PC, meant that deep down in the runes, something was failing.
So - advice if you see such an error
Check your PATH and make sure it is sensible
Look in your PC's configuration logs, and see if you can see any networking issues
...