Visual Studio tips

You probably already know classical features such as step-by-step execution (Step Into or Step Over to enter or not in functions) with breakpoints (conditions, count, disabling etc), Watch window, etc.

But there are also a lot of other very useful features for debugging.

• Goto definition with a right-click on a type or function name
• Call Browser | Show callers graph on a function name, to see all places of the project from where the function is called
• Find all references on a symbol name, to get all places where it is used

You can debug a DLL (with step-by-step execution, breakpoints and all the usual stuff) when it is launched by any program.

In Project Properties | Configuration Properties [ Debugging | Command you just have to put the path of the executable which will use your DLL.

Then, just put a breakpoint in your DLL source code, Start Debugging (F5) : it will launch the external program, and when your DLL will be used it will stop on the breakpoint.

Remark : the DLL that the executable use must be the same that the one generated by Visual Studio (you can't move or copy it). But it is simple to configure Visual Studio in order to generate the DLL in the path you want.

If your program is used by another program and you want debug it in this context, you can.

With Visual Studio you can attach the debugger to a running process. Set Project Properties | Configuration Properties | Debugging | Attach to yes, and be sure that the Command field still refers to your executable.

Then, just put a breakpoint in your DLL source code, launch your program in any way you want, and after attach the debugger with Start Debugging (F5) : when your program will be used it will stop on the breakpoint.

In non-managed C++, Visual Studio uses special libraries in Debug mode, which add a lot of verifications when allocating or freeing memory, in order to detect some problems in your code. But unhappily it won't detect all errors, in particular access to non allocated memory areas.

There exist some tools which can do that, such as Purify for example, but I don't know any free tool for Windows (for Linux there is the excellent Valgrind).

The problem with these errors is that they are not deterministic, can occur anywhere anytime with no connection with the location of your error in the code.

An artisanal way to try to deal with that can be to allocate huge buffers of memory that you don't touch, but you compute checksums of theses buffers all along your code. If your code is wrong and write data outside allocated areas, it can modify these buffers and you will see it. Of course you're not sure at all it will detect your errors, but there is a chance.

There is a tool which automates this procedure with other stuff, called Memwatch, but this is still not foolproof.

When using threads (System::Threading) or something else you get errors like Ambiguous symbol for the IServiceProvider class in the servprov.h file that of course you never touched.

Just try to move the #include <windows.h> line BEFORE the System::Threading line for example (and not after or not at all).