Going mad here!
Visual Studio is ignoring breakpoints, skipping with a "The breakpoint will not currently be hit. The source code is different from the original version" alert and the breakpoint turns white.
Simple test - new WinForms project with a few lines in the form load event.
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Console.WriteLine("1")
Console.WriteLine("2")
Console.WriteLine("3")
End Sub
Set a breakpoint on any of those lines, I get the above error, the console outputs as expected (1/2/3) and the form loads with no pause break.
Fresh boot of PC makes no difference.
Running VS 2013, Update 4, on Windows 7 x64.
Jim
In my case I was trying to run the unit test via a test agent. This does not allow debugging to occur. I changed my testsettings.settings file so that the role read "local" instead of remote, and then I was able to debug.
I also came across same problem. I rebuild my solution and checked Warnings. There were several warnings, one was of reference missing, due to which break point was ignored. As i fixed the reference missing warning, it started working.
Related
This is driving us crazy... In VS2010, MVC2 projects, not all projects.... both on a project that was upgraded from 2008/mvc1 and on a brand new project created within 2010/MVC2, we have the following behavior:
1) develop as normal..
2) hit F5 or CTRL-F5 to open up a browser
3) works great!
4) add a CSS file (or JS file or any file, or remove any file) in the project
5) immediately the dialog pops up "WebDev.WebServer20.exe has stopped working"
You have to close the program, and "F5" again - and all is right with the world...
Say we then modify an existing css file. No problem. But adding or removing one, immediate crash.
It seems like the development webserver is "locked on" to the project file and when it detects a change, it dies.
The Event Viewer is pretty unhelpful. The following is logged:
Faulting application WebDev.WebServer20.exe, version 10.0.30319.1, time stamp 0x4ba204ca, faulting module KERNEL32.dll, version 6.0.6001.18215, time stamp 0x49953395, exception code 0xe053534f, fault offset 0x000442eb, process id 0x%9, application start time 0x%10.
This is happening on all of our developer workstations, which include some with Windows Sever 2008, some with Windows XP, and some with Windows 7. All are running VS2010 Premium with ReSharper.
Also, the same thing happens on projects which target the 4.0 framework, only the error message referrs to WebDev.WebServer40.exe instead.
Google has revealed nothing. We've already tried "setting a static port" instead of a dynamic port - no help.
Please help if you can.
So, as it turns out, the problem was due to a certain use of MVCTurbine and StructureMap, but it seems likely that the problem would also occur with other IOC Containers, not just StructureMap.
The author of MVCTurbine has expressed that the fix will be in version 2.2 of that product.
In the meantime, one extra line of code in your Global.asax will solve this problem:
//VNEXT: after Turbine 2.2 we wont need this line anymore...
protected override void ShutdownContext() { CurrentContext = null; ServiceLocator = null; }
This article shows the particular use case we were addressing. The "normal plain vanilla" use of MVCTurbine and StructureMap would not have this problem.
Obviously, great thanks to Javier for being so responsive to help requests!
VS 2005
For example,
My employees gave me a project with about X try-catch statements.
X > 100 .. 300
I need to test a project. Is there a way to mark each (every) beginning of catch as a breakpoint ? I don't want to do it manually. Maybe there is some settings that fit to me ?
Go to Debug > Exceptions (Visual Studio 2013 and earlier) or Debug > Windows > Exception Settings (Visual Studio 2015 and later).
In this dialog you can enable first chance debugging of exceptions - when an exception is thrown, the debugger will automatically break at the throwing code before the "catch" code is executed, allowing you to debug it.
What you want to do is ask it to break when CLR exceptions are thrown, not only when they're unhandled (image from Visual Studio 2013 - 2015 is similar but now is in a view rather than a dialog):
(Note: This won't get the debugger to break whenever you execute a try block, only if the exception is actually thrown)
Short answer is no. But you might be able to make some an aspect-oriented plugin to your project that captures the catch crosspoint, then you just have to put one breakpoint at in your aspect
I am not aware of a possibility that allows setting breakpoints in code by some pattern. The closest you can come to is Debug/New breakpoint/Break at Function where you can specify the file and line number. If you can get this automated and working down a list generated by a grep search, you might find a way. Here is something from the IDE samples that might get you started:
' Sets a pending breakpoint at the function named "main". It marks the
' breakpoint as one set by automation.
Sub AddBreakpointToMain()
Dim bp As EnvDTE.Breakpoint
Dim bps As EnvDTE.Breakpoints
bps = DTE.Debugger.Breakpoints.Add("main")
For Each bp In bps
bp.Tag = "SetByMacro"
Next
End Sub
However, why do you want to set those breakpoints anyway? If it's in order to catch exceptions as they are thrown, you can make the debugger break automatically whenever the happens under Tools/Exceptions.
You can use this if you are using older IDE's (anything pre-2012)
Programmatically apply / deactivate breakpoints in Visual Studio
Unfortunately they removed the macros from the newer IDE's.
There are extensions you can download and one of them allows you to modify a *.js file. Issue is going to be converting what the gentleman wrote in the other post to have it read properly.
For now I'm just using System.Diagnostics.Debugger.Launch(); it's just a pain and it would be awesome if someone could translate that file over.
In Visual Studio 2008, after debugging about 1-2 minutes, when I press F10 (Step Over), the debugger hangs and Visual Studio freezes for 5-10 seconds and then go to the next line. Then whatever I do (F10, F5, F11, etc), the debugger continues the execution as if i pressed F5 and all my forms that I was debugging close. I always have to restart the application.
It is very hard to reproduce and it does not occurs every time I want to debug something. Does anyone has a solution ?
EDIT : I've managed to reproduce my problem with the following code :
static void Main(string[] args)
{
XElement e = new XElement("root");
Test(e, 0);
}
static void Test(XElement parentElement, int i)
{
if (i < 1000)
{
XElement element = new XElement("element");
parentElement.Add(element);
Test(element, ++i);
}
}
You need to put a conditional breakpoint on the line "XElement element = new XElement("element");" with the condition "i == 999". Then start the program, wait 2-3 seconds and put normal breakpoint on the line "parentElement.Add(element);". Now VisualStudio freezes and it is impossible to debug. In a WinForm application, it closes all the forms that are open after pressing F10.
But I found that if I disable the debug option "Call string conversion function on objects in variables windows" in "Tools -> Options -> Debugging", I can debug. It is slow but at least VisualStudio doesn't freeze. Does anyone know why it is doing this? Because I don't want to disable this option, it's really annoying to debug without it.
I also noticed that if I only put a breakpoint at the end of the main method, the code runs really fast compare to having a conditional breakpoint in the recursive method.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file can get corrupted.
If this does not solve the problem, then you have something else going on, such as threading issues, excessive memory fragmentation, garbage collection issues, dispose/finalize issues, and so on.
I found the answer to this question on another Stackoverflow thread. There's a MS hotfix for this issue.
I've found that I get slowdowns like this whenever I have added remote unc shares that don't exist to the list of symbol directories.
Try going to Tools -> Options -> Debugging -> Symbols and make sure that all of the directories in that list actually exist.
I have no idea how that would cause your program to continue after that point however.
Not sure I've ever run into this, but if I were you, if you haven't, delete your bin folder, and rebuild your project. Then run a clean solution to be safe. Sometimes, funky things can happen with your PDB's getting out of date -- so you need to clear them out.
Also, if your calling outside assemblies, remove them and reattach them to make sure you have the most up-to-date assemblies.
I have had this exact same problem just as you described. The MS Hotfix addressed the issue and now I install this hotfix whenever I do a fresh 2008 VS install.
Please download the fix from this link
http://support2.microsoft.com/hotfix/KBHotfix.aspx?kbnum=957912
I know this is an old thread but this occurred when debugging an Excel add-in in my case.
Problem was that my breakpoint was in a background thread and in my watch window I had an old check on the ActiveWorkbook in Excel. That call just like many others should only occur on Excel's main thread.
Once I removed that watch, it debugged just fine again.
I've installed Visual Studio 15.9.0, Preview 3 and created a project using the new platform support for C++/winrt. The project runs fine until I set a breakpoint. When the break is hit VS tells me "You need to find debuggerutils.h to view the source for the current call stack frame" It tells me this file was originally at onecore\com\combase\inc\debuggerutils.h, though it doesn't tell me the path to onecore. Search can't find such a file. Does anyone know how to find that file or install it? I had just assumed that VS would automatically include debugging capability.
[Update] Appears it is not the setting of a breakpoint but a bug causing a break before that. But I'm still mystified by the error message.
Someone asked this question on github's WinObjC issues:
https://github.com/microsoft/WinObjC/issues/2931
From the discussion:
edvv commented on Nov 22, 2019
Ah, now I remember what this means: "This is a false message. What really happened is that your app silently terminated (maybe by a console abort(), i.e.: crashed ) and when the app failed to launch (aborted) the front end gave that message. You need to look at the Windows Console window in VS while in debug mode."
My project has both client and server components in the same solution file. I usually have the debugger set to start them together when debugging, but it's often the case where I start the server up outside of the debugger so I can start and stop the client as needed when working on client-side only stuff. (this is much faster).
I'm trying to save myself the hassle of poking around in Solution Explorer to start individual projects and would rather just stick a button on the toolbar that calls a macro that starts the debugger for individual projects (while leaving "F5" type debugging alone to start up both processess).
I tried recording, but that didn't really result in anything useful.
So far all I've managed to do is to locate the project item in the solution explorer:
Dim projItem As UIHierarchyItem
projItem = DTE.ToolWindows.SolutionExplorer.GetItem("SolutionName\ProjectFolder\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect)
(This is based loosely on how the macro recorder tried to do it. I'm not sure if navigating the UI object model is the correct approach, or if I should be looking at going through the Solution/Project object model instead).
Ok. This appears to work from most UI (all?) contexts provided the solution is loaded:
Sub DebugTheServer()
DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate()
DTE.ActiveWindow.Object.GetItem("Solution\ServerFolder\ServerProject").Select(vsUISelectionType.vsUISelectionTypeSelect)
DTE.Windows.Item(Constants.vsWindowKindOutput).Activate()
DTE.ExecuteCommand("ClassViewContextMenus.ClassViewProject.Debug.Startnewinstance")
End Sub
From a C# add-in, the following worked for me:
Dte.Windows.Item(Constants.vsWindowKindSolutionExplorer).Activate();
Dte.ToolWindows.SolutionExplorer.GetItem("SolutionName\\SolutionFolderName\\ProjectName").Select(vsUISelectionType.vsUISelectionTypeSelect);