InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Historical Debugging in Visual Studio 2010

Posted by Jonathan Allen on Apr 22, 2009

Sections
Development
Topics
.NET ,
IDE ,
Debugging

Have you ever wanted to know what you program was doing 5 minutes ago? Ever wondered exactly what files it was opening instead of the one you wanted it to? Well Visual Studio 2010 has got you covered.

During the Lang.NET keynote (10 minute mark), Microsoft demonstrated Visual Studio 2010’s diagnostic events and historical debugging features. These features allow developers to not only see the application as it currently stands, but also the events that led up to that condition.

The diagnostic events window shows key events in an application’s run. These include exceptions, file access, and debugger events. In some ways these could have been hand-rolled using Debug.Write statements or macros on breakpoints. But with an integrated list view, this allows you to filter on the type of event or the thread the event occurred on.

While a good feature on its own, this is dwarfed by the historical debugging capabilities. When turned on, Visual Studio can capture stack frames and the variables associated with them. This allows developers to back-step through the program to find out why something happened the way it did.

In order to save this information, the state of the application is stored on disk. By default it only stores key types, but developers can set it to record literally every parameter, object, and global variable. The only thing it will not store is local variables.

For more information, also see the video discussing historical debugging on Channel 9. This feature should be included in the upcoming beta 1 release.

12 comments

Watch Thread Reply

Sounds like a very helpful feature! by Josh Grenon Posted
Re: Sounds like a very helpful feature! by Andrew Zhygmanovsky Posted
Re: Sounds like a very helpful feature! by Dan Tines Posted
Re: Sounds like a very helpful feature! by Jonathan Allen Posted
Re: Sounds like a very helpful feature! by Andrea Del Bene Posted
Re: Sounds like a very helpful feature! by Jonathan Allen Posted
Re: Sounds like a very helpful feature! by Andrea Del Bene Posted
Re: Sounds like a very helpful feature! by Dan Tines Posted
Re: Sounds like a very helpful feature! by Andrea Del Bene Posted
Re: Sounds like a very helpful feature! by Heejoon Lee Posted
It has a java counterpart by cloud jun Posted
Re: It has a java counterpart by Francisco Jose Peredo Noguez Posted
  1. Back to top

    Sounds like a very helpful feature!

    by Josh Grenon

    I can't believe I didn't hear about this yet. This is going to be a very useful feature for all developers of any level.

  2. Back to top

    Re: Sounds like a very helpful feature!

    by Andrew Zhygmanovsky

    objection
    as far as i can see this useful feature will be useful indeed only for rather simple products
    and now imagine how this debugger will slow some massive semi-enterprise web-solution considering that simple debugger slows them quite noticeably
    don't believe that MS will make this feature as lightweight and fast as possible for such solutions (and, you know, these are solutions that _really_ need this feature) as, for instance, log4net/log4j components or something like that

  3. Back to top

    Re: Sounds like a very helpful feature!

    by Dan Tines

    I think this is going to be great.

  4. Back to top

    Re: Sounds like a very helpful feature!

    by Andrea Del Bene

    Maybe I'm wrong but it seems to me an "anti-TDD" feature, the classic "nice" feature just to catch the attention of lazy developers.

  5. Back to top

    Re: Sounds like a very helpful feature!

    by Jonathan Allen

    Two points.

    First, this is an op-in feature. Most of the time you will have it tuned down or turned off completely.

    Secondly, it is in no way meant to replace traditional logging. It is a debugging and analysis tool, not something that should be run in production.

  6. Back to top

    Re: Sounds like a very helpful feature!

    by Jonathan Allen

    Maybe I'm wrong but it seems to me an "anti-TDD" feature, the classic "nice" feature just to catch the attention of lazy developers.


    It is important to keep in mind that debugging and testing are not the same thing. Tests are for testing, that is determining if something is broken. Debugging tools help you find out why something isn't working. As a software engineer, you need to understand how to use both.

  7. Back to top

    Re: Sounds like a very helpful feature!

    by Andrea Del Bene

    Yes, debug and TDD are two different things but I'dont' agree when youn say taht tests are only for "determining if something is broken". If a test fails it means that your code doesn't respect the expected behavior, and if you apply good TDD you know exactly where you code fails without walking through code (that is a boring and repetitive task)

    From en.wikipedia.org/wiki/Test-driven_development

    "Benefits :
    ...
    Programmers using pure TDD on new ('greenfield') projects report they only rarely feel the need to invoke a debugger."

  8. Back to top

    Re: Sounds like a very helpful feature!

    by Dan Tines

    Many teams don't subscribe to TDD. Besides, as has already been stated, tests and debugging are really orthogonal.

  9. Back to top

    Re: Sounds like a very helpful feature!

    by Andrea Del Bene

    Many teams don't subscribe to TDD.


    That's a pity :-) ...

  10. Back to top

    Re: Sounds like a very helpful feature!

    by Heejoon Lee

    Maybe I'm wrong but it seems to me an "anti-TDD" feature, the classic "nice" feature just to catch the attention of lazy developers.

    Unit tests and debugging are not same. But IMHO, people tends to make less unit tests and to do more edit-run-watch cycle, when they have good debugging tools.

  11. Back to top

    It has a java counterpart

    by cloud jun

    Reading this post reminds me of its java counterpart, Omniscient Debugger (www.lambdacs.com/debugger/). It is a java historical debugger that shows stacks, threads, local variables, method trace, code and even output at the same time, which at this moment, seems to be a superset of the .net historical debugger.

  12. Back to top

    Re: It has a java counterpart

    by Francisco Jose Peredo Noguez

    Yes, the java Omniscient Debugger (ODB) might be better, but unlike vs.net historical debugging, ODB seems to be a dead project: That page is from 18 February 2007. Why this feature is not included by default in Eclipse or Netbeans? (or even IntelliJ) ?

Educational Content

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?