I developed a project on VS 2010 using c++ qt. When I run the project in debug or release mode it works great. But what I want is to run it by double clicking on the generated executable, unfortunately when I do that I get a R6010 Error .. abort has been called.
I want to solve this problem to help me creating an installer for my project.
Thank you in advance.
It happened to me exactly the same, and the problem was that the executable was reading a configuration file and some image files that were not in the same directory as the executable, and obviously nonexistent program attempted to read files so the error occurred. What I did was copy the files that are read from my program to the same directory where the executable is found and everything was arranged. Check if this is your case. Greetings!
Today I had the same error, my solution was to debug and checking if specific call of C++ function reads or writes data out of range. In my case I was trying to access to element of STL container that didn't exist.
http://www.cplusplus.com/forum/beginner/41485/
Most likely you are running out of Virtual Address space. Possibly because you are making x86 binary and that is restricting the VA space that user mode process will get. Try using x64 binary. Memory management of Win 8.1 is much better than Win 7 (Win7 becomes unresponsive when footprint reaches GBs)
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.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.
I have been trying to find a solution for this problem but I haven't been able to see/find any answer that correctly solves it.
I coded a program (Qt + OpenCV) that works fine when I run it with Visual Studio, but trying to run the executable it simply does not execute anything. The program doesn't give any error: it just never starts.
I am not sure where to start checking what is happening and why it is not even starting (I could understand lack of libraries, some other error..).
I am basically interested on what are the best way of checking why a program runs when executed from the IDE and not from the executable created. As I said, I was expecting an error message if something was wrong. Any ideas? Any good programming advice regarding how to avoid this problem in the future?
Edit: I forgot to mention that I am coding with a Windows XP machine. It doesn't work in this machine when I try to execute the file. It executes normally on a W7 machine but not in other W7 machine.
The executable will need the QT libraries on the computer that you are running it on. On linux there is command (I think ldd) that will show you what libraries your executable needs. I am not sure about Windows but there should be something similar. At least on a linux computer it will not necessarily give you an error if the QT libraries are missing. The executable just seems to do nothing.
Try copying the executable into the same directory as the .dll files in the Qt 'bin' directory.
If that works then you just need to put the Qt bin directory into your path, or copy the dlls into the windows\system directory
You need not only the correct dlls in your path (best in the application directory), but also the plugins in the correct location. See my answer to the question: Qt dll deployment on windows.
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx