Can't seem to step into call from _asm code RRS feed

  • Question

  • I have the following code in a Visual C++ file:

    void MachineForthEngine::Execute(int* pInstructionStream)
    BYTE* pStart = m_pStart;
    int* pOpCodes = pInstructionStream;

    m_pVirtualCodePtr = m_pVirtualCodeTarget;

    // now reset m_pVirtualCodePtr back to beginning
    m_pVirtualCodePtr = m_pVirtualCodeTarget; 

    int baseForth = (int) m_forthImage;
    int esSeg = baseForth + esSegPtr;
    int csSeg = baseForth + csSegPtr;
    int ssSeg = baseForth + ssSegPtr;
    int dsSeg = baseForth + dsSegPtr;
    int fsSeg = baseForth + fsSegPtr;
    int gsSeg = baseForth + gsSegPtr;

    __asm mov eax,esSeg
    __asm mov [eax],es
    __asm mov eax,csSeg
    __asm mov [eax],cs
    __asm mov eax,ssSeg
    __asm mov [eax],ss
    __asm mov eax,dsSeg
    __asm mov [eax],ds
    __asm mov eax,fsSeg
    __asm mov [eax],fs
    __asm mov eax,gsSeg
    __asm mov [eax],gs

    __asm mov eax,pStart
    __asm call eax

    int i = 1;

    The code at pStart that I am trying to call is code that I hand assembled by writing bytes to memory.  When I look at it in the disassembly winodw it appears to be perfectly valid asm code,  This is the start of it:

    06620668 50                   push        eax  
    06620669 51                   push        ecx  
    0662066A 52                   push        edx  
    0662066B 53                   push        ebx  
    0662066C 54                   push        esp  
    0662066D 55                   push        ebp  
    0662066E 56                   push        esi  
    0662066F 57                   push        edi  
    06620670 90                   nop  
    06620671 90                   nop  
    06620672 90                   nop  
    06620673 90                   nop  
    06620674 B8 EE EE EE EE       mov         eax,0EEEEEEEEh  
    06620679 BA FF FF FF FF       mov         edx,0FFFFFFFFh  
    0662067E BF DD DD DD DD       mov         edi,0DDDDDDDDh  
    06620683 BE CC CC CC CC       mov         esi,0CCCCCCCCh  
    06620688 BD BB BB BB BB       mov         ebp,0BBBBBBBBh  

    I am able to set a breakpoint on line 06620668.  Yet when I Step Into the _asm call eax statement, it never hits the breakpoint and returns to the caller of Execute.  I can't for the life of me get this breakpoint to activate even though I'm doing a call to the line where it is.  I'm picking this project back up after a few years of letting it go.  This use to work back in VisualStudio 2013 or 2015 (don't remember the last one I used).  Anybody have any ideas? 

    Saturday, December 14, 2019 3:56 PM

All replies

  • Is this a Debug build or a Release build? If a Release build then optimizations
    are on by default. That can cause a disparity between line numbers in the source
    and what the compiler has actually generated. 

    - Wayne
    Saturday, December 14, 2019 4:24 PM
  • Did you try to put a breakpoint at ‘call eax’, then press <F11> when it stops here and you move the caret to Disassembly window? Otherwise <F11> does not seem to step in if Disassembly window is not focused.

    By the way, you do not have to put “__asm” to each instruction.

    • Edited by Viorel_MVP Saturday, December 14, 2019 5:47 PM
    Saturday, December 14, 2019 5:38 PM
  • It's a Debug build.  I'm thinking there might be some environment setting that I don't know about that's either new or wasn't the default when I was debugging this code some years back.  I'm sure I'll figure it out eventually; I'm just anxious to get back into the code.
    Saturday, December 14, 2019 9:49 PM
  • No, I definitely had the Disassembly window as the focus when doing the Step Into.  Also I would have thought that the breakpoint on the code being called should kick in whether I step into, over it, or even continue execution.
    Saturday, December 14, 2019 10:27 PM
  • For a debug build:

    It sets the break point on inline assembly without any issues here.

    Break points can also be set on external assembly too.

    This is with the default project settings but with Just My Code disabled.

    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Sunday, December 15, 2019 2:31 AM
  • Also I would have thought that the breakpoint on the code being called should kick in whether I step into, over it, or even continue execution.
    Ah yes, but 'stepping in' would be a little bit more safe regarding the target address (not line) - e.g. using self-modifying code? 
    Normally, 'moving' (exclusively) in 'Disassembly Window' is quite reliable  in VS  - and at the moment I do not remember a  debugging option apart from 'Enable address-level debugging', which you have obviously checked, because without, you would have no 'Disassembly Window'. One thing, to bear in mind: a breakpoint set on an address does not survive the debugging session unharmed ( gets disabled -> ASLR).
    You can certainly ensure that 'stepping in' in general is working by choosing a call instruction at standard code (e.g. in one of the crt-runtimes or kernel32.dll ...)
    or using a different debugger like 
    Windbg Preview
    which isn't affected by VS settings and in my personal opinion offers some added value for address level debugging.

    With kind regards     

    Sunday, December 15, 2019 10:29 AM
  • Hello,

    If your issue is solved, please "Mark as answer" or "Vote as helpful" post to the appropriate answer , so that it will help other members to find solution quickly if they faces similar issue.

    Best Regards,

    Suarez Zhou

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, December 20, 2019 7:04 AM