locked
Debugging - Stepping Broken RRS feed

  • Question

  • For some reason, when I debug my Windows Mobile 6.5 /.NET Compact 3.5 app deployed my handheld, the debugger no longer allows me to step over or step into.  It stops at my breakpoints, thank God, but if I hit F10 or F11 it winds up stopping at some other method I don't have a breakpoint on. Then it steps out and continues.

    In short, I can't trace through my code.  Any suggestions?

    Thanks!

    Aaron

    Wednesday, January 25, 2012 3:18 PM

All replies

  • Hi Aaron,

    >>but if I hit F10 or F11 it winds up stopping at some other method I don't have a breakpoint on.

    It seems the correct behaviour. The debugger steps into the method called by the fuction you breaked.

    If I misunderstand, please prepare some simple repro steps for invesigation.

    Regards,

    Yi


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 30, 2012 9:43 AM
  • Hi Yi,

     

    Thanks for the reply.  No, this wasn't the correct behavior in that if you're on line 88 and you hit F10, you expect it to go to line 89.  It would skip line 89 (and all the subsequent lines in the current method) and jump back out to some line in the calling routine (as if I had hit step out instead of step over).

    The good news is that it seems to now be fixed.  I fixed it by installing Service Pack 1 to Visual Studio 2008.  I also found this patch for VS, but never wound up needing it.

    Thanks!

    Monday, January 30, 2012 1:31 PM
  • On Mon, 30 Jan 2012 13:31:44 +0000, Aaron Edwards wrote:

    Hi Yi,

     

    Thanks for the reply.  No, this wasn't the correct behavior in that if you're on line 88 and you hit F10, you expect it to go to line 89.  It would skip line 89 (and all the subsequent lines in the current method) and jump back out to some line in the calling routine (as if I had hit step out instead of step over).

    Any chance you were trying to debug optimized code?


    The good news is that it seems to now be fixed.  I fixed it by installing Service Pack 1 to Visual Studio 2008.  I also foundthis patch for VS <http://support.microsoft.com/kb/957912/en-us>, but never wound up needing it.

    Thanks!

    Tuesday, January 31, 2012 6:52 PM
  • I'm not sure.  How do I know if it's optimized code? I doubt my coding methods are very optimal :)

    Wednesday, February 1, 2012 1:53 PM
  • Also, I don't know if this is significant, but every time I debug I get this message:

     

     

     

     

    I don't know if this would come up using an emulator.  I only debug using my device.

    Aaron

    Wednesday, February 1, 2012 2:47 PM
  • On Wed, 1 Feb 2012 13:53:10 +0000, Aaron Edwards wrote:

    I'm not sure.  How do I know if it's optimized code? I doubt my coding methods are very optimal :)

    I was referring to optimization done by the compiler, and I think only done for release
    builds. Optimization usually rearranges code so the compiled code no longer corresponds
    properly with source code and the debugger can no longer step properly. So the question is
    whether you tried to debug a release build. I don't think I'm the only person whose done
    that.

    Friday, February 3, 2012 9:51 PM
  • On Wed, 1 Feb 2012 14:47:07 +0000, Aaron Edwards wrote:

    Also, I don't know if this is significant, but every time I debug I get this message:

     

     

     

    <http://social.microsoft.com/Forums/getfile/61571/>

    I'm not familiar with that message, but it sure looks relevant. I think it means the
    debugger can't find the information it needs to connect compiled and source code. I just
    used google to look up
    "during remote managed debugging, symbols are cached"
    (note that I included quotation marks to make sure the string is used as a whole) and came
    up with several hits that look relevant and useful.


     

    I don't know if this would come up using an emulator.  I only debug using my device.

    Aaron

    Friday, February 3, 2012 9:51 PM