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
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.
I compiled a program using freeglut, optix, cuda and other libraries (some of them dinamically loaded). It compiles and runs without problems in Visual Studio but it crashes if I execute it outside Visual Studio. Both release and debug versions work within VS, they both crash without any information on Windows 8 if I try to execute them directly.
I already included all the necessary DLLs, that didn't work.
What could be the problem?
Most such observations are usually coming from undefined behavior -- using uninitialized variable, dangling pointers/refs, overrunning buffer.
You may try to use Application Verifier, with some luck it might rearrange the used memory enough for you to trigger the problem under debug to help corner it.
Also, when it crashes you should get a prompt to launch VS and inspect the problem -- did it not indicate a hint? What was the immediate cause of the crash and what you had on the call stack there?
You can try comparing the environments between visual studio and the default environment.
Dependency walker should identify any missing DLLs.
Get WinDBG, then File > Open Executable and run the program under WinDBG. When it crashes, you will get some more information. My answer here describes an issue in .net, but the concept applies to native C++ as well.
Visual studio runs executables under "debug" mode, meaning a debugger is present.
What does this mean? If you check out the msvcrt implementation, if the runtime detects a debugger is present (IsDebuggerPresent), then heaps preform differently.
What does this mean? It means buffer sizes are "nudged" upwards, it means memory allocations are wiped clean by default (no need to memset), etc.
This can cause a variety of bugs to manifest, or some more subtle bugs to be hidden.
When I run my exe outside of visual studio, with a release build, the graphics are very distorted. It works completely fine when I run it in debug mode, but I can't seem to figure out why it happens in release mode. It works fine if I start the application through visual studio though, which is the strange part. If you guys have any suggestion, I would really appreciate it. Thanks!
Expected Result (Debug Build):
http://i.stack.imgur.com/XH0cJ.png
Actual Result (Release Build):
http://i.stack.imgur.com/5lms0.png
(I don't have enough reputation to post picture)
There are two variables that are possibly not what you believe them to be. First, and less likely, is that there is code preprocessed differently than you believe. I don't believe that to be the case because if that were the whole problem, you'd see the same behavior in and out of VS. It may still be a factor, though. More likely, the culprit is in your configuration management; frequently, when you add projects or configurations, the configuration uses unexpected configurations from different projects. Check to see that your release configuration is using all release configuration versions of each project.
Other variables might be command line parameters and path differences, but I'm sure you've already checked that :)
Good luck.
Are you copying your geometry into the Vertex Buffer once at start-up or once every frame?
Check that your pointer to the geometry isn't pointing to something temporary; sometimes this will work ok in Debug mode (or Release mode when the debugger is attached) but will be optimized out when running as a standalone exe in release mode.
I have a problem with my C++ application. It was developed on a 32bit pc, on Microsoft Visual Studio 2008, and now I am trying to run it on a 64bit pc.
On my 32bit pc it works fine; on the 64bit pc, Visual Studio does not give any compilation problem, but then on execution gives wrong results.
And I have undestood why.
In the code, I define a variable, of tipe "dag", that is a structure for a direct acyclic graph. By debugging the software, I noticed that, although I declared it, later the software is not able to insert data in it, and the debugger says:
CXX0017: Error: symbol "dags" not found
Here's my code:
Dag<int64_t>* dags = new Dag<int64_t>();
dags = getDagsFromRequest2(request, dags);
The very strange thing is that, if I follow the flow inside getDagsFromRequest2() function, I can clearly see that dags variable is full of data: on "quickwatch", it shows 2342 nodes inside it. But when I come back from getDagsFromRequest2() function to this part of the code, debugger says "CXX0017: Error: symbol "dags" not found". How is it possible?
You can also see this screenshot from my Visual Studio debug set.
What could be the problem?
Thanks a lot
There are a few possibilities to consider:
Running in Release builds. Switch to a Debug build.
Using a Debug build that has optimizations enabled and/or debug information disabled. Disable the optimizations and enable the debug information (look in another project for the relevant settings).
A corrupt build of some sort. Clean and rebuild the entire solution.
Memory corruption which is preventing the debugger from displaying the variable. Ensure that no memory issues exist with a tool like Valgrind.
A VS bug. This report for VS2010 seems to suggest a known bug with similar characteristics for example. Ensure all patches and hotfixes for VS2008 are installed.
The variable dags is defined as your code compiles. The error you see is simply related to the debugger. I am guessing it is caused by running the application in Release mode which sometimes causes confusing and wrong watches values. Try changing the mode to debug(there is a drop down from which you can choose the build mode).
EDIT: as you say you are running in Debug mode, my next guess is that this behavior could be caused by stack corruption. Try using valgrind to detect if that is the case. It may take a while to start with it,but it is worth it and will detect if you have some memory corruption.
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