Visual Studio: Garbled debug watch of std::string's ?

Answer 1

Looks like your debugging symbols are incorrect.

Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.

If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.

A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?

It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.

Answer 2

Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).

Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.

Answer 3

Yes, i see this problem in my debuger,
in my case its connected to Unicode vs NonUnicode.

Answer 4

One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.

Answer 5

I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.