I am a newbie learning C# after C++. VS2010.
Trying to debug my code, I come across weird empty lines in the "locals" frame.
The debugger just quits after a few seconds of me staring at these empty lines.
Please check it out: http://pastebin.com/KZbfy8JF
Thanks.
I've spent at least 3 hours looking for solutions and playing around with code to no avail.
The Value property getter and setters are infinitely recursive - change them to this:
public T Value { get; set; }
Already answered (Value get/set) but here is a tip:
In VS.NET, press CTRL+ALT+E to open the Exceptions dialog (depending on your profile selected in VS.NET, it may be under Debug->Exceptions as well). This lets you break when certain exception types are thrown, as opposed to the full stack unwinding and the program ultimately crashing.
For "Common Language Runtime Exceptions" check the "Thrown" checkbox, hit OK, then run your program. The execution of your program will stop at the point of exception, which should make it much more obvious.
In your case, the program breaks on your property. To see more, open the Call Stack wndow (Debug->Windows->Call Stack or CTRL+ALT+C) to see the full stack and you'll see your property is just about the only thing in it.
Ok generally, stack overflow would mean that you're recursing without going back. I don't see however where you do that. What I'd do would be to insert a Console.WriteLine statement in a few strategic places to see which lines are executed and how often. For example, on the beginning of Insert, and in the inner loop. This should give you (and us ;) a bit more information.
Related
At some point while developing my C# application, the following started to appear in the VS Output pane whenever I create an OpenFileDialog:
First-chance exception at 0x75A6C42D (KernelBase.dll) in (myapp).exe: 0x000006BA: The RPC server is unavailable.
I've been maintaining this application for years, and definitely never saw this before, so I started rolling back in SVN to determine when it began.
Bafflingly, revisions in which it occurs & doesn't occur seem to be inconsistent; if I go back sufficiently far it never happens, but there's an "area" when I can check a revision, it won't happen, I'll check another revision, it will, then I'll return to the first, and this time it suddenly will. In other words, I can't seem to reliably pinpoint when it started happening.
To illustrate this, here's an excerpt of my tests, indented for clarity. Numbers are revisions. For each test, I "update to revision" and do a full rebuild.
3977: Exception. This is the most-recent revision.
3839: OK. Since it didn't happen, I'll start working my way back up to see when it starts
3843: OK
3852: OK
3890: Exception. So it started between 3852 & 3890.
3852: Exception. Huh?? I JUST tried 3852, and last time it didn't happen!
3778: OK. Going back this far, I've never seen it happen.
3852: Exception. I guess I'll start working my way BACK to see when it stops.
3828: Exception
3810: OK
3828: Exception. Just making sure.
3810: OK. Just making sure again.
3828: OK. What?? 3828 showed the exception last time I tried!
3852: OK. (but previously it showed the exception)
3890: Exception
I'm aware that I can just tell VS not to break on these types of exceptions, and ignore them. But as mentioned, after years of working on this software, I've never seen it once - so I'd like to determine exactly when and why they started, rather than just turning a blind eye.
This has nothing to do with your project. When you use the shell dialogs, like OpenFileDialog, you load Explorer into your process. Which comes with a lot of baggage, you also get all of the shell extensions loaded. The kind that customize Explorer, they work just as well in the dialog.
Misbehaving ones are quite common. Programmers tend to use the quirkier kind. Any mishap in such a shell extension is now visible to you, the debugger tells you about it.
So, nothing actually went wrong, the exception was caught and handled. Explorer implements counter-measures against bad shell extensions destabilizing it and automatically disables them. So you just have a lame-duck shell extension that doesn't work, low odds you'd notice since it probably hasn't worked for a while.
The debugger can tell you which one is bad. Enable unmanaged debugging and tick the Thrown checkboxes in the Debug + Exception dialog. The debugger will now stop when the exception is thrown. You won't see any source code but you can look at the Call Stack debugger window for hints. It displays the name of the DLL that contain the bad code somewhere on the stack, below the Windows DLL functions. The name ought to give you a hint which one is the troublemaker. SysInternals' AutoRuns utility is excellent to disable them.
This might not be possible but it would be hugely helpful with debugging. Sometimes random bugs occur when the program is running. I'd like to be able to type something in (a string) and then it would grab a variable with the name of that string and return its value.
int mainNumber = 89;
Input: retrieve mainNumber
Output: 89
Is something like that possible? I don't want to have to create debugs for every single variable I have on the off chance something could go wrong. I know I could wait for the bug to occur, stop the program, throw a debug in and wait again, but this would be faster.
You need to learn about the variable, watch and immediate windows of Visual Studio.
Would the 'immediate window' be what you're looking for? http://msdn.microsoft.com/en-us/library/f177hahy(v=VS.100).aspx
I would suggest reading up on Trace and Debug in .NET. You can typically switch Trace and Debug statements off and on from a program's config file, thus not affecting your runtime performance unless you want these dumps. Then you can sprinkle Trace.Write(...) and Debug.Write(...) statements in your code to provide the output you desire.
Based on your comment, it sounds like you're going to need to do some research. Here are some things to consider/try:
What is the bug? Is an exception being thrown, is data not coming back correctly, etc. Identify what it is that you're trying to root cause.
Do you know under what circumstances the bug happens? Since you said random, chances are you don't yet know the answer to that.
Are you able to reproduce or see the bug in a test environment?
One option that I've done in the past is to add logging (usually to a text file) to the application in question. I put in logging in the areas of interest, and timestamp the entries. Grab enough information so you can adequately identify the actions that are occurring (before/after states of variables/objects, any supporting information that identifies the action, etc).
When a bug is reported (or reproduced), if the reporter gives enough information (i.e., time, what they were doing, other things particular to the app or what they were doing) you can look in your log files and see what was going on.
Once you have that information, you can either identify the root cause, or narrow it down to a more specific area and focus your efforts there.
It can be something of an iterative process, depending on how big the app is and how large the area of possible problems can be.
The title may be a little confusing so I'll explain. Say you had this call chain...
public DoWork(index) >> private DoWorkHelper(index) >> private CheckIndex(index)
Now if you call DoWork, it traverses the calls down to CheckIndex, adding each deeper call to the call stack.
Now if someone calls DoWork with a bad value for index, it throws the exception all the way down at CheckIndex, and currently, that's where the debugger breaks. You then have to walk back up the call stack to see the real offender was that someone passed bad data to DoWork.
Now back in the VB6 days, you could simply decorate DoWorkHelper and CheckIndex with an attribute to say 'If any exception is thrown inside me, don't highlight me, but rather my caller because they were the ones that passed me bad crap!' So in this case, the code would break inside DoWork with the call to DoWorkHeper highlighted.
There was also a setting to disable this so for deeper debugging purposes it could still be thrown at CheckIndex, the level where it actually occurred, but half the time, breaking down there tells you nothing because you don't know how you got there without walking back up the call stack.
Think of it a way to decorate your code to say when you hit an exception, auto-traverse the call stack to the point where the bad value actually tells you something useful.
Note this is similar to 'Break On All Exceptions' except you're handling this via decoration. Plus, you're not setting to break on a specific type of exception (e.g. all null reference exceptions, etc.) but rather a specific method! (or more accurately, the one that called the decorated method.)
So does C# or .NET in general have this?
Update
While I credit Dark Falcon for the answer since he directed me there, I've added a more detailed explanation about what all the attributes mean, and in what context. Check it out below.
Please see the Just My Code option. You need to decorate DoWorkHelper with DebuggerHiddenAttribute or DebuggerNonUserCodeAttribute.
Just adding what I've found to better explain so people don't have to go looking elsewhere...
There are three attributes related to this: DebuggerHidden, DebuggerStepThrough, and DebuggerNonUserCode.
Here are the rules:
When Just My Code is not checked:
DebuggerNonUserCode
This is basically ignored. Breakpoints, step-into and exceptions all work the same as if this attribute wasn't there.
DebuggerStepThrough
This respects breakpoints and will break on exceptions where they occur, but you cannot manually step into blocks marked with this attribute.
DebuggerHidden
This doesn't allow you to step in to these blocks, it ignores breakpoints, and any exceptions thrown are handled in the calling method, not where they actually occur.
When Just My Code is checked
All three attributes behave the same as if you had used DebuggerHidden above.
There's another attribute, DebuggerStepperBoundary that is pretty cool. Here's the excerpt from MSDN:
Use the DebuggerStepperBoundaryAttribute to escape from stepping through code to running code. For example, in Visual Studio 2005, encountering a DebuggerStepperBoundaryAttribute while stepping through code using the F10 key (or Step Over command) has the same effect as pressing the F5 key or using the Start Debugging command.
Hope this clears things up! Sure did for me!
I have an ASP.NET web app which is small yet has a fair amount of C# behind it.
I am trying to run some code, which is dependent on a class library/.dll I have produced (containing business logic). When I debug, after I bind to datasource property, I get an object reference not set to an instance object.
I know how to fix these errors as I have done more than my fair show when I lacked experience, but the trouble I have is I cannot find the last method to execute (which will in turn help me find the variable at fault) until this exception. Is there a way I can make the code break when it reaches the line of code causing this exception (or the line of code matching the last method called in the stacktrace)? I will probably do a find for that method signature but I don't really like this approach. Is this something for windbg?
I guess this is what they mean by unmaintainable code.
Look at the stack trace that is most likely printed out with the error.
Also try breaking on exceptions - Debug Menu -> Exceptions, Choose CLR Exceptions
VS should highlight the line from which the exception was thrown. If it doesn't, you can enable it in Debug > Exceptions. If you put a breakpoint on or before this line (or if it doesn't give you a line, on or before the code you suspect of throwing it), and then "Step In" repeatedly, you will eventually reach the code where the exception is thrown.
Sometimes, while I am debugging a c# application, I will hit a break point and when I try to continue, step or step into, it just does nothing. The yellow line highlighting the current line goes away, but it never reaches the next line. The app is still frozen like I am on a breakpoint and I can do nothing but hit the stop debugging button and restart. This doesn't happen all the time, but once it starts on an app it seems like it always happens after that for that app. I have found that adding the following code just before the class declaration "fixes" the problem for that app, but am very curious as to why this is happening.
[System.Diagnostics.DebuggerDisplay("Form1")]
Additional details:
I have not noticed any kind of pattern as to what the particular line does when it freezes. Most of the apps I write use threading, so there is a decent chance this is happening within a thread every time.
I've seen stalling problems where the debugger is trying to evaluate the variables shown in the Auto/Local windows. If the evaluation is complicated then it can cause significant stalls.
You can turn the auto-evaluation off through Tools|Options and it does make a big difference.
I have come across with this kind of behavior, though this is my first time.
I have got through this problem, by two ways
Your way of putting this attribute, [System.Diagnostics.DebuggerDisplay("Form1")]
Turning off Tools->Options->Debugging->General->Enable Property evaluation and other implicit function calls.
I am still debugging my code but It seems to me that some of the Autos evaluation is failing (possibly throwing an exception), which is possibly crashing the debugger.
Please let us know if this is also your case.
What sort of code are you debugging?
When you "step into" are you calling your own .NET code, or calling a native library, or an external assembly that you don't have the pdb files for? Either of these situations would cause the debugger to freeze while the external code was executing.
If you debug multithreaded application you might be changing of thread. You can switch between Thread with the "Thread windows" while debugging to be able to see again where the debug yellow line is.
My psychic debugger says that you're missing symbols for something and that VS is hitting the network trying to look them up. Try setting your symbol path to something weird like C:\foo.
dead-lock seems likely in your case. Press the pause button and look at the threads view next time it happens.
I have seen this type of behavior when my DB was being very slow, NHibernate is trying to write to it under the hood, and the whole debugger gets locked randomly when the DB gets pegged.