Error while dll load

Question

Hi, My program tries to load some dlls. The problem doesn't come during the first load. But it comes every 7th time. I guess there is memory corruption. Is there a tool or something to debug the memory corruption for visual c++. I tried some memory leak tools but there is no memory leaks.

please help!!!

regards, Suresh

Answer 1

I wrote a blog that goes through some steps you can use to find memory corruption. The one that will really help is the gflags one (#2).

http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/02/06/6-_2200_Pointers_2200_-on-Debugging-Unmanaged-Code.aspx

Use Debugging Tools for Windows: If you don't have this, go get it now. For some serious debugging, you get windbg, which I will write a blog about soon. But, the utility I use most is GFLAGS. One of the most useful features it has is the ability to make every heap allocation on its own page (+hpa). This means that you can detect a memory out of bounds error at the point of the initial dereference, not later when you end up scribbling on something important.

This option makes your process use much more memory and is noticeably slower. I recommend running your entire unit test suite in the debugger after running this line from the command prompt (if you are using the NUnit gui test runner).

 gflags -i nunit-gui.exe +hpa

Replace nunit-gui.exe with the name of your test runner .exe. (remember to turn it off when you are done with -hpa). More on GFLAGS.

WinDBG is essential for tracking down unmanaged memory leaks. You could also check out AutomatedQA's tools for this which are orders of magnitude easier to use -- I still think it's worth learning WinDBG though.

Answer 2

The first thing to try is to compile and run the program from the Visual Studio IDE using its Debug configuration. This enables some heap checking and other options that might just show up the error right away.

Make sure you are compiling with all warnings (/W4) and that you neither ignore them, nor add casts to make them go away. The compiler is a good friend if you listen to it.

Since it does not happen every time, this could be timing-related, or an uninitialized variable that usually gets left floating at some functionally OK value.