I have a complex C# project that I ported over from C++ and now I'm in the middle of debugging. Things are working great most of the time but more often than not I have huge problems with Visual Studio and debugger attached to WP7 emulator. For some strange reasons, my debug session is often abruptly terminated while stepping through the code without any indication from VS or any trace left in the Output window.
There are even some cases when a breakpoint is hit and then when I hover over a particular variable, VS simply exits the current debugging session. If I refrain from inspecting the variable contents, nothing happens and VS waits happily forever.
As the app is a memory hog by definition, I am wondering whether I am hitting any debugger / WP7 / emulator limits of any kind. Why would a mouse over variable terminate debugging session? Most of all, why is there no trace of what happened? I am left to wonder whether this is a VS issue or an emulator issue or even an app issue.
What are your computer specs?
I have seen similar problems on computers with low specs, especially computers with low memory.
Try clearing out memory hogs from your PC (CCleaner is a good tool) and running Visual Studio in administrator mode.
I have found this post which has helped me immensely. It appears that having ToString() overrides can sometimes crash the debugging session. I have implemented mine for the sole purpose of having customized value representation of variables/values in the debugger.
After removing all the ToString() overrides I am able to debug normally again. The thing that still puzzles me is the fact that no exceptions are leaked from my ToString() overrides so I wonder why debugger behaves the way it does but at least the problem is solved for now.
I hope this helps someone.
Related
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I'm using Visual Studio 2012 Update 3. When I open a project, VS automatically creates a process called <myproject>.vshost.exe, even before starting to debug.
When I start debugging and later close the debug application, most of the times the <myproject>.vshost.exe process closes as well. When this happens, devenv.exe starts taking up 3x more memory than normal and CPU goes up to 25% (on a i7 Quadcore with 8GB ram) for around 1 minute. At the end of 1 minute, a new <myproject>.vshost.exe opens up (even though I'm not debugging), CPU falls back down to 0 and memory drops back down as well.
Trying to start debugging whilst the CPU is at 25% and <myproject>.vshost.exe is not running in the background will results in the solution building but the debug does not start.
If I wait until the CPU falls back down and <myproject>.vshost.exe process is running again then I can start debugging normally.
This happens to me 80% of the times after closing the application I am debugging. The remaining 20% of the times when I stop debugging <myproject>.vshost.exe continues running in the background and I am able to start debugging again immediately after with no delay.
This also happens regardless of code changes in between debugs.
This is a new install of VS2012 U3, I've tried resetting all settings and disabled ReSharper but still no joy.
I don't want to disable vshost debugging because of the features I would lose.
Has anyone else encountered this problem before? Is this a known issue? Are there any solutions/workarounds?
EDIT
I changed the platform from Any CPU to x86 and it appears to work properly, but I still can't understand why I shouldn't be able to debug it as Any CPU. Even though this might be the workaround I'd still be interested in knowing whether this is a known issue and if there are other (better) solutions.
By 'working properly', I mean that when I stop debugging the vshost doesn't close, in fact it never closes, but the CPU of devenv stays at 0% and it allows me to start and stop debugging as many times as I want one right after the other.
EDIT2
Actually it appears that changing the platform to x86 only worked properly for a while, after about 20 rebuilds it is now doing the same as leaving it as Any CPU.
On another note, closing and opening VS makes no difference.
I've ended up formatting the computer again and re-installing everything from scratch. For not it appears to be working fine, let's see how long this lasts for.
I know this is several months old but I'm trying to post this answer in a few places since this is what was causing my ills: I had the Data Sources toolbox open in Visual Studio 2012. Once I closed that, it seemed to eliminate the lengthy delays when switching windows. You may also want to close Server Manager if you don't need it open.
I know this is old Post but, I think I need to share my solution for everyone.
and this is my first post so, please improve the answer if I miss something.
I have the same issue with Visual Studio 2012, When I try to build or debug it will use CPU up to 100%.
So, I try below steps to reduce the CPU usage while debugging:
Please close unnecessary opened file.
Hide unnecessary debugging panels like: breakpoints, auto, local, output, find symbol result, etc.
If still use high CPU then try to hide call stack panel.
Remove unnecessary breakpoints.
I'm currently learning OpenGL and I've noticed a rarely occuring performance problem:
My program is rather small so it's not a performance problem with the code itself, but when I'm running the code via Visual Studio I sometimes only get 1-2 FPS instead of the usual 60.
Once this happens I can restart the program as often as I want to (in debug and release mode alike) and it won't go away.
However, when I close my Firefox (or manually shut down the plugin-container.exe though task manager) and restart my program everything is fine again. After that I can start Firefox again (with the same tabs open) and the bug does not reappear.
I use the newest version of Firefox, and I've had this bug with several programs already - both made by me and others and using different versions of OpenGL. However I don't think I've had this problem when starting a compiled exe directly, but only by using the Run feature of Visual Studio.
I've searched the web but I only found a link about the generally bad performance of this plugin-container.
Does anyone else have this problem? Do you know any walkarounds or fixes?
PS: Regarding isti_spl's answer:
The CPU utilisation of the plugin-container.exe jumps to the 50% limit when the problem happens.
I'm working with Visual Studio, but the problem only occurs when I also have Firefox running (it most certainly is because of this plugin-container, so it probably won't happen with other browsers).
It's hard to isolate the problem because I can't replicate it. It might happen 1 out of 50 times.
I'll see if closing flash-related tabs (youtube, blip.tv etc) fixes the problem next time it happens.
Can you isolate the problem?
You first mentioned running visual studio then firefox. Please try to run separately.
Under FF. is it caused by WebGL or flash plugin? Is it caused by visiting specific sites?
Is it FF specific or happens under other browsers too?
Does CPU utilisation jump high? Please verify that too and which process consumes most CPU.
Not sure, but likely gpu driver + flash problems.
If so, the problem is not in your code, other GL program should be affected too.
So in a C# .NET v4 project in VS2010, I've got a debugging issue. Frequently, if not most of the time, the debugger freezes when you try to use it - typically on exceptions, it's usually OK if you try to manually break.
The only way I've discovered to fix this is to kill the debugged program ([projectname].vshost.exe), which unlocks the IDE and executes all the mouse presses and things that happened in its absence.
The main Windows GUI is not affected. There is minimal CPU load. Waiting does nothing. The output window (full of "Loaded xxx, symbols loaded") is uneventful. I've read about symbol servers deadlocks, or deadlocks in the GUI, but neither of those are the issue here (the symbol servers are disabled).
Anyone have any ideas? This is giving me a big problem, because I can't effectively debug the program.
Unfortunately, this could be any number of things.
Most often, I've had this type of thing happen when the program is caught in an infinite loop... but since yours is breaking on exceptions, maybe you could add some exception handling?
Never did figure this out. Oh well. Limped by with task manager open all summer, but made it through OK.
What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.