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

The Discussion

• 

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

  C

• 

  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

• 

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

• 

  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 ) 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.

   

  Brian

• 

  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.

   

  Brian

• 

  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.

   

  Thanks,

  Habib Heydarian.

   

• 

  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.

   

  HabibH.

   

• 

  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! 

   

  (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.

• 

  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.

   

  Brian

• 

  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.

   

  Brian

• 

  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.

  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.

   

  Brian