why windbg can't disassemble x86 instruction prefix ?

yu_shang

I have a function (64 bit machine) which has 3 bytes of 3E in the middle, this prevent me from using uf to disassemble the function , windbg can partially disassemble the function , but stopped at the beginning of the 3 bytes of 3E and report the error of Flow analysis was incomplete, some code may be missing.
I have consulted the x86 reference manual , found that 3E is an instruction prefix.
Any suggestion? Many thanks!

Scott_Noone_(OSR)

I can't speak to whether or not a bunch of 3Es is valid, but uf is pretty simple and doesn't handle a lot of things. What does u decode the instructions as?

yu_shang

@Scott_Noone_(OSR) said:
I can't speak to whether or not a bunch of 3Es is valid, but uf is pretty simple and doesn't handle a lot of things. What does u decode the instructions as?

no. u command does not work. I can set a break point at the first 3E and continue with a t command, windbg will skip the remaining 2 3Es and stop at the instruction right after the last 2 3Es.

Scott_Noone_(OSR)

What's the output of u?

Tim_Roberts

3E is the "branch usually taken" prefix. The behavior of multiple prefixes of a single type is undefined; the various processors handle that case differently, so it's never supposed to be done. Oddly, the 3E prefix is in the same type as the segment overrides, so you can't have a 3E plus a segment override.

How did you get this? The compilers shouldn't produce that kind of code.

And, as a side note, it isn't windbg that is skipping the remaining prefixes. Windbg just tells the CPU "go execute one instruction and interrupt". It's up to the CPU to decide where the next instruction is.

yu_shang

@Scott_Noone_(OSR) said:
What's the output of u?

u 00007ff7`909b6acf l4

...
00007ff7`909b6acf 3e              ???
00007ff7`909b6ad0 3e              ???
00007ff7`909b6ad1 3e              ???
00007ff7`909b6ad2 3e4c8d442434    lea     r8,ds:[rsp+34h]
...

yu_shang

@Tim_Roberts said:
How did you get this? The compilers shouldn't produce that kind of code.

it is in fact a function in Excel

0:000> u 00007ff7`909b6aca l5
Excel!MdCallBack12+0x7a:
00007ff7`909b6aca e8d55789fe      call    Excel!Ordinal43+0x22c2a4 (00007ff7`8f24c2a4)
00007ff7`909b6acf 3e              ???
00007ff7`909b6ad0 3e              ???
00007ff7`909b6ad1 3e              ???
00007ff7`909b6ad2 3e4c8d442434    lea     r8,ds:[rsp+34h]

Tim_Roberts

I'm going to guess that's a hook for code to be patched in at runtime. You don't use a "branch usually taken" prefix with an lea instruction.

Scott_Noone_(OSR)

So, to answer the original question: The WinDbg disassembler doesn't understand that sequence and uf stops when it gets to something it doesn't understand.

yu_shang

@Scott_Noone_(OSR) said:
So, to answer the original question: The WinDbg disassembler doesn't understand that sequence and uf stops when it gets to something it doesn't understand.

yes. this is not the problem of windbg. I'm curious why this function behaves like this.