From time to time I see that debugger doesn't honor breakpoints at all, mostly when there are threads involved. Is this a known problem? If not I'll try to create a repro.
FYI a locked MDB file is causing this behaviour. Filled a bug report:
https://bugzilla.xamarin.com/show_bug.cgi?id=5608
I guess that your IDE is just not attached to those process which works at the moment when you see no stop on breakpoints. Look at this Walkthrough: Debugging a Multithreaded Application to see how to do that safely.
Hope that helps,
Related
Every time I try to run my code, I am having this error: "Csc.exe" exited with code - 255.
I removed and re-installed Visual Studio 2015 and it did not help.
Does csc.exe succeed with different code?
It is possible that you’ve found a bug in the compiler that causes it to crash when trying to compile your particular program. To see if this is the case, create a new “Console App” project with Visual Studio (VS) and see if the default app in the template compiles and runs. If that works, then your code might be triggering a csc.exe crash. If that doesn’t work, your VS install might be completely broken in which case I would recommend uninstalling and reinstalling VS (but you already tried that). If you cannot get VS to run even simple programs on your computer, you’ll need to try to track down why it is crashing and see if it is something you can manually fix. If your system is messed up enough and it is not worth tracking a fix down, you might consider reinstalling Windows (using the “Reset” feature).
Another thing to try is running your code on another computer with VS installed. That can help determine if the issue is your code triggering a compiler error versus your computer being messed up.
If csc.exe only crashes for your particular code, then that is a bug in csc.exe. If there is an issue with your code, csc.exe should generate a nice error explaining the issue with your code instead of crashing.
It is also possible that your code is valid but a compiler bug causes csc.exe to crash. An example of this (with VS 2017 and csharp7) is roslyn#19182. If this is the case, you might try using the VS feedback (frowny face/feedback button in the upper right hand corner) feature to report the issue so that the VS developers know about it. Also, you might be able to poke your code around until suddenly VS starts running successfully. If this is the issue, it might be hard to guess why csc.exe is crashing, but, if you can, try to isolate the issue. For example, if csc.exe was running fine before you made some changes to your code, look at the changes you made and see if undoing them results in csc.exe running successfully again. Then try to make a new, minimal repro which causes csc.exe to crash and send that as feedback using VS’s feedback mechanism or by reporting a bug against the roslyn project. You might also ask a new question here about why that particular code causes csc.exe to crash. With particular code, people might be able to guess why csc.exe can’t handle it and suggest workarounds to use while waiting for the VS team to release a fix.
As it is, your question does not have enough information to guess why csc.exe was crashing for you. Hopefully this answer provides some guidance on what steps you should take if you ever end up in such a situation.
I get the Microsoft VS Delay Notification pop up consistently when I am trying to attach the debugger to a remote process (Native only, with no authentication). The process runs as a service on the remote machine, but Visual Studio (2005) seems to have no problem with that when it's running as a service locally.
I've loaded the symbols correctly (as in specified the right directory under Tools\Options\Debugging\Symbols), but this doesn't seem to help.
I've tried starting VS 2005 in Safe Mode, but that doesn't seem to make a difference either.
I had the same issue and used ProcMon util to look at waht my devenv were doing.
In my case it was waiting for loading symbols. So you you should check your Env. variable _NT_SYMBOL_PATH and if there is cached symbols if no - all this time your VS is waiting for downloading it.
One possible solution is you have many currently set or lingering (invalid) breakpoints.
Try clearing all the breakpoints and see if it helps.
There are more possible solutions here:
http://connect.microsoft.com/VisualStudio/feedback/details/498240/microsoft-visual-studio-is-waiting-for-an-internal-operation-to-complete
Hope this helps.
I've just had this problem when I turned on both native and managed debugging on a single application.
Turning off the native debugging fixed the problem.
The one thing that helped me is updating the package. Open the solution that is having this "waiting for internal operation to complete" then Go to Tools - Nuget Package Manager - Package Manager Console. Then run "Update-Package". After the update, I was able to close and open the solution with no problems. Hope this helps your issues.
I had the similar problem and it occurs because of the variable expression I created.
For example:
variable1 = variable1 - variable2 (gets warning)
variable1 = variable2 - variable3 (No Issues)
I had the same problem, did a lot of googling tried several things but didnt solve the problem. Finally I used processexplorer to check the devenv process and found there is a child process for devenv.exe, it was cmd.exe and it has another child process node.exe. So I went to Programs and Features and uninstalled Node 1.1 VS 2013 extension and Node package manager. It took quite some time to uninstall it even though I am using i7 quadcore processor with 16 GB RAM it took almost close to 1 hour to uninstall these two sofwares from my laptop. And this solved the issue.
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.
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.
I wanted to know if the "user.dmp" created by drwtsn32 has only the most recent crash.
I tried to capture a few crashes. But when i tried to analyse it, I just see one crash.
Thanks for the help,
Arun
Just one crash dump, although the log file may contain information on previous crashes.
Run drwtsn32.exe (without any arguments) to bring up the configuration dialog.
Yep. I recommend setting WinDbg as the default post-mortem debugger. You can save your dumps from there.