I'm trying to debug a variable in my code. I'm using a break point but when my mouse goes over any of the variables present in "locals" it the locals window suddenly closes down without any warning at all. Also a lot of the lines are empty. Is this a bug?
Your watch window contains an error message "Function evaluation was aborted." That probably means one of the properties displayed has an infinite recursion, like so:
readonly bool isSigned;
public bool IsSigned { get { return IsSigned; } }
Fix the infinite recursion and the problem should go away:
readonly bool isSigned;
public bool IsSigned { get { return isSigned; } }
You can catch the StackOverflowException when it is thrown using Visual Studio by selecting from the menu bar "Debug" -> "Exceptions" -> "Find..." -> type "stackoverflow" -> check "Thrown" for System.StackOverflowException -> "OK"
If "Exceptions" does not appear in the "Debug" menu of your version of Visual Studio, follow the instructions for To add the Exceptions command to the Debug menu for your VS version.
update Just checked, looks like Visual Studio won't break on the StackOverflowException if it's thrown in the watch window. If you can't find the bug by code inspection, what you have to do to find the infinite recursion is to delete everything in the watch window, then add a line or lines in your actual code to access the properties that might be causing the recursion, checkaoprimeiroradiobuttonG in your case, e.g.
var tmp1 = checkaoprimeiroradiobuttonG;
var tmp2 = desactivabetaoadicionalG;
In that case the recursion should get caught.
Related
I get the following exception (in Dutch, English translation follows in the text) which breaks my debugger when I press 'OK' it stops the debug session and closes the application:
Translated in text:
---------------------------
LerTemperaturaWPF.vshost.exe - Application Error
---------------------------
INTERNAL ERROR:
Unhandled exception in Debugger::HandleIPCEvent.
Event ID=0x246.
Exception code=0xc0000005, Eip=0x68fbaeca.
Process ID=0x1094 (4244), Thread ID=0x10a4 (4260).
---------------------------
OK
---------------------------
This happens if the first time the debugger breaks are inside a certain piece of code:
private void PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
// Set value of property, only when the long editor is selected (no optionlist item is selected)
if (this.Editor.SelectedItem != null)
{
if (this.Editor.SelectedItem as OptionForList == null)
{
this.Editor.SelectedValue = ((Management.Property)this.Editor.SelectedItem).Value;
this.Editor.SelectedIndex = 0;
}
}
}
It happens when I place the breakpoint inside the 2nd if statement, before the second if statement (where ever I place it). It gives me no problems.
If I make sure the first break the debugger has is before this code and afterward it hits a breakpoint in this code there are no problems either. The debugger must have broken before getting to this code. Now I do not think it has anything to do with this code (90% certain).
The property changed is a user control and somehow I think the debugger can't handle the user control properly? maybe?
Has anyone seen this behavior before and know how to fix this? do I need to turn off (or on) some of the debug settings??
Right click on the project/solution -> Properties -> Debug -> Check "Enable native code debugging".
(1) On the Debug menu->Windows->Exceptions, and enable all Thrown check boxes. Debug the application, it will show you the actual and detailed errors in a message Box.
(2) Right click on the project/solution -> Properties -> Debug -> Uncheck "Enable visual studio hosting process".
(3) Please also change the Platform target (X86/Any CPU/X64), re-compile the app, debug it again.
(4)Tools > Options > Debugging > General > "Use Managed Compatibility Mode" checkbox.
All answers described here do not guarantee 100% cure. What I am doing as a workaround is that just stepping over to the next line while debugging.After that I can see the value of that variable in the watch on mouse hover. (In my case, stepping over to next line does not change value)
I work with several code pages and Stored Procedures during day. I look for an easy way to stop visual studio while debugging, so database changes rollback. Since I work with several pages, i don't want to add code for this in my pages or for every SP I use. Is there a shortcut or a command i can use in immediate window?(I am open to other solutions - these are the ones came into my mind) If I can manually throw an exception(not written in code, in immediate window may be, it may work.)
I think the best thing is to use TransactionScope class for this.
Just wrap your db calls inside
using (TransactionScope scope = new TransactionScope())
{
// Invoke your database calls
scope.Complete(); // Put a break point here and stop the program when the break point is hit.
}
I usually kill the w3wp.exe process using Process Explorer. Alternatively, you can drag and drop the "yellow mark" in the debugger to a point after the commit so that the commit is skipped. I also sometimes set a variable to null and induce a crash that way.
If you want to throw an exception, you can do it using Immediate Window, after hitting breakpoint.
The problem is, you can not use in Immediate Window something like:
throw new ApplicationException("Forced exception");
But you can create the method, and then launch it from Immediate Window
public static void ForceAnException()
{
throw new ApplicationException("Forced exception");
}
In immediate window:
ForceAnException();
EDIT:
So maybe try this:
var throwEx = false;
if(throwEx) ForceAnException();
And change in immediate window throwEx to true, before condition is checked...it should work...
Normally I want the debugger to break on ArgumentOutOfRangeException.
But within my try catch(ArgumentOutOfRangeException) that exception is already handled and so I want the debugger to not break.
I tried the DebuggerStepThrough attribute, but it still breaks.
You can do this by setting the debugger to break on user unhandled exceptions.
Go to Debug -> Exceptions, Common Language Runtime Exceptions, de-tick (uncheck) the Thrown box. Of course you can get very precise with what you want to break on by drilling down into that list. Be aware that this setting takes effect across the whole solution, you can't set it per class or method. If you do want to be more selective per method, then consider using compile directives to not include that bit of code during debug time.
As for the DebuggerStepThrough attribute, that is to prevent breaking on break points, nothing to do with breaking on exceptions.
You should check your visual studio isn't set to break on all exceptions
On the Debug menu, click Exceptions.
In the Exceptions dialog box, select Thrown for an entire category of exceptions,
for example, Common Language Runtime Exceptions.
Microsoft Visual Studio Help
There is a way. First disable debugging code that is not yours. Go to Tools > Options > Debugging > General > select "Enable Just My Code (Managed only)". Now tell the debugger that this one function is not part of your code with DebuggerNonUserCodeAttribute:
[System.Diagnostics.DebuggerNonUserCode()]
private void FunctionThatCatchesThrownException()
{
try
{
throw new ArgumentOutOfRangeException();
}
catch (ArgumentOutOfRangeException ex)
{
//...
}
}
If an exception (some other than ArgumentOutOfRangeException) gets out of the function debugger will catch it as usual, but the location of interception will be where the function is called.
I've followed this advice to get debugging working for NUnit tests.
http://www.blackwasp.co.uk/NUnitCSharpExpress.aspx
However, i have several tests that do Assert.Throws<...>, which causes the debugger to break when the exception i'm testing for occurs, when really i want it to break if an exception occurs outside of those calls.
How can i get the debugger to ignore exceptions caused from within these kinds of methods?
EDIT: I've event tried the below, which doesn't work!
[Test]
public void InstanciatingWithNullParameterThrowsException()
{
try
{
Assert.Throws<ArgumentNullException>(() => new CachedStreamingEnumerable<int>(null));
// This still throws and stops be being able to debug tests called after this one
}
catch
{
}
}
Here is what worked for me (although in Visual Studio Professional, not Express, but I guess that should not matter).
Bring up the "Exceptions" Dialog as suggested by Ninjapig.
Click on the Add... Button, to open the "New Exception" dialog.
Select "Common Language Runtime Exceptions" in the drop down box
In the Edit box enter "NUnit.Framework.AssertionException".
Click OK to close the "New Exception" dialog.
Back in the "Exceptions" dialog make sure that both checkboxes (Thrown and User-unhandled) are unchecked.
Now, the debugger should completely ignore a NUnit assertion failure (i.e. a thrown, caught or not, NUnit.Framework.AssertionException).
UPDATE: This will only prevent from breaking into the debugger, it cannot ignore the exception itself; i.e. it will not alter the actual program flow. Appart from changing or replacing or encapsulating the Assert-calls in try-catch blocks, I don't think there is anything that can achieve that (at least not automatically).
I'm uncertain if VS2010 Express has this option, but you can choose the exceptions to break on .
Go to the 'Debug' menu, then select 'Exceptions'
and from here you can select what exceptions to break on
I've ended up referencing nunit-gui-runner.dll and invoking it like
NUnit.Gui.AppEntry.Main(new string[] { Dll });
This brings up the NUnit gui. I can then run the specific test i'm interested in.
I had the same problem. Although your original approach (without the need for a try...catch block) works for most exception types, ArgumentNullException doesn't work. I fixed it like this:
[Test]
public void InstanciatingWithNullParameterThrowsException()
{
bool isArgumentNullExceptionThrown = false;
try
{
new CachedStreamingEnumerable<int>(null);
}
catch (ArgumentNullException)
{
isArgumentNullExceptionThrown = true;
}
Assert.That(isArgumentNullExceptionThrown);
}
It's not as elegant, but it does seem to work.
I put a breakpoint to the last line of code. Breakpoint is disabled. Why?
It looks like the code is excluded by some condition. The constructor of TraceSource works, and I can verify the object is OK and all listeners are OK. It really looks bizarre. I stop on int a=1; and then debugger skips TraceInformation by ignoring it. The configuration is DEBUG x86.
public TraceSource _fixTraceSource;
_fixTraceSource = new TraceSource(_configSection.TraceSourceName);
int a = 1; // dummy line to set breakpoint
_fixTraceSource.TraceInformation("FIX -> toAdmin Message: {0}", message.ToString());
TraceInformation is marked:
[Conditional("TRACE")]
So you need the TRACE symbol defined at compile time for it to be included. This is usually by checking the "Define TRACE constant" box in the project properties page (it is enabled by default for both Debug and Release profiles, so somebody has unchecked it at some point).