I have mfc application that working fine on the machine with VS 2013 pro. But when I try to run it on the other pc which has VS redistribute package 2013, VS remote tools. Nothing happening. I can see in the task manager that it is started but then it goes away...
What I have tried so far:
1) I used Dependency Walker to find dll that my application depend on. And for my setup project I add MSVCR120.dll, the rest of the dll's were mfc120.dll the ones that part of the OS i didn't add it them, because I got warnings if I'll add dll which is part of the OS and another PC has exactly the same Windows 7 so they are on the PC.
2) I used VS remote debugger, and at this time I got this First-chance exception .. _com_error at memory location. But I can't catch it. I don't know where to look. My call stack look's that this.
3) Last out put before error, says that sqloledb.rll was not loaded, I check it systems folder does have it, I even copied to the folder where application executable located, still does not loaded, still have exception.
Can any one point me to what can cause this error or why application does not run? What else to install so my application can run the same way it is run on the machine with VS. It is seems that this error rise often but none of the solution helped me.
I used procmon.exe and it is shows buffer overflow.
It is turn out to be database connection. Application quite on this line, so I add try/catch block. But shows "unexpected error"...
m_pAppConn->Open("File Name=MyData.udl", "", "", adConnectUnspecified);
m_pAppConn is a _ConnectionPtr. On my pc I have MS SQl Server Enterprise, but on target pc MS SQL Express, could it be the issue?
Related
I write a c++ program using visual studio 2015 community in windows 7(64bit).
When I begin to run the program, sometimes the program will terminate, and a dialog box shows up, saying
"Application failed to initialize properly 0xc0000018".
Why do I get this error sometimes rather than always?
Thanks a lot.
Besides a bad application itself (that should be possible to track in the debugger):
This might be a corrupted Windows installation or Windows registry as well. Do you see it only for your application or also for some other applications?
It might be caused e.g. by some DLL that is built to be installed at fixed address, it might be a virus, malware, or even antivirus getting into the way.
Some of the reasons/solutions are mentioned e.g. here: https://superuser.com/questions/610495/the-application-was-unable-to-start-correctly-0xc0000018-windows-8-x64
The first thing to try is to remove the contents of APPINIT_DLLS in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\Windows - some of the DLLs loaded there might cause the problem.
The reason you do not see it every time could be that sometimes there might be some other DLL loaded on the particular address before the DLL with the fixed address requirement is to be loaded, so the conflict only occurs then.
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.
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).
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
...
I've written a quick C++ console app using VS2010. I'd like to run it via the remote debugger on the Windows Server 2008 platform, in order to determine why I can't enumerate the CLSID_AudioInputDeviceCategory on that OS.
The console app works on the XP and W7 platforms.
The remote debugger gives the following error when I first tried to run the console app:
The program can't start because MSVCP100D.dll is missing from your computer. Try reinstalling the program to fix the problem.
I did try just copying this DLL from my development machine to the target folder on the remote machine, but it returned an even more obscure message:
The application was unable to start correctly (0xc0000007b). Click OK to close the application.
I've tried installing the VS2010 C++ re-distributable on the target host. This has no effect. I'm out of ideas, does anyone have any suggestions?
Having spent some time on this problem, I've noticed that the Windows Audio service on server 2008 was disabled, but my query is more to do with getting remote debugging working on the server 2008 platform than solving my audio hardware enumeration problem.
Thanks to Errata, I had a look at
Project Properties -> Configuration Properties -> C++ -> Code Generation
I changed Runtime Library from Multi-threaded Debug DLL to Multi-threaded Debug (/MTd).
This allows remote debugging without having to rely on the correct debug DLLs residing on the remote machine.
I hope this helps someone out there!
I had this exact situation. I grabbed copies of MSVCP100D.dll and MSVCR100D.dll. However I grabbed them from system32 (the 32-bit version), which resulted in the 0xc0000007b error.
0xc0000007b apparently means invalid DLL, often architecture mismatch between program and DLL (i.e. x86 and x64). In my case I grabbed the wrong (32-bit) version of the DLL from my developement computer resulting in 0xc0000007b. After grabbing the file from SysWOW64, it worked.