Visual Studio only breaks on second line of assembly?

Question

The short description:

Setting a breakpoint on the first line of my .CODE segment in an assembly program will not halt execution of the program.

The question:

What about Visual Studio's debugger would allow it to fail to create a breakpoint at the first line of a program written in assembly? Is this some oddity of the debugger, a case of breaking on a multi-byte instruction, or am I just doing something silly?

The details:

I have the following assembly program compiling and running in Visual Studio:

; Tell MASM to use the Intel 80386 instruction set.
.386
; Flat memory model, and Win 32 calling convention
.MODEL FLAT, STDCALL
; Treat labels as case-sensitive (required for windows.inc)
OPTION CaseMap:None

include windows.inc
include masm32.inc
include user32.inc
include kernel32.inc
include macros.asm

includelib masm32.lib
includelib user32.lib
includelib kernel32.lib

.DATA
    BadText     db      "Error...", 0
    GoodText    db      "Excellent!", 0

.CODE
main PROC
        ;int 3           ; <-- If uncommented, this will not break.
        mov ecx, 6       ; <-- Breakpoint here will not hit.
        xor eax, eax     ; <-- Breakpoint here will.
_label: add eax, ecx
        dec ecx
        jnz _label
        cmp eax, 21
        jz _good
_bad:   invoke StdOut, addr BadText
        jmp _quit
_good:  invoke StdOut, addr GoodText
_quit:  invoke ExitProcess, 0
main ENDP
END main

If I try to set a breakpoint on the first line of the main function, mov ecx, 6, it is ignored, and the program executes without stopping. Only will a breakpoint be hit if I set it on the line after that, xor eax, eax, or any subsequent line.

I have even tried inserting a software breakpoint, int 3, as the first line of the function, and it is also ignored.

The first thing I notice that is odd: viewing the disassembly after hitting one of my breakpoints gives me the following:

01370FFF  add         byte ptr [ecx+6],bh  
--- [Path]\main.asm 
        xor eax, eax
00841005  xor         eax,eax  --- <-- Breakpoint is hit here
_label: add eax, ecx
00841007  add         eax,ecx  
        dec ecx
00841009  dec         ecx  
        jnz _label
0084100A  jne         _label (841007h)  
        cmp eax, 21
0084100C  cmp         eax,15h  

What's interesting here is that the xor is, in Visual Studio's eyes, the first operation in my program. Absent is the line move ecx, 6. Directly above where it thinks my source begins is the line that actually sets ecx to 6. So the actual start of my program has been mangled according to the disassembly.

If I make the first line of my program int 3, the line that appears above where my code is in the disassembly is:

00F80FFF  add         ah,cl

As suggested in one of the answers, I turned off ASLR, and it looks like the disassembly is a little more stable:

.CODE
main PROC
        ;mov ecx, 6
        xor eax, eax
00401000  xor         eax,eax  --- <-- Breakpoint is present here, but not hit.
_label: add eax, ecx
00401002  add         eax,ecx  --- <-- Breakpoint here is hit.
        dec ecx
00401004  dec         ecx  

The complete program is visible in the disassembly, but the problem still perists. Despite my program starting on an expected address, and the first breakpoint being shown in the disassembly, it is still skipped. Placing an int 3 as the first line still results in the following line:

00400FFF  add         ah,cl  

and does not stop execution, and re-mangles the view of my program in the disassembly again. The next line of my program is then at location 00401001, which I suppose makes sense because int 3 is a one-byte instruction, but why would it have disappeared in the disassembly?

Even starting the program using the 'Step Into (F11)' command does not allow me to break on the first line. In fact, with no breakpoint, starting the program with F11 does not halt execution at all.

I'm not really sure what else I can try to solve the problem, beyond what I have detailed here. This is stretching beyond my current understanding of assembly and debuggers.

Octaviaoctavian

