[dyn!o]

I am glad we switched from "you said.. I said...".

"You stated that "DEC ECX" can crash something. This is why I asked you to explain that."
I hope I did it.

""MOV EAX, EAX" is an effective "NOP". It does nothing expect modifying EIP. No procedure starts at 00403ECE, it starts at 00403ED0."
Right, but I didn't say it does something and didn't say it starts here. Opcodes like LEA EAX, EAX (TeLock trick) can crash some ring3 debuggers and that is why I said it smells like be related to protection and pointed ExitThread API (I am suggesting that this place (API call) may be connected with some protection routine).

"You started with your "middle" instructions. When you put two "DEC ECX" right after each other but put a breakpoint on execution on the second one, "middle" instructions will get executed."
Right again but we missed the topic. I was trying to show that a flow of "DEC ECX" opcode will modify flags. You may know that but not everyone.

"We have no interpreter here. When I use an interpreter which formats your hard disc when it encounters 0x49 ("DEC ECX") than of course this "bytecode" can do anything. But it is no longer a "DEC ECX" in this context."
And it's first time we are talking about the same theory (I hope). I didn't mean strict byte code interpreter (or PCODE or VMs) but the idea of logging or controlling the affects, not results.

This problem (crash) is a really interesting one and since we don't have this file in our hand it will require a serious OS knowledge from Mahmut to reveal the reason of crash on his own.

Regards.