How to enable/disable all breakpoints in single keystroke?

9 06 2008


During heavy debugging, we usually have dozens of breakpoints dropped in various locations of source. Some of these breakpoints can also be in the application startup route. While stopping and starting programs during debugging, these breakpoints are really irritating, because they stop always. I’ve to press F5 a couple to times to start the application and run it. If there’s some shortcuts to enable and disable all break points at one single keystroke, it will be nice. isn’t it? But how?


You can use the VisualStudio’s powerful object model to do so. See the macro code for enabling and disabling the breakpoints. In later steps, i’ll explain how to map it to keystroke. The macro code is as follows,

' Macro to Enable all Breakpoints.
Sub EnableBreakPoints()
    Dim myBreakpoint
    For Each myBreakpoint in Debugger.Breakpoints
        ' Enable the break points.
        myBreakpoint.Enabled=True
    Next
End Sub

' Macro to Disable all Breakpoints.
Sub DisableBreakPoints()
    Dim myBreakpoint
    For Each myBreakpoint in Debugger.Breakpoints
        ' Disable the break points.
        myBreakpoint.Enabled=False
    Next
End Sub

How to map the macros to Keystroke
1) Take Tools > Macro.
2) Now you’ll see your macro window and i assume no macros are defined in your macro file. For getting the macro editor, enter some dummy macro name and click “edit” button.

3) Now Macro editor will be opened and copy-paste the Enable/Disable macro code in your macro editor and save it.
4) Now take Tools > Macro again and VisualStudio will ask, whether to reload the macros. Press Yes.
5) Now you’ll see the macro dialog, and click “Options” and “Keystrokes“.

6) Now select the macro and press a key combination, then click “Assign”.

7) The greatest difficult that you’ll face is to find a free slot of key combination. Almost all are reserved by visual studio itself. 🙂 After some R&D I’ve found two working key combinationAlt+z and Alt+x. Map your enable/disable macros to those shortcuts.

8 ) Now take visual studio and press the key combination to disable the breakpoints. Note that the breakpoints will not be visually disabled but if you take breakpoint window by Ctrl+B you can see all are disabled. This happens because we’ve modified the internal structure of VisualStudio, but GUI is not refreshed.


The only drawback is the breakpoints will not be visually disabled on keystroke. I’m searching for some solution and hope i’ll be back soon. Till then enjoy this one. 😉


Targeted Audience – Intermediate.

Advertisements




How to locate the source code which pops the error message – More easily.

17 04 2008


While debugging huge code bases, unexpectedly some error messages can be popped up. Most probably we might be seeing it for the first time and don’t have any idea, from which location of the code base, the error message get fired. How to locate it easily?


Just follow the steps –

1) Start the project by F5.
2) Do the steps to make the error messagebox to be shown. Now the error message will be shown.
3) Now instead of clicking of in the error message, take debugger and click menu, Debug -> Break.
4) Now take Debug -> Threads to see the threads running in your application.
5) You can see one of your thread, which is paused in a messagebox showing routine.
6) Select that thread and click SetFocus, to focus that thread.
7) Now take the Call Stack by Alt+7 and iterate through it from top to bottom.
8 ) You see one familiar function? Yes! its the one which pops the error message. Now go and fix the bug 😉


You can also put a breakpoint by finding the memory address of the functions that can be used for showing error messages. But, if the application uses some custom dialogs, then you’ve to put more effort. This method is the handy one with least headaches. Try it!


Targeted Audience – Beginners.





Locate implementation of a particular Dialog in huge Codebase Easily.

7 04 2008


Huge Maintenance projects usually contain a number of dialogs. Sometimes we want to modify a particular dialog in that project. During most of the case, we might be encountering that dialog for the first time( Guys digging old code base like me can understand it very well ). At that time, what usually people do to locate the dialog implementation is as follows.

  1. Iterate through all dialogs in the resource by opening it or by checking the dialog ids.
  2. Find the matching dialog.
  3. Take the dialog ID.
  4. Search the code base for reference to the Dialog ID.
  5. You found it!

If your code base have 100eds of dialogs, how much time will it take?


All dialogs have the same base class, CDialog. So the CDialog constructor will be called before the constructor of your dialog class get called. Now follow the steps.

  1. Start debugging your project by F5.
  2. Open the file – <VisualStudioDir>\VC98\MFC\SRC\DLGCORE.CPP
  3. Put breakpoints on all CDialog constructors. Note – there are many overloads for your CDialog constructor. Since its unknown how your dialog class is initialized, its better to put break points on all CDialog constructors.
  4. Now launch your dialog from your application and the debugger will break on the CDialog constructor.
  5. Now take the Call Stack by pressing Alt + 7.
  6. From the call stack you can identify the class you were searching.


The above steps only works for debug version. If you are in release version, then breakpoint at DLGCORE.CPP will be disabled at the starting itself. For that, see following steps.

1) Our problem is how to put breakpoint at CDialog in release build.
2) For that take any put any other dialog class in your workspace and put a breakpoint in its constructor and start debug by F5.
3) when the breakpoint at your dialog’s constructor is reached, right click and select “Go To Disassembly”. It will be as follows.

62:   CDlg1Dlg::CDlg1Dlg(CWnd* pParent /*=NULL*/)
63:       : CDialog(CDlg1Dlg::IDD, pParent)
64:   {
00401216   push        ebp
00401217   mov         ebp,esp
00401219   push        0FFh
0040121B   push        offset $L87331 (00401d29)
00401220   mov         eax,fs:[00000000]
00401226   push        eax
00401227   mov         dword ptr fs:[0],esp
0040122E   push        ecx
0040122F   mov         dword ptr [ebp-10h],ecx
00401232   mov         eax,dword ptr [pParent]
00401235   push        eax
00401236   push        66h
00401238   mov         ecx,dword ptr [this]
0040123B   call        CDialog::CDialog (00401a0a)
00401240   mov         dword ptr [ebp-4],0

4) From the disassembly you will get the address of CDialog constructor to be called.
5) now take the breakpoint window by pressing Ctrl+B.

6) Just add a breakpoint by specifying this memory location in “Break At” editbox. don’t forget to add 0x in front of memory location. here it will be 0x00401a0a.
7) Now you’ve successfully added a break point at CDialog constructor in release version too. Enable it only when you need it.


Targeted Audience – Beginners.





Hardcoding Breakpoint.

23 03 2008

Icon Description
In some cases, MSDEV wont allow to set break point event if we press F9 a number of times. In those situations you can hardcode a break point by yourself.

Icon How Can I Do It?
Just insert the following line to the point where you would like to break while executing.

__asm int 3;

icon_underthehood.jpg
VisualStudio uses Interrupt 3 for implement break points. When we put a breakpoint, actually the debugger is inserting an int 3 instruction at that point. While executing, when an interrupt 3 is raised – debugger understood that one breakpoint is reached and it breaks and shows the appropriate code.