"int 3" and "int3" are two different instructions - try the latter (it's one byte). In Linux, it's sometimes helpful to put a "nop" as the first thing in the file. Different situation, but it might help here, too(?). – Wafture

It looks like you change the code without rebuilding :) Did you try to rebuild and then set the breakpoint? – Cacuminal

@FrankKotler Thanks for the suggestion, but int3 is a syntax error in MASM. int 3 is definitely the right instruction for an Intel platform. – Octaviaoctavian

@OhadHoresh The build is up to date. I would not be able to hit any breakpoints if it was not because the source would be out of date. – Octaviaoctavian

If you unchecked the option (Require source files to exactly match the original version) in (Debugging options) you will be able to hit a break-point with out-of-date source code. – Christen

@NourSabouny Thanks for making me aware of that option, but it does not address the odd problem I am encountering. – Octaviaoctavian

Answer 1

I have discovered what the root of the problem is, but I haven't a clue why it is so.

After creating another MASM project, I noticed that the new one would break on the first line of the program, and the disassembly did not appear to be mangled or altered. So, I compared its properties to my original project (for the Debug configuration). The only difference I found was that my original project had Incremental Linking disabled. Specifically, it added /INCREMENTAL:NO to the linker command line.

Removing this option from the command line (thereby enabling Incremental Linking) resulted in the program behaving as expected during debugging; my code shown in the disassembly window remained unaltered, I could hit a breakpoint on the first line of the main procedure, and an int 3 instruction would also execute properly as the first line.

Octaviaoctavian

Answer 2

01370FFF add byte ptr [ecx+6],bh

At least I can explain away one mystery. Note the address, 0x1370fff. The CODE segment never starts at an address like that, segments begin at an address that's a multiple of 0x1000. Which makes the last 3 hex digits of the start address always 0. The debugger got confuzzled and started disassembling the code at the wrong address, off by one. The actual start address is 0x1371000. The disassembly starts off poorly because there's a 0 at 0x1370fff. That's a multi-byte ADD instruction. So it displays garbage for a while until it catches up with real machine code instructions by accident.

You need to help it along and give it a command to start disassembling at the proper address. In VS that's the Address box, type "0x1371000".

Another notable quirk is the strange value of the start address. A process normally starts at address 0x400000. You have a feature called ASLR turned on, Address Space Layout Randomization. It is an anti-virus feature that makes programs start at an unpredictable start address. Nice feature but it doesn't exactly help debugging programs. It isn't clear how you built this code but you need the /DYNAMICBASE:NO linker option to turn it off.

Another important quirk of debuggers you need to keep in mind here is the way they set breakpoints. They do so by patching the code, replacing the start byte of an instruction with an int 3 instruction. When the breakpoint hits, it quickly replaces the byte with the original machine code instruction byte. So you never see this. This goes wrong if you pick the wrong address to set the breakpoint, like in the middle of a multi-byte instruction. It now no longer breaks the code, the altered byte messes up the original instruction. You can easily fall into this trap when you started with a bad disassembly.

Well, do this the Right Way. Start debugging with the debugger's STEP command instead.

Outspeak

Interesting about the starting address of the program. I've tried your suggestions and updated my question. Some progress, but VS will still not hit a breakpoint on the first line. – Octaviaoctavian

I have still not been able to break on the first line of the program, but your answer gives the best description of what might be causing the problem. The bounty is yours, and I'll accept unless a definitive answer comes along. – Octaviaoctavian

Answer 3

If you press F+11 (step into) instead of Start Debugging the debugger will stop on the first line.

It is possible there is some messed up breakpoint setting. Delete any *.suo files in your project directory to reset all breakpoints.

Note that your project will have a secret headers and stuff in it if it has a main function. To set a breakpoint at the real entry point use: Debug + New Breakpoint + Break at Function -> wWinMainCRTStartup for a windows program or mainCRTStartup or wmainCRTStartup for a console program.

Natie