Why debug occasionally brings up disassembly rather than Windows files?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5

Thread: Why debug occasionally brings up disassembly rather than Windows files?

Hybrid View

  1. #1
    Join Date
    May 2002
    Posts
    1,723

    Why debug occasionally brings up disassembly rather than Windows files?

    On fairly rare occasions, when attempting to debug one of my MFC applications on VS 2010, a compilation error is encountered, and instead of bringing up the customary Windows or MFC file with a arrow pointing to the problem, a disassembly appears with an arrow pointing to one of the assembler instructions. Since Windows assembly language is hardly my forte, I do not know how to interpret the error. Furthermore, the Output usually indicates one or more 'first chance exceptions' but little more, and the Stack output usually quite sparse and often refers cryptically to some ntdll.dll!7c92a82c().

    How can I better define the compile error?

    Would someone kindly explain to me what's going on here? Thanks.
    Last edited by Mike Pliam; January 15th, 2013 at 03:46 PM.
    mpliam

  2. #2
    Join Date
    Feb 2002
    Posts
    4,640

    Re: Why debug occasionally brings up disassembly rather than Windows files?

    It sounds like you don't have the debugging symbols for 'ntdll.dll' installed: http://msdn.microsoft.com/en-us/libr...=VS.71%29.aspx

    Viggy

  3. #3
    Join Date
    May 2002
    Posts
    1,723

    Re: Why debug occasionally brings up disassembly rather than Windows files?

    Thanks MrViggy. I tried to follow the instructions as posted. A MicrosoftPublicSymbols directory now appears where I set it with numerous *.pdb files. Now the Call Stack is clearly different but the same disassembly comes up.
    Call Stack repeats
    Code:
    	ntdll.dll!_RtlDispatchException@8()  + 0x8 bytes	
     	ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xe bytes	
    //..
    Still puzzled and wondering why I never heard of these debugging symbols in 10 + years of programming VS. This was supposed to be Visual Studio 2010 Ultimate but apparently it's only penultimate. : )
    mpliam

  4. #4
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    5,962

    Re: Why debug occasionally brings up disassembly rather than Windows files?

    Quote Originally Posted by Mike Pliam View Post
    On fairly rare occasions, when attempting to debug one of my MFC applications on VS 2010, a compilation error is encountered, and instead of bringing up the customary Windows or MFC file with a arrow pointing to the problem, a disassembly appears with an arrow pointing to one of the assembler instructions.
    When you get to attempting to debug, the error just cannot be a compilation error. Your code compiles fine as long as it is able to run.

    Quote Originally Posted by Mike Pliam View Post
    Still puzzled and wondering why I never heard of these debugging symbols in 10 + years of programming VS.
    Years of programming has nothing to do with stack of technologies you typically have in use during development lifecycle. Typical development relies on frameworks and runtimes of quality good enough to let you never have problems elsewhere but your own code. So you just confirm this rule.

    And the fact that you experience this kind of problem indicates a) framework quality not good enough, or b) framework improper use, or c) basic platform/language programming rules being violated so bad (like buffer overruns, stack/heap corruption, wild pointers, uncaught exceptions, etc.) , that problem extends far beyond your own code bounds.
    Last edited by Igor Vartanov; January 17th, 2013 at 12:54 AM.
    Best regards,
    Igor

  5. #5
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,239

    Re: Why debug occasionally brings up disassembly rather than Windows files?

    I used to get this problem quite often with VC++6 but I haven't seen it for many years now. Anything that's designed to shorten your build time is a possible candidate for suspicion. Try turning off precompiled headers / incremental linking and stuff like that. I don't know if it'll help but that's where I'd be inclined to start.
    "A problem well stated is a problem half solved. - Charles F. Kettering

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center