stustu

My feedback

  1. 309 votes
    Vote
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      You have left! (?) (thinking…)
      15 comments  ·  Visual Studio IDE » Debugging and Diagnostics  ·  Flag idea as inappropriate…  ·  Admin →

      Thank you for using Visual Studio and for your commitment to improving it. We are currently evaluating whether we will be able to address this suggestion in a future release. Thanks for capturing the pain points you feel when stepping through multithreaded applications while debugging. We will be providing an update soon.

      Additionally, I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread. If you have other breakpoints in your application and another thread hits one, then you will be debugging in the mixed thread state as described in this item.

      Kaycee Anderson
      Program Manager, Visual Studio

      stustu commented  · 

      This has been broken since the dawn of time. IBM's OS/2 debugger worked correctly, kdbg works correctly, xdbg or whatever AIX's full screen debugger was called worked correctly, eclipse with gdb works correctly, msvc is the only debugger I've ever used that has this crazy random thread context switching problem, and it has had it at least since this product was called visual c++. If they haven't been able to fix it by now, likely they're never going to. Makes you wonder how MS developers debug their software, obviously they don't use their own tools or they'd have fixed this problem by now.

    Feedback and Knowledge Base