Very basic question.
I want to debug release version of my exe. My debug version is working fine. But release version crashing as usual.
Any tool or debugger available for this would be a great help.
You can still enable debug information in release mode, and use a debugger as usual. Nothing particular here, except that the order of instructions will sometimes look weird when debugging due to optimizations.
Good luck, debugging release-mode-only bugs is tedious.
I'd recommend you adding some kind of logging system or trace points to locate the source of crash. The debugger can trick you when debugging release. You can also elevate the warning level of your compiler to see some usual suspects such as use of unitialized variables.
I recommend you to run exe under some memory debugger, such as Rational Purify or BoundsChecker. It will spot memory related bugs in your code, if any.
Related
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
There are a number of errors going on here but I'm sure they are all linked, so first off I'm getting Access violation reading location exceptions at locations (generally near 0x00000000)
but I only get these exceptions in release and not in debug, even if i setup debugging to do so. Also I found where the error happens but when I step over that it goes in to a complete unrelated function that is not called in the line or in any of the functions in that line of code. But when similar code is called it still goes to this unrelated function but doesn't fail. This all only happens in release versions. I know which piece of code is causing the error as if I comment it out its all fine. Also in the watch window in release all the numbers are wrong most of the time, which has never been a problem but it could help also a added some code to it to output the values of variables to a file and the variables are all fine, the pointers are sensible, but when the exception happens it always says their 0x00000020 but when I look at the log they are fine. This is in 32 bit , but on 64 bit windows 7 in c++. Please any help would be good!
Visual Studio's debugger will cause the program to use a debug heap that can hide uninitialized memory if you use the option "Start with Debugging" to start your program, in release or debug. You can try to run your program built in the Debug configuration without the debugger attached, and then use the Attach to Process... option in the debug menu to attach to your executable.
If this doesn't help, I recommend using windbg to debug your program. For help getting started with windbg, take a look at the answers on this question.
Once windbg is configured and symbol paths are set up, you can use the "!analyze -v" option once the program crashes to get a lot of information about the crash automatically.
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.
Is there any benefit in starting a debug build without debugging (as opposed to a release build without debugging)? And what do I miss when I debug a release build (as opposed to debugging a debug build)?
Biggest advantages of debug builds (outside of the IDE):
Assertions are enabled, as is other diagnostic code you may have compiled within debug-dependent prepocessor sections.
Stack traces and variable watches are working properly, so you can have beta testers send you a crash dump and debug that in your IDE later.
Biggest disadvantages:
Slow execution, higher memory consumption, bigger file size.
Some bugs are not evident unless you compile everything with full optimization. That's because memory allocation is working differently in release builds.
Many companies distribute debug builds to alpha and beta testers and switch to release builds later.
To add to Adrians answer and as a general point when talking about debug vs. release builds:
Here are some factors that influence your builds:
You link against either the debug or the release runtime libs (/MD vs. /MDd)
NDEBUG (release mode) or _DEBUG (debug mode) is #defined
_SECURE_SCL (or some equivalent) is defined (or not)
Compiler optimizations are enabled (to some degree)
A "debug build" normally comprises _DEBUG, _SECURE_SCL=1, /MDd and all compiler optimizations disabled. This results in the "safest", "most-checked" execution mode, but also should be the slowest version you can get for your executable. The speed and safeness factors should be completely independent of whether you run your program under a debuger or not! -- The debug build gives you a maximum safety and error catching net, completely independent of whether the program is attached to a debugger.
Next comes a non-optimized release build: That is, you have all the release mode settings (NDEBUG, _SECURE_SCL=0, etc.), but you disable all compiler optimizations. This is good for testing, since performance won't be bogged down too much and you can debug this allright. Again, the usefulness of this is independent of whether you run your program under a debugger.
Finally come full optimizations. (/Ox + full inlining + possibly whole prg optimization): While this is what you would like to ship for performance reasons, chances are that you do not have enough people in your company that are actually able to debug this. That is, given a crash dump, someone most likely needs some amount of asm knowledge and what a compiler outputs to make some sense of the crash dump (or even some random breakpoint, when actually running under the debugger). Again, the pros/cons for full opt are independent of starting/running the prg under a debugger.
Starting a debug build without debugging can give you for example the following benefit: if a contrainer is indexed with an invalid index you'll get an assertion failed, in release mode you'll get undefined behavior. That's one thought. What you miss when debugging in release mode is that there is no correspondence between source lines and assembly code any more because the optimizer has run. So it's far more difficult to debug in release mode
I'll offer a recent experience that I can't explain -- sometimes when I run my application, I get unhandled exceptions when running in the IDE. The problem is, I know my exception is getting handled, and I also know that I'm not breaking on thrown exceptions (via CTRL-D, E). If I hit F5 several times, my error handler eventually catches the exception and deals with it properly.
The reason for this has eluded me for several weeks, so when I don't want the execution to get interrupted, I run outside of the IDE and simply attach to the process later if I need to.
If you really need to see the Debug output while running outside of the IDE and you're not using something like log4net to capture everything, you can use DebugView instead.
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