Debug C++ dll from C#

Question

I will briefly tell you the situation. I got a C# project which uses some DLL created in C++.

Now, separately, I also have a C++ project, which was used to create that DLL some time ago. Now, I wanted to debug the C++ DLL during running the C# project.

I enabled "Enable Unmanaged Code Debugging" in my C# project.

I started debugging C# project and stepping into some functions alongside. All seemed to be ok. When I reached a function which belonged to C++ DLL, it asked for the source of the C++ file, I had to browse to my C++ project. (Before I think it complained about some .pdb files).

Now, I managed to step into the C++ function also, but as I step over and over, some of the data structures in that function don't seem to be populated with the data, eg, please see screenshot below

You can see the blob data structure is empty, and same happened with DataParser (it was showing it had 0 items inside, whereas in code above you can see there are multiple items being added to it).

I would really appreciate some help, what is going wrong here? And where I could have done mistake. How can I debug this C++ DLL so that I also see what values are assigned to its variables currently?

Maybe my way of debugging this C++ DLL is wrong? The fact that the C# project is using an already created DLL, and I have this C++ project which was used to create this DLL some time ago - the fact that they are separate, maybe that has to do something with it also?

PS Before I had to make changes like this to C++ project and lower toolset because I use VS2012 (strange if project was created using VS2013 though because I think it is old project). Also the project uses lot of manually written other C++ classes. Maybe that is the problem also and somehow the compiler can't retrieve their values and definitions?

What are the steps in general to debug a C++ DLL file in a setup like I have?

EDIT : PPS. Also some other interesting facts I have seen. If I click F11(Step into) on the DataParser.Add function for example, not necessarily I am taken to the body of that function, it shows me body of other function (which might be somehow related to it).

Also if I press F10 say after first time Request.Add is called, it jumps over multiple Request.Add lines, and moves to the fifth one for example.

EDIT2 : Also before I step into C++ code it is showing me warning that "the source is different version than the one that was used to create a DLL". Is this a problem?

Answer 1

Module and PDB

There is a link between a module ( .dll / .exe ) and the debug database ( .pdb ). This link is established via a timestamp and a checksum that is present in both files. Visual Studio checks the correctness of those, otherwise it will complain and not stop at breakpoints at all.

While other debuggers such as WinDbg have commands to turn that feature off, Visual Studio doesn't have such a feature and requires active manipulation (such as Chkmatch ) to turn off the checmsum verification. As long as you didn't use such a tool, your debugging symbols are fine.

PDB and source

There is also a link between the debug database ( .pdb ) and the source. This link is established by file name and line numbers. As you can guess, your source code will not modified during compilation, so the source code does not contain any checksum or timestamp that could be verified.

Therefore, the source may have changed and the line numbers may not even match roughly any more. There are several reasons for line numbers to get broken. I have answered a similar question before and listed the following reasons for line number changes although the code itself did not change:

• code reformat, which eg sorts the methods by visibility, so complete methods are moved
• code reformat, which eg breaks long lines at 80 characters, usually this moves things down
• optimize usings (R#) which removes 30 lines of unneeded imports, so things move up
• insertion of comments or newlines

How to debug

1. Restore the exact source code of that version, if you can.
2. Debug completely without source, just by PDB information. This way you can keep the binary components, if that's important (eg if a bug can only be reproduced with that version)
3. Rebuild all modules to make the code match the modules again. That way you lose the binary and the problem may not reproduce any more.