I'm working on a project in Silverlight and somewhere an exception is thrown. I'm not concerned with fixing the exception... I just want to find it.
Instead of Visual Studio popping up and showing the the line where the exception happened, I instead get a little window labeled "Just In Time" which mentions an error 4004, a managed runtime error. It asks which debugger I want to use to solve the problem. But, it only provides one option: a new instance of Visual Studio. If I try to accept its proposal, the new instance complains that a debugger is already attached.
Why doesn't the instance of VS which built the program and is already running catch the exception and show me where it is?
That is strange behavior. The first thing I would do is change a few settings
Disable Just My Code
Enable native debugging
Break on first exception thrown
This should help you narrow down the place where the exception is occuring.
Disable Just My Code
Tools -> Options
Debugger
Uncheck "Enable Just My Code"
Enable Native Debugging
Right click on the project and select properties
Go to the Debug Tab
Check "Enable Unmanaged Debugging"
Break on first exception thrown
Debug -> Exceptions
Check "Throws" for Common Language Runtime Exceptions
Silverlight has a habbit of swallowing exceptions. I call this "silent failure" and have found it very expensive and frustrating. When working with Silverlight do everything you can do expose exceptions, e.g. binding failures.
Have a look here: http://msdn.microsoft.com/en-us/library/cc189070%28v=vs.95%29.aspx
Also there is a setting on elements to have them visualise binding failures but I forget what it is as I'm not working in Silverlight any more.
Looks like the problem is the type of debugging. In your project properties make sure you enable Silverlight debugging. In your website project right click, go to properties, then on the 'Web' tab at the bottom there's a section called Debuggers. Make sure that Silverlight is selected.
Sometimes the JS debugger is attached to the IE process, which means that there's a debugger attached, but it's simply not the debugger you want. I think this might be the cause of this problem.
Hope this helps.
Miguel
click debug, choose exceptions, mark common language runtime exceptions as thrown.
I had the same problem and it fixed the problem for me
Related
I 'm working with Visual Studio 10, my project is with monorail and I get a lot of error on my ".vm" files, those errors are not pertinent, and I don't want to see them anymore is there a way.
I tagged this ask with castle monorail, because I guess some users could have the same problem. But I'm sure it's a problem more general.
I get the same problem sometime with aspx or xslt visual studio check the file's validity ( with the own rules) and report the errors in the error list
New Answer:
Unfortunately, these errors are emitted by CVSI, and can be ignored - I agree they're a bit annoying. I've found that they go away if I re-open the solution. Not a great answer, but it's the only one I've found that works.
Previous Answer:
Are these errors ObjectDisposedExceptions?
What are your settings WRT exception handling in VS.NET? Go to Debug -> Exceptions in the menu. If there's a check in the "Thrown" column, then you need to open that up and then find System.ObjectDisposedException and then deselect it.
If you're looking to still break on deselected exceptions which are thrown elsewhere, you're out of luck, as this isn't currently supported by VS.NET.
I have a web application where I attach the visual studio debugger. I am trying to locate a specific problem and it keeps stopping on exceptions I do not care about.
I have managed to uncheck the .NET exceptions by going to Debug->Exceptions. However when I add the name of the exception from the third party tool, I cannot keep it from stopping on those exceptions.
What am I doing wrong? The exceptions dialog wouldn't have a place to add exceptions if they didn't expect you to add your own, would it?
You must add the fullly qualified name of the Exception (ie, include the namespace) when you add an exception to the list.
You can do that by going to Tools -> Options -> Debugger -> General -> "Enable Just My Code". This will cause debugger to stop at only your code.
The answer of Omer Raviv is right: Specify the fully qualified name of the exception!
Just to make clear how the Exception-Window in VS 2010 should look like, here is a screenshot of a user defined exception that will not be stopped at while debugging:
When there is an exception thrown in my program, and it is unhandled, I expect the debugger to break in my program and show me what the problem is. This doesn't happen. Instead, my program simply exits, and debugging stops.
If I look at the debugging output, I can see my exception:
A first chance exception of type
'System.NullReferenceException'
occurred in System.dll
I am using Visual Studio 2010, Visual Basic, writing a simple WinForms app. The code doesn't matter in this case... it happens with any exception that I've seen so far.
I've read a lot online about doing to the Debug menu and clicking Exceptions and enabling "break on unhandled user exception", but I don't see this option. I think this advice is for VS2008, and is no longer applicable.
I should also note that I'm not running any unit tests. I have never set them up. However, I have read that perhaps the unit tester is swallowing my exceptions?
Please advise me on how to change the behavior of Visual Studio, so I can track down these unhandled exceptions.
Thank you for your time.
The item may not be in the menu, which you can fix by customising the menu and adding the item to the debug menu.
You should also be able to get to the exceptions menu using CTRL + ALT + E
You need to tick the box in the "Thrown" column for Common Language Runtime exceptions (CLR)
i had the same issue. i opened the exceptions dialog and clicked the "Restore the list to the default settings" button and now it breaks on unhandled exceptions correctly.
there's probably a bug with upgrading from 2013.
I would like Visual Studio not to enter the Debug mode when it picks up a specific exception I define (i.e. BusinessException is this case). This is because I have a specific global error handler that will then present this to the user.
Is there a way to avoid the VS debug pickup for this exception (so I'll go straight to seeing my exception handler dialog) but for other exceptions to still be handed by the VS debugging.
I'm using VS2008 for a C# project (winforms).
thanks
EDIT: Further clarification - currently I see (a) VS pick them up and show them in the debugger, and after I hit continue I see (b) them in my custom exception handler. What I want to do is disable step (a) for certain types of exceptions. I know that I can disable totally in VS by going to the settings and uncheck "Enable just my code", however that's not quite what I want.
May be you can try DEBUG Preprocessor
http://www.csharphelp.com/2005/12/c-languages-preprocessor-directives/
Is there a good way to debug errors in the Visual Studio Designer?
In our project we have tons of UserControls and many complex forms. For the complex ones, the Designer often throws various exceptions which doesn't help much, and I was wondering if there's some nice way to figure out what has gone wrong.
The language is C#, and we're using Visual Studio 2005.
I've been able to debug some control designer issues by running a second instance of VS, then from your first VS instance do a "Debug -> Attach to Process" and pick "devenv".
The first VS instance is where you'll set your breakpoints. Use the second instance to load up the designer to cause the "designer" code to run.
See Debugging Design-Time Controls (MSDN).
It has been a pain in 2005 and still is in 2015. Breakpoints will often not hit, probably because of the assemblies being shadow copied or something by the designer(?). The best you can do is to break manually by introducing a call to Debugger.Break(). You may wrap it into a compiler conditional as so:
#if DEBUG
System.Diagnostics.Debugger.Break();
#endif
int line_to = break; // <- if a simple breakpoint here does not suffice
I have had this happen many times and it is a real pain.
Firstly I'd suggest attempting to follow the stack trace provided by the designer, though I found that often simply lists a bunch of internals stuff that isn't much use.
If that doesn't work then try compiling and determining the exception from there. You really are flying blind which is the problem. You could then try simply running the code and seeing what exception is raised when you run it, that should give you some more information.
A last-gasp approach could be to remove all the non-generated code from the form and gradually re-introduce it to determine the error.
If you're using custom controls you could manually remove the generated code related to the custom controls as well if the previous method still results in an error. You could then re-introduce this step-by-step in the same way to determine which custom control is causing the problem, then go and debug that separately.
Basically as far as I can tell there's no real way around the problem other than to slog it out a bit!
I discovered why sometimes breakpoints are not hit. In the Attach to Process dialog, "Attach to:" type has to be "Select..."'d.
Once I changed to "Managed 4.0, 4.5", breakpoints for a WinRT application were hit. Source: Designer Debugging in WinRT.
Each one is different and they can sometimes be obscure. As a first step, I would do the following:
Use source control and save often. When a designer error occurs, get a list of all changes to the affected controls that have occurred recently and test each one until you find the culprit
Be sure to check out the initialization routines of the controls involved. Very often these errors will occur because of some error or bad dependency that is called through the default constructor for a control (an error that may only manifest itself in VS)
You can run a second instance of VS and attach it to the first instance of VS (Ctrl+Alt+P). In the first instance set the breakpoints, in the second instance run the designer, and the breakpoint will fire. You can step through the code, but Edit-and-Continue will not work.
For Edit-and-Continue to work, set you control library's debug options to run a VS with the command line argument being the solution filename. Then you can simply set the breakpoints and hit F5. It will debug just like user code! As a side note, you can do this will VS and Office add-ins also.
This worked for me for Visual Studio 2022:
I opened a second Visual Studio instance
In the second instance I clicked Debug -> Attach to Process...
I selected DesignToolsServer from the process list
More details: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/walkthrough-debugging-custom-windows-forms-controls-at-design-time?view=netframeworkdesktop-4.8