Some time ago I've read an article on CLR, where author showed that if a project is compiled in DEBUG mode, before each operator comes a NOP command, thus allowing to debug a code. Nevertheless, today I discovered that we can also debug in release mode as well... Please help to understand the difference.
Asked
Active
Viewed 4,392 times
8
-
1How ? I don't really know how can you debug in Release Mode – crassr3cords Jun 15 '12 at 16:02
-
I encountered that I can not move to other asseblies while I was debugging in the release mode – Eugene Petrov Jul 12 '12 at 04:18
3 Answers
8
Debugging .net code so that you can step through the source code while it is executed usually requires three things:
- Symbols (the related .pdb file) that were built along with the assembly .dll or .exe
- Source (the related .cs, .vb, etc. files)
- The executing machine code must be unoptimized
Symbols are controlled by the /debug:{full | pdbonly} flag. If you specify /debug:full (even in a release build, with compiler optimizations turned off) you may attach to an already running process and step through code. If you have /debug:pdbonly, then you must use the debugger to start the program (and cannot view symbols when attaching to an already running process).
Optimization is controlled granularly by the /debug compiler option, but can be further controlled by the /optimize-.
agent-j
- 27,335
- 5
- 52
- 79
3
You can debug in Release mode to an extent. Debug and Release are simply build configurations (of which you can create many), the real difference is that Debug configuration doesn't optimize the generated binary code (optimized code complicates debugging). It also generates additional debug data which release does not.
erodewald
- 1,815
- 20
- 45
-
So You are saying that Debug configuration complicates debugging?? – Vladislavs Burakovs Jun 15 '12 at 16:06
-
No, sorry, I said optimizing the code complicates debugging. I will reword that so it isn't confusing. – erodewald Jun 15 '12 at 16:09
2
Compiling in release mode optimizes the resulting binary, which makes it harder (but not impossible) for the debugger to know which binary code came from which line line of source code.
Debug mode is designed to make it easier for the debugger to 'follow along', so it separates lines of code with NOP, and does not optimize the resulting binary.
Kendall Frey
- 43,130
- 20
- 110
- 148
-
I mean, it is weird that such a big control is granted over these processes. Because today I saw that my colleague seamlessly debugged code in Release mode and when I asked him about this, he didn't know. – Vladislavs Burakovs Jun 15 '12 at 16:15
-
Without the debug symbols (.pdb file), the debugger won't know what the original source code was, but it will still be able to step through the binary code. AFAIK, a debugger can attach to any process it wants, and step through it. The OS gives a lot of authority to debuggers. – Kendall Frey Jun 15 '12 at 16:18
-
Hm, so it will be harder for debugger, but still possible?(I mean, without pdb file)? – Vladislavs Burakovs Jun 15 '12 at 16:19
-
Yes. There is still machine code that is executing, so a debugger can examine that. – Kendall Frey Jun 15 '12 at 16:23
-
@KendallFrey The debugger can show you the machine code, but it can't associate it with the original source code, so debugging code like this will be most likely very hard. – svick Jun 15 '12 at 18:11
-
@svick: Yes. Very hard. (I know, I have debugged machine code before.) – Kendall Frey Jun 15 '12 at 18:24
-
@svick !U and !dumpil make from the sos and psscor[24] windbg debugger extensions make it easier even in release mode. – Marc Sherman Jun 18 '12 at 16:17