I'm debugging a program that if any of the typical breakpoints are set the program breaks normally and if the run command (F9) is issued will go all the way to termination as it should. Without changing a thing, I then take the same breakpoints and target and automate stepping for some 50000 line code passing and about 2/3 of the way, some type of exception gets raised and it chokes olly.

Why would a full run not cause the expection and an automated step raise it? The only protection involved is crypto which is SHA1 and TEAN32.

I have the DECODE SSE REGISTERS disabled but all the rest in tact.

Any ideas why this error would happen?

thanks

Chris

probably some other single step preventing anti debugging trick that you have over looked

like pushf or [esp],100 popf or checking for 0x cc on esit points of loops
when you automate olly sets one time break points called hit points (Not just olly all debuggers for that fact set a single hit bps for traversing loops
may be it is being checked
there are lot of possibilites
can you say what is the ezception that is getting raised ???
did you try passing it to program ??
did you view seh chain and locate the handler ???
did you break before there using runtrace condition and single step ??
i dont think the above mentioned info is sufficient enough to give a
reasonable answer

maybe a RDSTC protection, when stepping more time pass and this is detected

Ricardo Narvaja

RDTSC sorry write error

Ricardo

The process does not allow for a pass exception like control f7 f8 or f9, the process from what I've seen a few times is Zw.raiseexception which I think is an int 3 exception. I've tried the plugin that unhandleexpectionfilter .22p, it says it can't find the signature. I don't think the two are the same.

When the exception occurs the total process terminates. I've done PEID on it and there is nothing else.........Its just a C++ [debug] overlay which shouldn't pose a problem.

I've look under the seh chain but the exception terminates and doesn't list the caller of the exception

The break occur before the run trace sucessfully, its after the automation step is sequence that it parses 2/3 after the break and then fails. Under full run mode, it finishs sucessfully with no exception. I can run it again and give a screen shot if needed.

Thanks for the response, hope to hear from you soon

Chris

still it is not clear enough to warrant a reply well olly cant magically terminate any application
zwRaiseException is the native api call which raises the Exception it is exported by ntdll.dll
probably you have already checked pass the following exceptions to the program and it is passing it automatically and gets terminated
what are you trying to achieve by auto stepping ?? why not use conditional break points effectively and stop at the required places instead of vague tracing ?? or use the log function of runtrace and log the whole crap and try looking through the logged commands then set a break point f9 and then auto single step to isolate the offending instruction

as ricardo posted it may be timing the sequence and verifying whether it is single stepped or not

UnHandledExceptionFilter is set by the calling process which handles any exceptions that are not handled and its functionality is almost same as
ntdlls final handler get jeremy gordons Except32 seh tutorial and give it a read through

may be look into debugging options -- exceptions and find what options are checked in there may be uncheck them all and add them one by one
as they arise
good luck