Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

10-4 Episode 28: An Introduction to the Historical Debugger

11 minutes, 20 seconds


Right click “Save as…”

  • WMV (WMV Video)
  • MP3 (Audio only)
  • Low Quality MP4 (approx. 500-800kbps)
The new Historical Debugger coming in Visual Studio Team System 2010 promises to revolutionize the way you debug managed applications. You can think of it as something of a VCR for your debugger; "rewind" the debugging trace to examine the state of your application at various points in time so you can all-but-eliminate the guesswork about where to place your breakpoints prior to pressing F5.

This quick overview screencast will give you just a taste of the capabilities offered by the Historical Debugger. For more information check out:

For more 10-4 episodes, be sure to visit:

Visual Studio Topic Area on Channel 9:

Visual Studio 2010 Beta:

10-4! Over and out!


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • CharlesCharles Welcome Change

    This is one of the coolest new features in VSTS 2010. Thanks for the great demo and concise explanation, Brian.


  • W3bboW3bbo Work hard; increase production; prevent accidents, and be happy.

    The video description says it's in VSTS2010, will it be available in the other SKUs? We Professional users don't like to feel left-out Smiley

  • CharlesCharles Welcome Change

    Sorry about my typo (fixed). I don't know the answer to your question. Brian does though Smiley

  • A question when running on a 64-bit platform (Vista/Win7-x64).


    Did I understand you correctly, that F5-Historical Debugging will not work if I'm running Vista/Win7-x64? Only post analysis on this platform.


    Is that because VS2010 is still a 32-bit app running in the WOW layer on x-64?

  • Hi W3bbo,


    The SKU plans haven't been locked yet (or if they have, marketing hasn't told me Smiley ) but unless something changes this feature will be limited to people using the Development or Suite editions of Team System.


    I know this will cause some angst since it's such a cool feature, but that's the business of building and selling developer tools... gotta pay the bills.



  • Hi Tschlarm,


    There's one workaround that I just found out from the product team, and that is that you can set your build configuration to x86 and the F5 scenario will work. F5 doesn't work when your app is targeting x64.


    The other scenarios outlined on Habib's blog (such as being able to collect historical debugger trace data while your automated or manual tests are running) will work with x86 or x64.



  • To add to Brian's point about 64-bit support, in the F5 scenario, our collection mechanism (i.e. how we collect information about a process) is specific to 32-bit processes. Unfortunately, we didn't have enough time to implement 64-bit support and had to make a hard cut. You can bet that 64-bit support is one of our top priorities after the VS2010 release.



    Habib Heydarian.


  • W3bboW3bbo Work hard; increase production; prevent accidents, and be happy.

    Such as in a Service Pack release for VS or will it have to wait until VS2014?

  • The scope of the work to support 64-bit won't fit into a SP. It would be the version after VS2010 but I don't know the exact timeline.




  • Tom BesserTRBesser Technobabble

    Thanks for the great info in these 10-4 shows.  I'm looking forward to using VS2010!


    BTW, you might want to check on your patients in that health monitoring app... those ECG readouts are virtually near death! Smiley


    (Sorry, my wife's a nurse, so I tend to notice these things...)

  • Hi,


    Thanks for the info. Glad to know I can move to x64 and not lose out on some dev tools. Hopefully, this will be toward the top of the list for the VS.Next.


    Anything else VS2010 may have issue with under x64? Anything that can't be avoided by targeting x86?

  • The 64 bit explanation was bit confusing in the video. What I got from it was that you need 32 bit cpu and OS for the f5 scenario. Or does the f5 scenario work with 64 bit cpu and OS when debugging 32 bit (non- any cpu) managed app?

  • Thanks TRBesser! I guess I got caught up in the excitement of filming the screencast and forgot to monitor my patients. I'll go check on them now. Wink

  • Hi tschlarm,


    I am not aware of any other features which are limited to 32-bit only but if I find any I will post them back here. Rest assured that supporting 64-bit is a very high priority for us, and as Habib points out there's a workaround to allow you to use the Historical Debugger by setting your target CPU to 32-bit in VSTS2010. Not ideal... but switching from a 32-bit to 64-bit world is a journey.



  • Androidi,


    My apologies, that was my fault for making the video confusing since I had a different understanding when I originally learned about this limitation. The 64-bit limitation during the F5 scenario is only about the target application being 64-bit; you can still be developing on a 64-bit machine as long as you set the target CPU to be 32-bit. Other scenarios such as collecting the debugging trace files (which can be consumed by the historical debugger) while running your tests are supported on both 32-bit and 64-bit hardware, regardless of your application's target CPU.


    I hope that makes it a bit more clear.



  • My version of Visual Studio 2010 Beta 1 is 10.0.20506.1. The Historical Debugger doesn't appear to me. I need to do something else?

  • Sorry, my fault. I have Professional edition, not Team System.

  • No worries. Smiley

    Also note that I used a newer build than beta 1 in my demo, so you may notice a few differences as you play with the beta 1 bits.

  • Right... but I often find that customers perception of your (any) platform is that if an application crashes it's interpreted as "Windows crashes". In other words the stability of ISV applications gets confused in customers mind with the perception of your platform as a whole.  I understand the point that the devdiv team needs to report to the bean counters, it's just a shame to see a debugging tool become exclusive. Please, please don't limit the availability of concurrency developer supports - helping the wider software industry transition to a many core world is something Microsoft is in a almost unique position to deliver on. Visual Studio and Blend *are* my desktop, I love these tools, it's just sad to see passionate younger engineers out there in the community get behind a new feature only to have to it denied them.

  • Hi Dot_Tom - I totally understand what you're saying. We're investing in a lot of capabilities around application quality which will not be limited to the Team Edition developer.


    In terms of concurrent development I believe that all of those features will be available in VS Pro. Nothing is baked until the marketing team announced it as such, but I don't believe based on what I know today that you'll be missing anything here.



Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.