Home/ Questions/Q 349907
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T11:30:06+00:00

I’ve been working for years with VS’s debugger, but every now and then I

  • 0

I’ve been working for years with VS’s debugger, but every now and then I come across a feature I have never noticed before, and think "Damn! How could I have missed that? It’s so useful!"

[Disclaimer: These tips work in VS 2005 on a C# project, no guarantees for older incarnations of VS or other languages]

Keep track of object instances

Working with multiple instances of a given class? How can you tell them apart?
In pre-garbage collection programming days, it was easy to keep track of references – just look at the memory address. With .NET, you can’t do that – objects can get moved around.
Fortunately, the watches view lets you right-click on a watch and select ‘Make Object ID’.

This appends a {1#}, {2#} etc. after the instance’s value, effectively giving the instance a unique label.

The label is persisted for the lifetime of that object.

Meaningful values for watched variables

By default, a watched variable’s value is it’s type. If you want to see its fields, you have to expand it, and this could take a long time (or even timeout!) if there are many fields or they do something complicated.

However, some predefined types show more meaningful information :

  • strings show their actual contents
  • lists and dictionaries show their elements count etc.

Wouldn’t it be nice to have that for my own types?

Hmm…

…some quality time with .NET Reflector shows how easily this can be accomplished with the DebuggerDisplay attribute on my custom type:

[System.Diagnostics.DebuggerDisplay("Employee: '{Name}'")]
public class Employee {
    public string Name { get { ... } }
    ...
}

… re-run, and it works.

There’s a lot more info on the subject here: MSDN

Break on all exceptions

… even the ones that are handled in code!
I know, I’m such a n00b for not knowing about this ever since I was born, but here it goes anyway – maybe this will help someone someday:

You can force a debugged process to break into debug mode each time an exception is thrown. Ever went on a bug hunt for hours only to come across a piece of code like this?

try {
    runStrangeContraption();
} catch(Exception ex) {
    /* TODO: Will handle this error later */
}

Catching all exceptions is really handy in these cases.
This can be enabled from Debug > Exceptions… (Ctrl-Alt-E). Tick the boxes in the ‘Thrown’ column for each type of exception you need.

Those were a few forehead-slapping moments for me.
Would you care to share yours?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Two in-code tricks:

    I really like the System.Diagnostics.DebuggerStepThrough attribute; you can attach it to a class, method or property to make VS not enter the code by default when debugging. I prefer it over the DebuggerHidden attribute as it will still allow you to put breakpoints in the ignored code if you really need to debug it.

    Another (sometimes) useful call is System.Diagnostics.Debugger.Launch(); when the execution hits it, you will be presented with the “select a debugger” dialog, and a debugger will start. A bit rude, but useful with particularly nasty to attach to processes, like a process that gets spawned by another and immediately executes your code.

    • 0