Is there a way to break the debugger when assertion is false and running the application using Visual Studio debugger. Earlier when I was debugging Windows application I would get an exception and the debugger would break, but now on Smart Device an assertion failed window is showed with stack trace, but I would also like to see variable values etc.
Stupid me, the solution was simple. When the window pops out, press pause in debugger :)
Not sure about VS 2008, but in at least 2010 and later, you can go to Debug/Exceptions (Ctrl-Alt-E). Click the "Add" button, choose "Common Language Runtime Exceptions", and type:
Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException
and hit "OK". It will now appear on the list, make sure you check the checkbox in the "Thrown" column. You will now get a break on any assert failure.
Updated:
screenshot from VS 2017
In addition to Vinay's solution, you can start the debugger for a specific process by calling
Debugger.Break
In your case you could do it every time the listener receives a failure message.
It seems that you can attach the Debugger when assertion fails to see other details - see this article: http://blogs.msdn.com/b/davidklinems/archive/2005/08/29/457847.aspx. Its quite dated but perhaps still applicable.
Related
I'm looking for a little help regarding the win32 exception "error creating window handle".
From time to time our program (WinForms - C#) throws this exception and sometimes the windows even freeze, so that the users have to kick the process to be able to work again.
From the many other threads regarding this problem, I know what I should be looking for, but not extactly where as our program is quite big. So I was hoping that there might be a way to restrict the codelines I have to check... Are the any tools, which can help with this exception?
Short update: I solved the problem.
ProcDump didn't help me much, because I got pretty the same information from our logfiles. However, I was able to reproduce the error in our development environment. Thanks to debugger and displaying the user-objects count in the taskmanager I found the source of the memoryleak - an undisposed texbox which was created dynamically.
Thanks again for the tips!
If this issue happens inside the debugger, you can set the debugger (I will assume Visual Studio as you're using C#?) to break on throwing an exception. In your case you would want to set an exception breakpoint on (I think) System.ComponentModel.Win32Exception.
Again assuming Visual Studio as your IDE, on the "Debug" menu is an "Exceptions..." item. This allows you to tell the debugger to break when specific exceptions are a) thrown, or b) unhandled.
Under Common Language Runtime Exceptions, expand System.ComponentModel, and enable the checkbox in the Thrown column for System.ComponentModel.Win32Exception.
Then just carry on as normal. If during debugging the exception occurs, it should break into your program and allow you to see where it's happening.
Edit: If you can't reproduce the problem on your development machines, see if you're able to set up the target machine to produce a dump when a crash occurs. One way of doing this is to run ProcDump. Run it with the -e parameter to create a dump in the event of an exception. Then you can analyse this back at the ranch.
When I run my code within VS, when I enter certain methods, upon ending the application (closing the form) been debugged, VS does not end the debug session automatically forcing me to end it manually.
This doesn't always happen, the results are consistent with certain windows / classes loaded when the application is run within VS.
I want to know why this may be, I'm assuming its an indication of a file not been closed in my managed code or 'something' like that.
Why might this occur and how can I trace and fix it?
This would happen if your code keeps running after closing the window.
Pause the debugger after closing the window to find out what it's doing, then modify the code so that it stops running when you close the window.
On Debug menu, click "Detach All".
Hope that helps!
EDIT
Follow, SLak's advice, as that will go after the problem. My solution may only fix the symptom. I will leave the answer here just in case it is helpful to you though.
Good luck!
I am getting the following error message while running .net 3.5 applciation
Your step-into request resulted in an automatic step-over of a
property or operator.
This behavior can be overridden in the context menu for the line being
executed by choosing 'Step Into Specific' or by unchecking the option
'Step over properties and operators'.
Do you want continue being notified when an automatic step-over
happens?
What does this error message mean?
VS2017 and VS2019:
Tools > Options > Debugging > Uncheck "Step over properties and operators > (Managed only)".
It is not an error message as such. The IDE is telling you that tracing for some of your code is being skipped during debugging due to the current settings. If you want to be able to trace into the code, change the settings as described in the message.
You can change this behavior by going to: Tools -> Option -> Debugging.
The setting for this in VS2010 is under: Tools -> Option -> Debugging (near the middle)
To be more specific: the option to enable in Visual Studio 2010 is:
Tools->Options->Debugging->General->Enable property evaluation and other implicit function calls
As answered by other people this is an informational message from Visual Studio telling you that it could have stepped into a line of code but rather stepped over it due to current dev environment settings.
There are three ways to change this behaviour in VS2012:
Change the settings: Tools->Options->Debugging->General->Step over properties and operators
OR
Right click on the line of code to get the context menu. Then untick: Step over properties and operators
OR
Select 'Step into Specific' in the right click context menu which will ask you which specific function you would like to step into. It will list all the properties/functions involved in the current source line.
In Visual Studio 2013: right click on the line that caused the message to pop-up.
This will bring up the context menu.
Uncheck the option: Step over properties and operators.
Other posts have the correct answer, which state that you can change the option in Tools > Options > Debugging > Step over properties and operators (Managed only) in Visual Studio. I wanted to add an image from the Options dialog for those who are visual. Uncheck the property if you want to perform Step Into (F11) without automatic Step Over (F10).
The reason that we get this prompt is: that we may have created properties or operators in our classes, and when, during debugging, we reach that line of code, it is stepped over (like the effect of F10 ) instead of stepping into ( the actual effect of F11 )
e.g., this line of code,
having pressed F11 here, resulted into effect of pressing F10
So Visual Studio notifies us..and gives this beautiful, well illustrated message, which I could only understand when I read the following blogpost
Credits: AutoStepOver a blog post
The other answers are suffient for turning the feature on or off. Lacking is the insight as to WHY one would want to do one or the other.
For beginning C# programmers their property method is a simple {get,set}. Since this code is not worth viewing we check the box "Step over properties...".
However, when your property settings become more interesting, you may want to step into the property method to ensure it's behavior is correct. Once you tell the IDE "Don't bother me any more", then later when your "step into" fails for a complex property method, now it's your fault.
My recommendation would be either to remember how to switch the option on and off for future debugging sessions or uncheck the "Step over..." setting and learn to toggle between F11 and F10 as appropriate.
Another option is never to use "step into". Just set a breakpoint in the method/property/operator you want to debug and click the step (F10). This way you step into only the methods you are debugging.
I´m coming from a PHP background where my debugging "tools" are basically echo, var_dump and exit. While I know the importance of debugging, I never tried to use/learn a debugging tool.
Now I´m learning C# and I think I can´t really program without an extensive knowledge of this area.
So my question is: where can I learn what is and how to do debugging? I know what is a breakpoint (conceptually), but how to use it? How to use Step into and Step over? Basic things like that.
As a related question, there is anything like var_dump in C# (Visual Studio), where I can inspect any object.
I find very difficult and painful to do a foreach for every array/list to see the contents, specially now that I´m still learning the language.
Microsoft has an extensive guide on C# debugging in Visual Studio that might be helpful. VS has a lot of powerful debugging functionality; for example, rather than doing a foreach to see the contents of an array as you were describing, you could set a breakpoint (pausing the execution of the program) and select the variable you wish to see the contents of (array or list or whatever) and see what it contains, without having to write any extra code. Step Into and Step Over can be used to continue execution of the program but only incrementally so that you can continue to see how variables change, where the flow of execution currently is, etc.
This has been covered earlier on StackOverflow:
Best Visual Studio 2008 Debugging Tutorial?
So, your compiled applications can be run in a "debug" mode from which visual studio can monitor the internal workings of the application and even control it.
A break point can be placed just about anywhere in your code by clicking to the far left of the line (kinda in the margin of the visual studio text editor). When that line of code has been reached, the visual studio debugger will actually pause the execution of your program and bring you back to the editor where you can literally hover over a variable or object or whatever and see everything about it.
There is also a "Locals" window available that will give you the break down of all of your locally scoped items - this should pop up by default at the bottom of your screen when debugging.
In debug mode you can navigate the execution of your code line-by-line
F10 will continue with the next line of code.
F11 will attempt to drill down into what ever functions are on the current line of code
Ctrl-D will bring up a "Quick Watch" window giving you all information about the currently selected variable/object.
Once you are in debug mode there are tons of things you can do - in some cases you can even edit the code as you go.
The easiest way to get into debug mode is to use the little "play" button up at the top of visual studio - and when a break point is reached it will enter debug mode and highlight the currently executing line of code.
You can also hit F10 from the editor and your application will be started and paused on the very first line of code.
By comparison, in PHP, you had to actually write "debugging code" into your application - using Visual Studio you can actually monitor the execution of your code without adding a thing to your existing code.
I hope that gets you started.
You might want to also read up on your IDE a bit to. There is a metric ton of stuff in visual studio that will help you navigate your code in ways you never imagined in most PHP editors.
If you've already downloaded Microsoft Visual Studio, you'd might want to check out the Visual C# Express Library available for free over at: http://msdn.com/express/
It's located down the bottom of the page and is very useful. It contains pretty much every answer you might be looking for as a beginner to the C# Language. ...Welcome to C#, my friend :-D
So my C# program is quitting/disapearing/closing/crashing suddenly even in debug mode.
How can I make it break/pause/stop so as to find out where caused it?
Set a breakpoint (by clicking the left of the line numbers--it's a red circle) that you know is before the point where it crashes and then step through it (using F8). The last statement that you're on is the one that it's crashing at.
If you're in Visual Studio you can enable "Stop when an exception is thrown" - go Debug->Exceptions. This is often quite useful for detecting the exact source of the problem.
You may be able to learn more by using an unhandled exception handler. However, if you're in debug mode you should be able to see it by default. Check your Debug: Exceptions settings to make sure you haven't accidentally stopped reporting them in debug mode.
as Eric suggested try going through step through it... also always place try/catch in your end caller apps in order to manage exceptions.
Also, it may be worth checking your code for occurrences of Environment.FailFast, just in case someone tried to be (too) smart.
You can hit F10 to start debugging your project. This will put a breakpoint right at the beginning of your Main method, then you can go from there stepping through the code with F11 to see at which points it crashes.