I read the recent article "Longest x86 Instruction"


I attempted to reproduce the curious disassembly issue on a Win7x86 development platform using masm and as the article suggested, redunant prefixes.

Talk is cheap, so here's a toy program (masm32):

.386 .model flat, stdcall

option casemap:none

includelib \x\x\kernel32.lib
includelib \x\x\user32.lib

include \x\x\kernel32.inc
include \x\x\user32.inc
include \x\x\windows.inc



db 0F3h
db 0F3h
db 0F3h
db 0F3h
db 0F3h
db 0F3h
db 0F3h
;...6 more bytes later
db 089h
db 0E5h

end start

invoke ExitProcess, NULL

After linking and assembling, I opened the resulting executable in windbg.

To my disappointment, when I single step, unassemble the $exentry, etc. windbg simply sees the prefixes/bytes as individual instructions, says 'to hell with it' and executes only the valid instructions.

Is there something I'm missing?

  • the link is dead :( Nov 29, 2019 at 3:29
  • i updated the link, blame it on bitrot
    – grepNstepN
    May 8, 2020 at 20:35

1 Answer 1


I was confused by the disassembler implementation...the processor executes instructions that are ( i.cache <=15B ) as the artcle states.

Verified when I single step, as IP increases by 15B.

So, it accurately treats the prefix bytes as a part of one single instruction.

However, I tested dumpbin /disasm and windbg so far, which disassemble the prefix bytes as individual instructions instead of contiguously with the "real" instruction, e.g.

89 ; start of 'real' instruction: mov ebp, esp

...having evil thoughts already.

Apologies for forgetting the OS's/software's disassembler implementation isn't taking full advantage of processor capabilities (like Windows not implementing Ring2, etc.).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.