Posts Tagged ‘Debugging’

Breakpoints in Windbg

January 15, 2011 Leave a comment

WinDbg¬†rocks. ūüôā Setting breakpoints¬†is very easy in WinDbg. The command to set a breakpoint¬†is ‘bp’. So if you want to break whenever a¬†dll¬†is loaded into a process then type in following command…

bp kernel32!LoadLibraryW

So to trigger this breakpoint¬†attach ‘notepad.exe’ to the debugger and then type in this command. Now let the app run (press F5). Goto File->Open (this will trigger a definite LoadLibrary¬†:)). Now have a look¬†in WinDbg which¬†will have following output…

Breakpoint 0 hit
00000000`76e50420 4533c0          xor     r8d,r8d

¬†To view call stack, type in ‘kpn’. I’ll blog more on breakpoints as and when I get time. Happy debugging. ūüôā

Run to cursor feature in Visual Studio

January 6, 2011 Leave a comment

This is one cool feature of Visual Studio which I very much like, the shortcut for this feature makes life even more easy. ūüôā So what does this feature do?

Imagine we’re are¬†stuck in a heavy duty¬†for¬†loop and you want to immediately break after the for¬†loop but don’t want to traverse through the entire for¬†loop iteration, move your cursor to the line below the for loop (of course it must be¬†a c++ statement) and press Ctrl¬†+ F10. The result of this action is that the debugger will ‘execute’ (no it won’t skip) the entire for loop and break at the line that you chose.

I used to use this feature frequently so I guess this will help save sometime for you too.

Categories: C++, VC++ Tags:

Debugging WM_PAINT messages

November 15, 2008 1 comment

It’s always irritating to debug paint messages and sometimes expensive too. I’ve tried different methods to try debug painting issues, always ended up disappointed.

Why is it such a pain to debug WM_PAINT messages?

Main reason is, we are not in control. Paint messages comes via a window framework. Painting is done whenever a window gains focus or is activated this means our application will never get focus if we set a breakpoint in an OnPaint function because as soon as our application comes to focus it again sends a repaint request which again breaks into the OnPaint function.

It’s can be expensive too because we’ll need some kind of a dual monitor setup. So that our application runs on one monitor and the debugger on the other. For professional game/UI developers it’s ok because that’s their job and they will always need such a setup.¬†But guys like me cannot affort such a setup.

Any workaround?

Yes, that’s the good news. Windows explorer has a cute feature called “Tile Horizontally” and “Tile Vertically”. It also has another feature to select taskbar items using control key.

So this is how a standar taskbar looks, as you already know that at a time, in windows, only one window can be active.


The tab having a dark shade is the one that’s active, and if you right click on this tab you’ll get a context menu which will correspond to the active application’s system menu.

Now here is the interesting part use ‘Ctrl’ key to select multiple tabs. Press ‘Ctrl’ and then use your mouse to click on tabs you wanna select and then right click on any of these selected tabs and see what you get! Here is a screenshot of what I get…


These menu items are interesting, most windows users are unaware of this option, it’s a quick way to arrange your windows. You can try them one by one. Note that there is an option to close a group too. ūüôā

So returning back to our original discussion, we now apply this trick to our application. We are going to select visual studio and an application that’s being¬†debugged.¬†I’ve set a break point in the OnPaint function.

So we select both applications in the taskbar using ‘Ctrl’ key and mouse and then right click and select ‘Tile vertically’ or ‘Tile Horizontally’. I would select ‘Tile vertically’ as it would give me enough vertical space but you can decide what’s best for you. Eventually what I get is a screen like this with two windows that doesn’t overlap each other. One of them is visual studio and the other one is my application that’s being debugged, also note that I’ve set a breakpoint in OnPaint function. Both applications behave independently without interfering with each other.


Now my desktop acts like a dual monitor setup. ūüėČ It’s kinda cool for debugging purpose and yeah I agree this is not the ultimate solution but it’s quite useful. Hope this helps you. ūüôā

DEBUG_NEW explained

August 13, 2008 2 comments

mm so what the heck is this DEBUG_NEW? Does this harm my application? Why is DEBUG_NEW provided? These are some of the questions that people have always asked when they see the following statements in a .cpp file of an MFC application…

#ifdef _DEBUG
  #define new DEBUG_NEW
  #undef THIS_FILE
  static char THIS_FILE[] = __FILE__;

So after all what is this DEBUG_NEW?

Well in short it’s an overloaded version of the new operator. So when you write new in your code the preprocessor expands it to DEBUG_NEW.

It’s proper definition looks likewise…

void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
    return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);

The call get’s redirected to another overloaded new operator which in turn does some additional housekeeping for tracking memory leaks. This is the reason why this new operator takes the file name and line number so that when a leak occurs the user can be taken to that particular location where the leak occurred. But out of ignorance people just delete above code which although doesn’t disable tracking of leaks but disables the feature whereby the user can double the click in the output window to be taken to that exact location where the leak occurred.

So suppose I write a piece of code which is purposely left undeleted, then this is what I get! So if I click on the red line I am taken to the exact location where the leak occurred.

Detected memory leaks!
Dumping objects ->
E:\SingleDocTest\SingleDocTestView.cpp(43) : {84} normal block at 0x00035628, 100 bytes long.
 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD 
Object dump complete.

This is a big help to me atleast. I’ve seen colleagues out of ignorance deleting DEBUG_NEW. So how did this help me? Here is an example…

void SomeFrequentlyCalledFunction()
    m_pSomeObjPtr = new CSomeObj;

So ideally I should be deleting m_pSomeObjPtr before reallocating it again, and this is where DEBUG_NEW comes handy. Well if you have other advanced applications for tracking memory leaks then it’s fine, but this is a big help to know immediately where the leak is happening.

Is there some performance penalty involved?

Yes only in debug builds which is expected too, since we never ship debug builds!

Does this track resource leaks?

Of course not!

Is there anything wrong if we delete it?

Yes it’s wrong but its not an error, leave it, it’s harmless!

Function return values live in VC watch window!

May 23, 2008 2 comments

Ever felt the need to watch over return¬†values from functions! Well I did always but unfortunately couldn’t come up with something! I was reading through one of John Robbins’ Bugslayer articles in MSDN and found an interesting tip related to seeing function parameters passed in by adding a watch statement over the ESP stack pointer variable.

So that got me thinking like “why not EAX”, huh that was easy! So this tip happens due to the tip given by¬†one of the¬†readers of John’s article in Bugslayer. I will put a link to that tip once I find it along with the author’s name.

Now let me tell you how the watch statement for our tip should look like…

  1. To watch string values returned by functions…
  2. To watch integer values returned by functions…
  3. To watch objects returned by functions…

Now you may ask why do I need this, I can always use the auto variable¬†debug window. Well don’t forget that we are adding watch to¬†a register (EAX), so this means even raw function call’s return value is shown here.

Let me show you a live case where you may need this. See here I’ve got four function calls which does some strange operations but return values doensn’t matter hence they are not stored. It’s¬†just¬†useless¬†to store return values in temporary var just for the purpose of debugging, so above watches come handy.

DoOperationReturnBool(); // Returns bool, but returned values not stored
DoOperationReturnEnum(); // Cast EAX to appropriate enum type or int
DoOperationReturnCharPtr(); // Cast EAX to char pointer  or wide char ptr
DoOperationReturnObject(); // Cast EAX to appropriate object type, I haven’t tested this but should work

I am using this these days, yet to see a drawback, tell me if you find any! Have fun debugging ūüôā

Categories: Debugging, Visual studio Tags: , ,

Quick VC debugging tip!

So you have a dialog while you are debugging an application and you don’t know from where this dialog is popping up, huh, how many time has this happened!

So what normally people do is goto debug menu, press break and then goto threads and then double click on each thread to view call stack and then they find out. This is fine if you have a modal dialog, but what if it’s modeless?

So here is the solution, to break into an application while it’s running press “F12”. Yeah “F12”, can’t believe your eyes, do and believe!

So in order to debug into modeless dialogs you need to be real fast in pressing F12 ūüėČ . As soon as you start such a dialog press F12. This does the trick for me and must do for you too!

This same trick applies to any code that you are executing, at any time to break while debugging press “F12”. This doesn’t require visual studio to be running in the foreground. The foreground application should be the application that’s being debugged. After breaking into the process, continue as you would normally to find out where exactly and in which thread the execution is taking place.

Enum bit flags visualization in VS2008 debugger!

%d bloggers like this: