Visual Studio 2010 C++ cannot see classes instances in debug window but can see native types ..Why?

Apr 13, 2014 at 1:46 PM
Edited Apr 13, 2014 at 1:47 PM
This was posted on Stack overflow but I've had no luck
(http://stackoverflow.com/questions/23036879/visual-studio-2010-c-cannot-see-classes-instances-in-debug-window-but-can-see).

There is a similar but not exactly same question here but proved not useful see.

https://daffodil.codeplex.com/discussions/391875


I have VS2005, VS2008, and VS2010 installed on my Win7 development machine.
My application has a C# front end which makes calls into my C++ dll.
I am building my dll which uses a collection of third party dll's some of which were
built using Visual Studio 2005. I am using Daffodil to do ensure my dll is also built (from within Visual studio 2010) using the Visual Studio 2005 compiler and linker.

The problem is that within my dll I can see local variables of native C++ types (longs doubles char * etc) but the debugger refuses to show any of my C++ classes or STL types (e.g. std::string). I don't think it is an issue with the PDB for my dll as I can clearly set breakpoints and see native c++ types (longs, doubles, char * etc) but it just refuses to show any classes either in the watch window or when I hover over the variable. At first I thought it might be an issue with the microsoft stl implementations so I created a simple local class that only contains intergers and NO complex classes/stl member instances. I instantiated it, set a break point and I still cannot see this simple class. The simple class looks like this
class LocalClass
{
    public:
        LocalClass();       
        int         myInt;
};


So in effect this is nothing more than a glorified int!!

I instantiate it simply by doing the following (from within another class method)
LocalClass *cl = new LocalClass();
When I add the this pointer and cl variable to my watch window it gives me this
this    CXX0017: Error: symbol "this" not found 
cl  CXX0017: Error: symbol "cl" not found   
What I believe is happening is that the debugger just cannot figure out where the "this" pointer is and hence it goes bezerk and gives up.

So just to verify that I indeed did natively compile using visual studio 2005 I stepped into the new method sure enough it is calling into the version 8 runtime that ships with 2005 (strangley enough I can see all the complex types in .dbgheap.c and afxmem.cpp.

Here is the stack when allocating the above class.
msvcr80d.dll!_heap_alloc_dbg(unsigned int nSize=8, int nBlockUse=1, co
msvcr80d.dll!_nh_malloc_dbg(unsigned int nSize=8, int nhFlag=1, int nB
msvcr80d.dll!_malloc_dbg(unsigned int nSize=8, int nBlockUse=1, const 
mfc80d.dll!operator new(unsigned int nSize=8)  Line 347 + 0x10 bytes    
mydll.dll!CApplicationData::CApplicationData()  Line 88 + 0x7 

It is drivng me nuts and I really don't want to trace every line to the debug window!
Coordinator
Apr 20, 2014 at 10:13 PM
I don't really have any ideas offhand other than the two links you already dismissed. I've been meaning to create a test project to see if I can reproduce your problem, but I just have not had time. It would help if you can create and attach a standalone solution containing minimal projects that demonstrate the problem. If you do, I'll be happy to investigate.