I have a large C++ project under VS2008, and use edit & continue quite a bit during debugging. However, sometimes after quite minor changes edit and continue simply stops working. Debug / apply code changes is greyed out. If I rebuild all, it tends to come back, but this takes ~30mins. It seems very sporadic, much more so than in previous versions of Visual Studio. Any ideas what could be causing this?
FWIW, I'm on VS2008 SP1, with Whole Tomato plugin, running on a 32bit 2G XP box. I suspect the problem could be resource related, but this is no more than a hunch based on the fact that the problem seems to occur more often if I have not rebooted recently.
I've eventually moved onto VS2010, SP1, and I'm delighted to note that edit and continue works like a charm. Far better in my case than any previous versions and quite a bit faster. FWIW, I've also moved onto a 64bit Windows 7 box with 16gb of RAM, so can't say definitively whether the problem was resource / compiler or platform related, just that the combination I'm currently using works very well.
Related
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.
basically, I have a native C++ application which obviously crashed from time to time during code development. After fixing some bugs it runs rather smoothly. However, I noticed a rather weird behaviour which is very confusing to me.
It is a CMake-based project and I have an option of packaging the application into a zip file. When I run the executable from a freshly extracted zip - the application runs normally (and performance is high). However, say, if it crashes couple of times - the next start the behaviour is the same, but everything runs terribly slow. The test case I have (albeit manual) is very straightforward and I can repeat it easily.
Once the application is slowed down all I have to do is to rename the folder the application is located in and the performance rises again. Until it has crashed couple of times.
Obviously, this is not a problem once I get rid of the crashes. However, it seems to me that once the system (Win8.1 x64) detects persistent crashes it runs it in some different mode(?). And it looks like the app that I run from the IDE (MSVS2013) has received this "penalty". So it runs terribly slow even in release mode, let alone debug.
So I have a couple of questions to the community. First, have you ever observed such behaviour? Second, is the reason for slowdown indeed some system-wide information stored upon application crash? And finally, do you have an idea how to fix it?
Note: I could probably move the source folder to a different location, but it would require quite a lengthy rebuild step. Moreover, I'm just curious about what is going on. Also, system restart and full rebuild in the same folder didn't help.
Some context: the application uses Qt4 (also, Qt plugin system), MITK, ITK, VTK, CTK, OpenCASCADE, glew and related libraries all build from source on this machine.
Cheers,
Rostislav.
Pretty much a year after asking this question, and having the problem "self-resolve", I think I found the answer and decided to post it here in case someone would run into similar problem.
It seems to me that my application was put by the system into the fault-tolerant heap (FTH) after several crashes. Some more information on FTH can be found on MSDN. It might make sense to disable the FTH on the developer machine (at least temporarily) when debugging a particularly nasty crash.
The actual question: what are the differences between running in Visual C++ 2010 (both release and debug mode) and standalone, excluding anything that couldn't cause the problem stated at the bottom of this post?
I have a very specific problem with my program, so I am not going to post the code. If you would like to know details of the problem to gain some understanding, I post them at the bottom. Instead, I ask: what are the differences in running in visual c++ and standalone?
I am using Visual C++ 2010, and my program is using SFML 2.0. It runs fine in studio (I am calling it studio because it is easier to type), but when run standalone on some computers only a bug will occur within the program, to do with movement being delayed but other parts not. I cannot find any links between the computer specs of the users who test it and whether they work or not.
All dlls and such are included (at least, I think they are - the program runs fine, as detailed at the bottom - maybe some users have some framework installed?). On my computer, it works all the time in studio but not standalone. On my netbook, it works, on my older computer, it doesn't. The only project settings I changed with vc++ directories and linker settings.
Problem details:
All the sounds sound slightly different and there is a possible high pitched background noise. Character movement, enemy movement and space bar delay which is supposed to be 0.5 seconds is increased to about 5 seconds but "generating pixels" (an aspect in the game with the arrow keys isn't.
I'm stressing again that it only happens on SOME COMPUTERS, mine included, but always works when run within studio. A number of people have tested the game, and some reported the problem and others different.
[NOT THE MAIN POINT OF THE QUESTION BUT HERE IS AN EXTRA BIT: If you are so willing to help me that you wish to look through the entire source code, it's here: http://dl.dropbox.com/u/53835113/EVERYTHING.zip [note: ignore the massive amount of bugs and memory leaks other than the problem described :P]]
EDIT: THE POINT ISN'T THAT I WANT MY PROGRAM DEBUGGED! That is an optional extra. The question: what are the differences in running in visual c++ and standalone?
More edits: Found that the problem is due to the frame time not being correct. Not sure if this provides some insight.
Thanks to anyone who tries to help me!
GetFrameTime() in SFML was removed in a recent version because it returns the time since last frame rather than the time since last update. As a result, the it may return 0.
When the compiling of a project is complete (or at least when it says it does), I receive no window, no error message, or anything; VC++ freezes up and my computer basically stops responding altogether.
After about five minutes, Task Manager finally pops up and I'm able to close the program. Upon doing that, I see this:
I'm going to take a wild guess here and say something is wrong with the image above. On a side note, the process' (MSBuild.exe) don't (seem) to open all at once, but that may only seem that way because the computer becomes frozen multiple times until I shutdown vc++.
Is this a known issue and if so what should I do so I can compile programs without this issue once again?
Additional Information:
Windows 7
Microsoft Visual C++ 2010 xpress
Project Type(s): I've tried on "Windows Form Application" project and "Win32 Project", both produce the same results.
Compiling projects in VB works as it should. (in case this helps at all)
As suggested by Hans Passant, disabling avast! solved the problem.
Did any error pop up during installation?
The standard thing to do (that almost always helps) is rebooting, reinstalling, (rebooting,) and trying again. Chances are absolutely nobody knows what's going wrong (even MS).
I'm working on a bug where I have an MFC application that does weird things when installed in when Sophos Safeguard hard drive encryption is installed. I'm sorry to be so vague here, but I'm writing this away from the office so this is all from my (poor) memory.
Three things I've noticed:
AfxGetResourceHandle() doesn't return a consistent resource handle. There is a single case where we try to load a string resource, and for some reason, the resource handle that we get from this method is different to all the other stings.
Can't construct a CDocumentTemplate. There is a trace error which I cant seem to recall. Will edit and post when I'm in tomorrow.
This behaviour appears to manifest in a Visual Studio 2005 version of the project, but not a Visual Studio 2008 version. Unfortunately moving to the 2008 version is not an option.
The bug is not always reproducable if I step through with a debugger. Also, bringing up debug message boxes changes the behaviuor, which leads me to think that either there is some kind of race condition going on with the way MFC events are being handled, but I'm not sure how I'll ever know for sure, or even what I can do about it if I did.
I think there's some underlying reason that the app is behaving weirdly, but what I've posted are more symptoms. Can anyone think of what I should check for?
I've run Windows update on the test environment to ensure everything was up to date, and I've examined the process in procmon to see if the disk encryption stuff was getting in the way and conflicting with files - it didn't appear to be, but it does appear to be involved in some way as our app accesses Sophos related paths in the temp directory.
If your code is multithreaded (which I assume it is, since you mentioned the possibility of a race condition), then the likelihood is that the decryption delays are exposing concurrency flaws. You might want to try running the application off of a network share or similar slow access device to see if it manifests similar problems.
Turned out that the antivirus software was injecting itself in a way where the antivirus' software's resource handles were overridng the app's resource handles. Yuck!