CRT Debug support – The Magic Memory values.

29 04 2008

Memory corruptions are every programmer’s nightmare. But Debug Heap provides some facility in debug build to help you to get rid of those memory corrupting problems. Depending to the type of memory allocation we have done, the debug heap will fill some magic value for the allocated memory contents. Take care that, this will be available only in debug build. Please see below.

  1. 0xCD – The memory locations filled with this magic number are allocated in heap and is not initialized.
  2. 0xFD – This magic number is known as “NoMansLand”. The debug heap will fill the boundary of the allocated memory block will this value. If you are rewriting this value, then it means, you are beyond an allocated memory block.
  3. 0xCC – The memory locations filled with this magic number means, it’s allocated in stack but not initialized. You can see this when you a variable on stack and look at its memory location. You can use /GZ compiler option to get the same feature in release build.
  4. 0xDD – The memory locations filled with this magic number are Released heap memory.

Regarding the 4th one – 0xDD, when I tried, the deleted memory locations are filled with 0xFEEE. I’ve to check it further. as per documentation its 0xDD.

Targeted Audience – Intermediate.


How to take command Prompt with default path as Selected Folder Path.

22 04 2008

Usually in huge frameworks, we’ve to run a lot of console applications for starting up the system. Sometimes we’ve to start it by specifying long commandline arguments. In those cases, instead of double click and running the application, usually we take command prompt and start applications by entering commandline.

When, Console opens, it points to the default path and we’ve change the directory to required folder by CD command. Is there any easy way to start command prompt with default path as selected folder in Windows explorer? Yep! there is.

Just do the following steps.

1) Take Windows explorer.
2) Take Tools > Folder options.
3) Take File Types tab.
4) Select “Folder” Filetype.
5) Click advanced.
6) Click “New
7) Now give Action: “Cmd” and application used to perform action as “cmd.exe
8 ) Now, click ok in all dialogs.
9) Now press WinKey+E to see the windows explorer.
10) Now right click on any of the folders in tree and you can see the menu item cmd.
11) Now click on that, a new console will be opened with default path as selected folder’s path.

Targeted Audience – Beginners.

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.

Trailing spaces after backslash delimiter – Programmers nightmare.

31 03 2008

Icon Description
Usually we used to have spaces after semi columns. Since C++ ignore whitespace, its not a problem. But in Visual C++ 6.0 that is not the case always. If you put spaces after the backslash delimiter(\), it will become one of the worst bugs that you encounter.

Usually we use backslash delimiter to concatenate lines – mostly while writing macros. See the following macro.

    Value = Value + 1; \ » » »
    Value = Value - 1;

In the macro, instead of » char, put some tab or space and then compile. You will get a strange error as follows.

error C2501: 'Value' : missing storage-class or type specifiers

Icon How Can I Do It?
One of the defensive mechanism is – always enable “View whitespace” by pressing Ctrl+Shift+8. So take care next time and don’t spend hrs on these silly bugs as I did years before.

Note that its just a implementation behavior in Visual C++ 6.0 and may not found in other compilers or upcoming Visual C++ versions.

Thanks to Hemant for pointing out my implicit biasing towards VisualStudio 6.0. I forgot to specify that its just a Visual studio behavior.

Targeted Audience – Intermediate.

List the loaded modules in your crash report.

29 03 2008

In crash reports, usually we see a list of loaded modules. While writing Error Handler frameworks, for dumping crash reports we too need to get list of loaded modules which will make the debugging tasks easier. But how can we find out the loaded modules? You can use EnumerateLoadedModules() function to enumerate the loaded modules.

You can use EnumerateLoadedModules() function to enumerate the loaded modules. For calling EnumerateLoadedModules() we need provided a callback function pointer. The EnumerateLoadedModules() will send the loaded module information as callback to that provided function. Please see the following code

#include <Dbghelp.h>  

// Callback function.
BOOL CALLBACK EnumerateLoadedModulesProc( PSTR ModuleName,
                                          ULONG ModuleBase,
                                          ULONG ModuleSize,
                                          PVOID UserContext )
    // Print the module name.
    cout << ModuleName << endl;
    return TRUE;

int main(int argc, char* argv[])
    // Enumerate loaded modules.
       GetCurrentProcess(),	// Process Handle
       // Callback function pointer
       (PENUMLOADED_MODULES_CALLBACK) EnumerateLoadedModulesProc,
       0 );	// User context.   

       return 0;

Add beauty and complexity to your crash report by listing out the module names 😉

GetCurrentThread() returns pseudo handle, not the real handle.

26 03 2008

Icon Description
For getting our thread handle, we usually call GetCurrentThread() api. But actually it returns a pseudo handle. A pseudo handle, is a special handle which represents the handle of current thread which uses it. Please see the following e.g. for more clarify.

1) Thread A gets its threadID by calling GetCurrentThread and Passed to Thread B.
2) Thread B needs to terminate Thread A. So it calls TerminateThread( handle passed by Thread A ).
3) But instead of terminating Thread A, Thread B will be terminated, because the handle passed by Thread A was pseudo and it will become Thread B’s handle when Thread B uses it.

Debug one GetCurrentThread() call and GetCurrentProcess() call and watch its return values. You can see what they returns are follows,

  • GetCurrentThread() – 0xfffffffe
  • GetCurrentProcess() – 0xffffffff

Ofcourse pseudo… isn’t it ?

Icon How Can I Do It?
For getting a real handle which represents your thread, create a duplicate handle by calling DuplicateHandle(). Please see the code block below.

HANDLE hRealHandle = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
                 GetCurrentThread(),  // Source Handle to dup.
                 GetCurrentProcess(), // Target Process Handle.
                 &hRealHandle,        // Target Handle pointer.
                 0,                   // Options flag.
                 TRUE,                // Inheritable flag
                 DUPLICATE_SAME_ACCESS );// Options
// Now the hRealHandle contains a real handle for your thread.