I have some problems deploying a simulation application to another computer. Up until a few weeks ago it worked fine to just check out the executable and required DLLs to the target machine. However, since recently I cannot start the application any more on the target machine without getting a windows (7) message stating that the application does not work correctly and needs to close. However, if I rename the application to any other name it works correctly. After renaming it back, it won't start again. It seems that the original name, which is "simspray.exe" btw, is somehow the problem.
Does anyone have an idea where the problem might be?
(I am really curious despite having the rename workaround)
The application uses some libs, mainly qt 4.8.3, qwt, nvToolsExtension (nvidia), glew.
We have tried the following already:
- use a completely fresh PC with newly installed Win7
- depends shows no missing dependencies
- no anti-virus program running, windows defender and firewall disabled, no other third party security tools
- application does not start from within visual studio either unless renaming the output exe name in the project settings
Thanks for any help.
If you have tried it on a completely fresh install then it can't be anything to do with the platform or environment, it must be something in the source code or build process.
If it worked fine up until a few weeks ago then it must be a bug introduced in the last few weeks. Can you check your source control system for changes made in that time?
Try varying the filename you rename to - do longer or shorter filenames have different results?
Try searching for code that uses the executable name in a stupid way, like this:
char buffer[sizeof(argv[0])+1];
strcpy(buffer, argv[0]);
or this:
int len = strlen("simspray.exe");
char *buffer = malloc(len);
strcpy(buffer, GetCommandLine());
Contrived examples I know, but both of these will buffer overflow yet magically appear to work if you rename the file to something of the right length.
Related
I have recently encountered a problem on my Windows 7 machine where I can't run an application with a specific name. Let's call it a.exe.
It is a C++ Qt based app and has been working OK for months but when I tried to run it today I got "The application was unable to start correctly (0x80000003). Click OK to close the application.". This happens for both 32-bit and 64-bit builds for Debug or Release.
I spent hours going round in circles checking dependencies and rolling back to previous versions without getting anywhere. I tried the software on a different machine and it worked, so it must be something on my machine...
I finally discovered that if I rename it to something else (e.g. a1.exe) then it will work :-S
I've checked the VirtualStore folder but couldn't see anything. Any other ideas?
Maybe your "known file extensions" are hided, and you are trying to access a.exe when actually the file name is a.exe.exe?
I developed a small c++ program in Visual Studio 2012 on Windows7, 64bit (let's call it PC1). On that pc it runs fine!
Since I didn't have a versioning control system like SVN at hand, I copied ALL the project data (the exact folder structure, DLLs, source files, project files...) to a usb stick and moved it to another computer.
On that other engine there's Visual Studio 2010 on Windows7, 64bit (PC2).
So I just changed the platform toolset to v100 as described here.
I successfully compiled the project on PC2 (clean, build) and wanted to run the exe, but the command prompt stayed empty.
I then tried to debug and added a breakpoint at the very first line of main - which wasn't reached, the command prompt was still empty.
Ok, a usb stick is certainly not the most secure solution for data storage, so I gave it another try and moved it again - the problem remains.
Visual Studio's output on PC2 is the same as on PC1, so I couldn't find any anomalies there.
Yeah, there might be many error sources, so where can I start?
And how can I get a more verbose output for troubleshooting?
Or is this even a common phenomenon (perhaps due to different VS versions) and there's an simple way fix it?
This is not a full solution, but at least I'm a tiny step ahead:
In my last comment I wrote:
I took your advices into account and created a brand new project on PC2, VS2010. I exactly followed this guide: http://frozenhamster.wordpress.com/2011/02/11/lapack-on-windows-with-visual-studion-2010/
That didn't work either, so I removed I "out-commented" everything except for a single cout. Voila, that worked!
But as soon as I make use of the desired Armadillo (LAPACK and BLAS), the project compils but does not run.
What's going wrong here?
I don't get any compiler errors!
Basically, yesterday I could program in C++ and today I cannot.
I'm trying to write a simple hello world program in Eclipse Helios using the MinGW C/C++ compiler and I'm running into several problems, and I believe this one to be the root of it.
At first the program compiled and built, but when I tried to run it, an error dialogue said the FirstProject.exe file could not be found/does not exist in the launch configuration. However, I got no errors building and I could clearly see the binaries in Debug/FirstProject.exe in my project explorer. I tried refreshing my project explorer and alas, the file disappeared before my eyes.
I tried building the program again, and that's when I get this error:
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: final link failed: No space left on device
I don't know what device it's talking about. I have more than 1TB left on this hard drive, so it can't be that. I tried emptying my %Temp% folder and recycling bin (suggestions I found trying to search for a solution for this problem) but to no avail.
It may be worth noting that C++ programs I have written in the past are still running. I'm very new to programming, so I don't know how much information you need, but I'll gladly add anything you need if you think you can help me out.
I just solved this on one of the computers at work which had the same issue when compiling through Codelite. Moving workspaces, rebooting, and reinstalling Codelite didn't fix the problem. I also checked permissions on the /temp folder which were fine.
It turns out there were permission issues/other issues with the disk. Running a disk check fixed a few issues on the disk and that allowed the program to compile. If this doesn't solve your issue you may also want to try disabling any anti-virus/spyware programs and try again.
I just solved this problem on my PC. Actually what the problem in my case was that my windows defender (or any antivirus in someone's case) was blocking ld.exe from accessing the protected folder that is the source code folder. You can correct this by going into the Virus and threat protection settings of your PC and then find there for blocked history. You will definitely find there a history record of that blockage. Then just go and allow on this device it. And boom 😁
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
...
Gosh, this is so weird, I don't know what to say. The short version is that I have a simulator app which I spawn from my application when the user asks me to. It recently stopped working, though I can run the simulator fine from the command line or Start menu. This could be due to moving to VS2010 or Windows 7 or something I didn't notice reviewing source control diffs.
I have a second simulator which I try to spawn in the same fashion and it works fine.
By default, I'm using Qt3's QProcess wrapper around CreateProcess for this purpose, but I get the same behavior using system, my own CreateProcess, and ShellExecute.
ShellExecute of a cmd.exe "/c application params" does provide me with some more information however. I get the dialog
"The program can't start because MSVCR80.dll is missing from your computer. Try reinstalling the program to fix this problem."
Inconveniently, both the parent application and the second simulator use MSVCR80.dll.
Upon copying MSVC*80.dll from g:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5 to the same directory as my executable, the error message changes to
"Runtime Error!
Program: g:\path\to\app.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
Followed by
The application was unable to start correctly (0xc0000142). Click OK to close the application.
And, once again, the application runs fine from the command line with those dlls in place.
Update:
I suspected perhaps it was environment related, so changed my ShellExecute mechanism to do cmd /c set && app params. I set up a cmd.exe with those same params and my app is now crashing similarly. Will update when I figure out why :)
It is MATLAB's component runtime tool that is modifying my process's PATH variable to bad effect. It is prepending its own dir full of dll's and wreaking havoc.
A foolish tool I was using did a setenv on PATH, prepending a directory it wanted for dynamically loading some dlls, but which messed up my application later. I ended up using GetEnvironmentStrings as shown in the last example here, erasing the first entry in the PATH env var, and sending the new (original) environment to QProcess, which wraps CreateProcessA.
You need to install the CRT
This may work - if it breaks, you get to keep both pieces :-)
Try installing VC++ redistributable from here - http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en.
Remember to backup your system, create a restore point etc. before installing stuff.
Another idea -try reinstalling the failing appliacation itself. It may come with its own copy of VC++ redistributables, and reinstalling might help. Esp. trying to reinstall it using Windows 7's compability mode (perhaps go back to Vista or XP compatibility) might be even more effective.
To reiterate - you'll have to try, and I've no real idea if either of the above ideas will do you good, or even be sure to do no harm. That said, if I were faced with a similar problem, these are the steps I'd try. HTH!