When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )
alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg
Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking.
The simpler types of data (e.g. ints) (usually?) get their correct values shown.
Did this ever happen to you too?
This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?
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.
Yes, i see this problem in my debuger, in my case its connected to Unicode vs NonUnicode.
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.
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.
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.
This is a bug that has been in the Visual Studio debugger since forever and still occurs in Visual Studio 2019.
It is random.
Sometimes making a code change and recompiling resolves the problem, and sometimes it doesn't.
Related
Sometimes when using the data viewer in debug mode in Visual Studio 2010 (C++), I cannot see the data. I can see the data of many other variables, but not the one shown below. The element below is an array. How do I get rid of the "(error)" messages and see the data?
Update: I wrote a member function called "view". If I jump into the function call, the debugger works fine and I can see all the class variables. So maybe this is an issue with the debugger following pointers.
Is your object "test" one of standard STL class (vector, set, etc..)?
If yes, usually you should get also size in debugger tooltip - and this looks like corrupted autoexp.dat file.
If you did some modification in autoexp.dat, then try to revert it back and check if this helps.
I'm using visual studio for kernel debugging. Yes, I know all the tutorials say to use WinDbg, but visual studio is actually spectacular now for Kernel debugging. It's a more recent development.
When I have a pointer in the watch window, assuming it is an array, I would like to see multiple items in its list at once as a drop down. Normally in Visual Studio you would add ",AMOUNT" after the pointer to get multiple items, but this does not work when in kernel debugging mode.
Is this option available?
[Edit] As requested, I have attached an example image. In the watch window I have included multiple attempts to access the data in the "ProcessPath" variable.
During Kernel Mode Debugging, Watch window appears to work through WinDBG expression evaluator. That is, it works pretty much the same as WinDBG's Watch window. Therefore, your question is not really Visual Studio related, but rather it boils down to WinDBG's watch.
This is why ,amount syntax will result in showing amount as result - WinDBG treats , as "evaluate and discard", just like c++ does. This also explains why you prepend variables with $! which is WinDBG syntax for local variables.
While WinDBG supports quite a bit of c++ syntax, it will unfortunately fail to recognize c++ cast-to-array syntax such as (char(*)[4])$!ProcessPath (by the way, this works when debugging a usermode target in in VS debugger).
I have not found a single way to cast to array in WinDBG. It seems the only workaround available is to add specific elements of array to watch, like
ProcessPath[0]
ProcessPath[1]
ProcessPath[2]
ProcessPath[3]
ProcessPath[4]
ProcessPath[5]
ProcessPath[6]
ProcessPath[7]
ProcessPath[8]
One of our application (windows form application C++, MSVS 2010 )crashes after few minutes of usage. Task manager tells that the memory usage grows to 60% of total system RAM in just few seconds of the run.
I used Intel inspector to get any idea of memory leaks. I was expecting I will get a a list of functions that are creating problem. But what I got is only the dlls as can be seen in the following screenshot.
The application is using a couple of third party libraries such as those starting with Pv, OpenCv cdio, CAIO etc. As you can see the last one is an opencv library, and is occupying close to 400MB. (How is this possible ? )
Also the right panel shows different types of leaks which have occurred.
I want to pin point the memory leak code and correct it. What should be my strategy, what functions should I start looking into? Why the inspector is not giving me correct source code and just giving me dlls? I am sure dlls are perfect as these are used by millions of people.
Please advice,
Thanks
Update
I think I have done something wrong in various compiler setting while generating the exe. .
As can be seen above, no symbol information is loaded. That was the reason I was unable to get the source code where memory leaks were happening. Pressing F1 reaches me to the following instructions:
Troubleshooting No Symbolic Information Symptoms
In the Sources window, the Intel Inspector displays no source code for any code locations in the problem set.
Details Intel Inspector cannot display source code for viewing and editing unless the application has symbols available.
If the Intel Inspector detects no symbols for a location, it sets the call stack and code pane to the first location where it can find symbols.
If the Intel Inspector cannot find any location in the call stack with symbols, it provides the module name and relative virtual address (RVA) for the location.
Possible Correction Strategies
1- When you compile and link an application on Windows* systems:
a) Enable the debug information compiler option.
b) Set the linker option to generate debug information.
2- Configure the project to search non-standard directories.
3- Copy the symbol files, such as *.pdb files, to a location where the Intel Inspector can find them.
So now I am focusing on the above correction strategies. My latest question are:
1- how do I set the above three strategies in MSVS 2010.
2- Do I need to use debgug exe or a release exe while using Intel inspector ?
If this is your source code, and you are sure your code is causing the leaks, you can use Visual Leak Detector.
You just need very minimal changes in project - I would say just #include<vld.h> (which you can make conditional). It will report all memory leaks on Debug Output window. This differs from VC++ standard leaking staticitics - it shows where memory was allocated.
Probally it couldn't load symbols for some module / modules and thus the information is a bit incorrect. Is symbol file (like opencv_core240.pdb) opencv_core240.dll available? Check it!
Also I would suggest to try another memory leak detectors to compare their results to each other.
In general when using Inspector the recommendation is to use a debug build of the code. Release builds may optimize away some important pieces of code.
You can also enable just debugging symbols in a release build, which is important when using Amplifier and Advisor. You can do this by going to Project -> [project name] properties... -> Linker -> Debugging -> Generate Debug Info -> Yes and Project->[project name] properties...->C/C++->General->Debug Information Format -> Program Database. Even if you are in debug configuration make sure these settings are set correctly, because they may have been accidentally modified.
WRT what you are seeing in the report:
OpenCV (and others) isn't occupying 350MB, rather there has been a leak of that size (which means the last pointer to dynamically allocated memory was overwritten without releasing that memory). Is it possible that you're misusing the library APIs?
Also, you may find it useful to look at the call stack at the location of the leak. You will possibly find the API leading to the memory leak which can help you pinpoint the issue.
I have a simple C++ program (command line with Boost libraries) that I developed under Visual Studio Community 2013. I want to deploy it on other Windows computers, so I am testing InstallShield LE in Visual to do so (I am new with InstallShield). I added an InstallShield project in the current solution and I managed to create a setup.exe.
When I test it on another computer, setup seems OK but when I try the application, I have weird error:
MyProgramm.exe --help
Sends correct result (but it is not really interesting).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Fails with a Windows displaying this message:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
What did I miss?
I built Release configuration only. How can I be sure that I have checked all the merge modules or InstallShield prerequisite ?
You will have to identify what is going wrong. Typically the symptom you describe indicates that an exception caused the process to terminate. One common source of such exceptions is misuse of an invalid pointer.
But why does it work on one computer and not another? Depending on the code it could be random incidental things. But as long as this repeats every time, it's more likely to be environmental. This could mean a missing data file, a missing registry key, a missing service, or a missing .dll dependency.
Because you can run the program at least one way, you know it's not a static dependency. If it were, you'd get a message about an inability to load some file or one of its dependencies. But instead in some execution paths you see a crash. So if it's a dependency, it's what InstallShield calls a dynamic dependency. I'm not personally a big fan of it (I'd much rather be told exactly what might be required), but there is a dynamic dependency scanning wizard that can help identify such files and include them into the project.
That will only help if the problem stems from something like this:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Or maybe from a COM-related variant of that that looks something like this:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
The common problem here is that neither of these blocks of code verifies the function it's calling is safe to call. In the first case, proc (or even hMod) could be null; in the second, spSomeFace might not have been successfully created an instance. While the code can (and should) prevent these scenarios from crashing, fixing the crash will not get your application to actually do what it's supposed to, and you'll still have to fix the reason that the procedure, dll, or instance could not be initialized as desired.
It's also possible that you're missing a data file or registry key that at some point is being used in an incorrect fashion. For example, the code may assume a data file exists, build a pointer from data it reads, and fail to work correctly because the file wasn't available and thus the buffer it read into was never actually initialized.
So in short, to solve this, if it's not a dependency scenario that the dynamic dependency scanner can assist with, you may have to debug the code in question. You could try tools like Process Monitor and look for errors that involve your application shortly before the crash. If you have source and symbols, you could try running the program under WinDbg to figure out exactly what was crashing, and then try to figure out why it does so in one environment but not another. But from just the information you've already provided, there's nobody that can tell you the answer.
I've experienced this with every version of Visual Studio starting from 2012 (2012, 2013, 2015 Preview), on multiple computers and multiple projects, but I haven't figured out how to fix it:
Whenever I'm debugging a 64-bit(?) C++ console program, after a few minutes and seemingly completely randomly (when I'm not clicking or typing anything), the console window for the program spontaneously closes and I can no longer debug or step through the program with Visual Studio. When I press Stop and attempt to restart debugging, I usually get ERROR_NETWORK_UNREACHABLE:
// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE 1231L
If I try to attach to the process manually I get the error:
Unable to attach to the process.
The only fix I've found for this is to restart Visual Studio. I can't find any other way to fix it, and I've tried running Process Monitor but haven't found anything.
What causes this problem and how can I fix it?
(?) Upon further checking it seems that this only happens in 64-bit mode, but I'm not 100% sure.
Ok, this is just so wrong
I also have issues with this bug, and in my case it occurred every other debug session. Which meant debug -> stop -> debug -> bug -> restart visual studio -> go to start (repeat every minute during the whole day).
Needless to say I was driven to find a solution. So yesterday I tried procmon, spend hours looking at API monitor differences, looked at plugins, netstat, etc, etc, etc. And found nothing. I gave up.
Today
Until today.
To track down a stupid bug in my program today, I launched appverifier. For my application, I ran the 'basics' tests and clicked save. After a few hours this led me to the bug in my program, which was something like this (extremely simplified version):
void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
Obviously this is a bug and obviously it needed fixing. I noticed the error after putting a breakpoint on the memcpy line, which was not executed.
After a stop and 'debug' again I was surprised to find that I could actually debug the program for the second time. And now, several hours later, this annoying bug here hasn't re-emerged.
So what appears to be going on
So... apparently data from my program is bleeding through into the data or execution space of the debugger, which in turn appears to generate the bug.
I see you thinking: No, this shouldn't happen... you're right; but apparently it does.
So how to fix it? Basically fixing your program (more particular: heap corruption issues) seems to make the VS debugger bug go away. Using appverifier.exe (It's in Debugging tools for Windows) will give you a head start.
Why this works
Since VS2012, VC++ uses a different way to manage the heap. Hans Passant explains it here: Does msvcrt uses a different heap for allocations since (vs2012/2010/2013) .
What basically happens is that heap corruption will break your debugger. The AppVerifier basic settings will ensure that a breakpoint is triggered just before the application does something to corrupt the heap.
So, what happens now is that before the process will break the heap, a breakpoint will trigger instead, which usually means you will terminate the process. The net effect is that the heap will still be in-tact before you terminate your program, which means that your debugger will still function.
"Test"
Before using appverifier -- bug triggered every 2 minutes
While using appverifier -- VS debugger has been stable for 5 days (and counting)
This is an environmental problem of course. Always hard to troubleshoot, SysInternals' utilities like Process Monitor and Process Explorer are your primary weapons of choice. Some non-intuitive ways that a network error can be generated while debugging:
Starting with VS2012, the C runtime library had a pretty drastic modification that can cause very hard to diagnose mis-behavior if your program corrupts the heap. Much like #atlaste describes. Since time memorial, the CRT always created its own heap, underlying call was HeapCreate(). No more, it now uses GetProcessHeap(). This is very convenient, much easier now to deal with DLLs that were built with /MT. But with a pretty sharp edge, you can now easily corrupt the memory owned by Microsoft code. Not strongly indicated if you can't reattach a 64-bit program, you'd have to kill msvsmon.exe to clear up the corruption.
The Microsoft Symbol Server supplies PDBs for Microsoft executables. They normally have their source+line-number info stripped, but not all of them. Notably not for the CRT for example. Those PDBs were built on a build server owned by DevDiv in Redmond that had the source code on the F: drive. A few around that were built from the E: drive, Patterns+Practices uses that (unlikely in a C++ program). Your debugger will go look there to try to find source code. That usually ends well, it gives up quickly, but not if your machine uses those drive letters as well. Diagnose by clearing the symbol cache and disabling the symbol server with Tools + Options, Debugging, Symbols.
The winapi suffers from two nasty viral infections it inherited from another OS that add global state to any process. The PATH environmental variable and the default working directory. Use Control Panel + System + Advanced + Environment to have a look at PATH, copy/paste the content of the intentionally small textboxes into a text editor. Make sure it is squeaky clean, some paralysis at the usual mess is normal btw. Take no prisoners. Having trouble with the default directory is much harder to troubleshoot. Both should pop out when you use Process Monitor.
No slamdunk explanations, it is a tough problem, but dark corners you can look in.
I have the same problem. Thought it was related to 64 bit console apps, where it is very easily triggered with almost any debug session. But, it also happens on 64 bit windows apps too. Now I am seeing it on 32 bit windows apps. I am running Windows 8.1 pro on a single desktop with the latest version of vs 2013 and no remote debugging. My (added) extensions are Visual Assist, Advanced Installer, ClangFormat, Code Alignment, Code Compare, Duplicate Selection, Productivity Power Tools 2013, and Visual SVN.
I discovered that the "Visual Studio 2013\Settings\CurrentSettings.vssettings" file gets corrupted. You can delete this file and recreate it by restarting VS or you can try to edit the XML. I then keep a copy of a good settings file that I use to replace when it gets corrupted again.
In my case, the corrupted line begins with
</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"
... and it is extremely long (I think this is why it is prone to corruption).
I just disabled in the Menu
Tools > Options
Debugging > Edit and Continue
Native-only options > Enable native Edit and Continue
and now it does not give the that stupid error which was preventing the starting of the debuggee application.
I also had the same problem with VS2015. It was so frustrating that a simple Hello World program gave this error when I ran debugger for the second time. Tried uninstall and reinstall and didn't work.
Finally, the solution mentioned in https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug
worked. Reset all visual studio settings using Tools->Import and Export settings. Now the issue is not occurring.