Look closely at the code you're looping within: it uses the FS register in several places. Now, googling for "windows FS register" tells you that this holds the segment of the
TIB for Thread Information Block. And the first entry in that block, at byte offset 0, has the address of the current
SEH, Structured Exception Handler.
Your code above is writing to that SEH, so it's reasonable to assume (as this is within ntdll.dll) that this is the part of the kernel that processes (possibly nested) exceptions. Seems that your application somehow detects the presence of a debugger, and sets up a bogus exception handler in that case. Probably this happens way before your
I'd check the assembly code if there is any call to
IsDebuggerPresent. Or, maybe, it gets the address of the current PEB (Process Environment Block) at
[fs:0x30], and reads the second byte of it, which is a
BeingDebugged flag. Probably your code uses some of these to check for a debugger, and does something to the exception handler in that case.
Also, your sample may just set up an exception handler, then execute an 'illegal' instruction, like
sti, or access an unmapped memory location. This will raise the exception; but if you just single step your program, Olly won't know the exception is going to happen, so it places its temporary single-step-breakpoint at the wrong location. Try to remember the address where an exception happens when single stepping, and be careful to add a breakpoint on the exception handler the next time.