What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.
Related
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I've had several times where I was writing a program using Visual Studio and something, somewhere along the line breaks. Naturally, my first thought is to set a breakpoint early on in the program and then step through the code slowly, line by line until I reach the error.
But often times I find that everything works correctly when slowly stepping through code in the debugger. However, when I just try to run the program without breakpoints something goes wrong.
Why does this happen? Is stepping through the code line by line actually different from just running the program in dubug mode?
(I'm not talking about debug vs release, i'm talking about debug vs line-by-line debugging)
One reason could be that you have timing issues between multiple executing threads that occur differently when the program runs "at full speed" and when you pause a thread in a debugger.
It could be due to a some thread unsafe operations that seem to happen correctly when stepping through the code but not at run time. Compiler optimizations are ruled out because you are sure that you are running a debug build.
Running inside the debugger materially alters the runtime options for eg. heap operations so that errors can be detected and surfaced to the user.
See here.
When a process is run under any debugger, certain heap debug options
are automatically enabled for all heaps in the process.
This is not for sure your issue, but a likely candidate.
I'm testing performance. The program receive huge bytes from other other side through TCP connection and parse into target structure.
If I try it in Debug (F5), delayed very seriously. But if I try it in Release (Ctrl+F5), it works very smoothly.
I check the situation using WireShark, TCP window update statement let me know the status of receive side.
I wonder if I want to make end-user program. The program should be work in debug mode as well as release mode?
The data size really big and the transmit interval is very short. In this case, the difference of performance between debug and release will be very cleary? I couldn't see that kind of difference ever.
This question conflates two different issues. One is Debug versus Release builds. Debug builds are slower for numerous reasons, all aimed at making debugging easier.
The second issue is that launching an application under the debugger (F5) versus not under the debugger (Ctrl+F5) can affect performance. The Windows heap does additional checks when launched under the debugger, processing of OutputDebugString and module loads may take longer, etc.
These two issues are completely orthogonal. You can launch a Release build under the debugger, or you can launch a Debug build not under the debugger.
If the problem is that Debug builds are slower then, well, yes, they are. You can control this somewhat by enabling optimizations in some source files or by turning off debug iterators, but Debug builds are supposed to be somewhat slower.
If the problem is that builds launched under the debugger are slower then don't do that when you care about performance. You can always attach the debugger after, which will avoid some of the slowdown, or don't attach the debugger at all.
When you publish, your application, it should be compiled in "Release" mode only. Debug mode is used to really "debug" while your development.
You should only program with Release mode in mind. It's really the only version of your app that should reach the end-user. Debug mode is only for "housekeeping" and well... debugging. Not really the user's concern.
I have cuda events in my code to record the time of execution. When I click "Start Debuggin" from VS 2008, the timer gives a value of 1.5 seconds. However, when I run the program from .exe file, it gives time of .4 seconds. Why this difference?
There's no inherent reason that running attached to the debugger should introduce a performance difference, other than (just a few possibilities):
Do you have any conditional breakpoints set? Depending on the condition, these can have a dramatic impact on execution time.
Are you explicitly writing large amounts of data to the Debug or Trace listeners? (Edit: that's relevant for C#, probably not for C++.)
Is the EXE compiled in Release mode? By default, the Release config turns on optimizations that aren't present when building in Debug mode.
Is your timing code really only timing the relevant section? If you're starting the timer at the start of program execution instead of around the GPU calls that you're really interested in, you may be accidentally timing some startup tasks that are tied to running with the debugger that won't be active in a standalone app.
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.