Hi,

I am playing around with an application where I have made a few changes to the base code. Somehow the app has worked this out (maybe some clever internal checksum calculation).

Anyway when the application has been running for a while (maybe working out the checksum calc) it popups a messagebox and says that there is a problem and it's now going to exit.

I can breakpoint on the messagebox OK, that's not the problem. If I try and use run trace it's only showing a few lines of code - and the locations are not in the user code - I think the buffer is being overrun because the app has to run for a while before the messagebox occurs.

I am sure that this is a problem that others must have encountered but so far I have not been able to locate any threads which discuss how to resolve. I am logging the run trace to a file and have the buffer set to maximum, so obviously that is not the solution.

Either I need a method to fix the run trace (preferred), or since I can catch the breakpoint on the messagebox, can I somehow work out where the procedure I am in was called from - so I can work my way back (effectively back trace)?

Thanks

VW

If this is an olly question then it should be in the new olly forum, but I'll try to give you some tips, in olly I use trace over very frequently, but it can be a slow process, the method is to trace over until you get your nag or whatever - pause execution and view run trace, now go to the last entry generated by your target and double click it, (almost always a call), then when on that code line hit enter to enter the call, set a break point and reload the program - run to the break and trace over from there - this can go be repeated many times, in your case your looking for a RaiseException call - and a possible jump over it or the code that calls the sub that calls it - I very seldom use trace into, it is way too slow and subject to being caught in loops. If your run trace is truky broken get a new copy of olly, my personal preference is Shadow's.

Hope this helps!

sIgInt

Yes this is an Olly question, I guess I goofed, maybe a moderator can move the post.



I believe that my copy of Olly is OK, I have been using run trace frequently on localised or targeted traces without problems.

The issue I have here, (and as it happens after restarting my computer, at the moment the app has now been running fine for about 30 minutes) so maybe I don't have a problem with the app after all - but it's an interesting scenario in any case.

But before that when the error message was popping up, it did not happen for sometime (say around 5 mins after the app had been running). I really have no idea where in the app where the call to the messagebox is coming from, so I have no idea where to set an "upstream" breakpoint - apart from where the initial program window is displayed.

So what I did, was setup a breakpoint just before the main window was displayed, and started the run trace at that point. Sometime later the app then breaked on the messagebox and then I went to the run trace which unfortunately did contain anything of use.

So when you say In this instance I am not sure that I can do that, because to be tracing implies that I have paused execution and I am now tracing the app by hand. But at this point I don't have any idea where the call to the messagebox is coming from, so I can't be stepping through procedures as the key call could be miles away.

I think my answer is to try and understand why the contents of the run trace is garbage.

Do you know if the run trace overflows does it just restart (i.e. does it use circular logging) or does it get messed up?

If it's the latter, I could try manually pausing the app at an arbitrary point during it's execution and starting the run trace and hoping that it didn't overflow before the breakpoint was triggered (not a robust approach - but it might work).

Thanks for your advice.

VW

Stack/Call stack can give you some clue...

Regards,
Knight

As Knight suggests, just run your app with olly, if and when the error appears pause execution, hit the blue "K" button and look in the stack for the last address from your target - double click on it and look for call - RaiseException, also in the stack window off to the right you'll see the address that called the routine that generated the exception, investigating there is probably the place that will yeild the best clues, you learn this technique quite quickly after unpacking a few apps dunped with DilloDie (still the best automatic answer around!).

SiGiNT

Thanks for the tip. I think that is going to be really useful.

Since I restarted my computer I decided to test the app and it has now been running for 8 hours, so I think whatever was causing the error to occur must have had something to do with all the debug sessions I had been running earlier.

I still have a lot to learn, but it is a lot more interesting once you start to get a grasp of some of the basics and can actually do some stuff. I initially started out with SoftIce, and although I did manage to accomplish a couple of tasks with it, I am finding Olly far easier to use.

Cheers,
VW

if buffer size set to maximum ie 64m/4m
if the records exceeds this limit the older ones are lost
the buffer is circular
if you are logging then losing old records should not be a problem you should be having the record of every single execution in your log file

i have a 102 mb txt file that notepad and wordpad refuses to open created with just a 512k buffer on a 64 mb ram machine tracing msword

if you are having run trace logs of non user mode code
then you can ask ollydbg to skip them

options ->debugging option -> checkmark always trace over system dll
options -> debugging options -> checkmark always trace over string commands (this would make all those repe scasb repnz lodsd rep stosw have just a single entry instead of trillion entries)

Never underestimate the power and versatility that olly has - it's used even by the pros in the software business, I'm really looking forward to Oleg's latest, ver, 2.

SiGiNT

I had these options selected (mine is 64m / 3m -> I assume that's a typo on your part).


I've now added this option as well.

The bit that I find odd, is that given that the buffer size was set to 64m/3m, I'm surprised that there were only about 15 entries in the trace.

To be honest, I think if I can use the call stack to narrow the trace range that's a far better approach.

But having said that, I still expected the run trace to contain a massive amount of entries, and it bothers me that I can't explain why the contents of the trace was so small. I'm sure that there is a logical explanation, most likely something that I'm doing.

Thanks

VW

I can think of a couple of ways you would end up with only a few entries, you had run trace going for an extremely long time, you may have paused execution during a "flush" - or the app may actually be similar to one I encountered recently, the main .exe was nothing but a GUI that executed code contained in associated .dll's, or like VB most of the code is executed in msvbmXX - more likely the first scenario, or olly simply choked "run trace" is not supposed to be used to monitor long term code execution, (that's an opinion). Or did you hit an exception and automatically hit shift F9? I've done that myself many times.

SiGiNT

I think you're definitely right about this. The main exe does contain some code, but there are two underlying modules that are responsible for a lot of the processing once the app is running.

So what you say makes sense.

VW

64m /4m is right its not typo

fewer entries may also mean that you are probably doing ctrl+f12 instead of ctrl+f11 ( trace over instead of trace in) now if you trace over it wont be logging any of the wndproc code

for example if you load iczelion tut-03 win.exe and TRACE IN you would see
all those loadicon setcursor apis being logged and the messageloop being logged infinite times log count dependent on the time you keep the exe running

while tracing over would yield just 9 entries till you exit

as far as exceptions are concerned if you still want to trace you should either
use options ->debugging options -> exceptions->add range or add custom exception details and check mark the ignore box

or use shift+f7 and continue with ctrl+f11

run trace is pretty much powerfull if used properly

btw if you are tracing an application that uses custom dlls that are not in
%system% directory and you want ollydbg to ignore those dlls also from
trace log
use
alt+E (view executable modules) select the dll that you want to ignore
and right click on it (you would see a context sensitive menu "MARK AS SYSTEM DLL" marking as system dll would make runtrace ignore them too
from logging

That's different to my option, I am using version 1.10 of Olly, what version do you have?


I understand the point you're making here, but at the time I wasn't stepping through code, I was letting the app run and was waiting for the dialog box to appear. Which I realise is more "brute-force" than a strategic approach, but as I didn't know where the 'trigger' was coming from I figured I would breakpoint on the messagebox and then trace the code back from there. In other words I would have a huge trace, but I would only be interested in (relatively speaking) the last few entries to identify where the error was coming from.


This is a really useful tip, I have encountered exceptions a couple of times, and I have not been sure what to do. I can't recall now for certain, but I have a feeling that I might have had an exception with this trace and hit shift+f9


Absolutely, I can work through the code if I can get close to where a 'key event' is happening, but at the moment I rely on run trace fairly heavily to analyse apps. That's why I was keen to understand why the contents of the trace was so small when I expected heaps of entries.


That makes sense, but I would never have considered that option.

Cheers,
VW

Blabberer,

Makes a lot of great points, but I would keep the size of your code in mind before executing trace-into, it might be best in this case to find the spot where the error is occuring, by tracing over, back-up a couple of calls and trace-into from that point, or you could be tapping your foot for a long time!

SiGiNT

@sigint33

i was not directing my answers towards his error i was just pointing out
ways and means to make an effective runtrace happen

as always its the hunter who decides whether to use dumdum bullets or .202

if he pumps dumdum on quails he will get trash instead of a clean kill
if he pumps 202 on bison he will probably kill himself with a ricochet

If one fires a .22 at a Bison, they will probably end up on "the horns of a dilemma" ! Bison are fairly aggressive beasts.

Regards,

Personally I prefer to shoot beer cans with a tank - you never miss.

SiGiNT

Hi,

Sorry to bump this thread, but I'm still getting results with run trace that are different to what I expect.

I have downloaded another Olly installation which behaves the same as my original install, so that indicates that Olly is working fine. Pity I can't download a new brain

So I would appreciate if someone can explain the following behaviour to me:

I have two screenshots of an extract from the same app. The instructions being executed in both examples are in the range 00472F53 to 00472608, with the same input.

The top half of the screenshot shows the run trace when I manually step through the app (using F8 for the API call & F7 for the balance). The contents of this run trace is as I expect it to be.

However when I configure the run trace and set breakpoints and then run the app (F9) for the same selection, I don't understand why the run trace only shows 3 entries.

And another question about "strange behaviour", although this question is purely cosmetic. In the CPU window, sometimes I am able to resize the vertical pane of the disassembler (to make the disassembler bigger and the registers smaller) and sometimes I cannot. I always seem to be able to select the horizontal pane (btw the disassembler and the run pane). But often I cannot select the vertical pane. Has anyone else observed this behaviour?

Thanks

VW

Howdy,

Perhaps he meant a .302 caliber. I dont think that would richocet .

As for the funky Olly ouputs,
Could it be stack stunts ? Can the program be changing each time it is run ?

Woodmann

Configure "run trace" and hit F9??? - just hit ctrl F12 to trace over - or ctrl F11 to trace into, when you hit F9 it bypasses "run trace".

SiGiNT

veedub,

Did i help? don't we get to see the obligatory DOH!!!!
I know you've been sifting through reams of trace code!

SiGiNT

Hi Sigint,

Sorry for the delayed response, I've been a bit busy with work so I haven't had a chance to test out what you say, but it does makes sense.

Having said that, the F9 thing is a bit of a trap for the unwary, because some of the time at least, the traces have worked OK using F9, which is how I got caught out in the first place. It would be better if nothing was recorded in run trace when using F9.

But assuming that what you say is right, and I expect that will be so, then from now on I should be able to rely on traces consistently which will be good.

Cheers,

VW

veedub,

Actually after posting I studied your sceens and was puzzled a little bit myself, I would have assumed that using F8 or F9 nothing would have been logged to run trace, it's a good thing to discover! I do a lot of hand tracing and sometimes completely forget how i found that "sweet spot"!

SiGiNT

means you did not configure it right

used copy-> rightclick -> select all ?

or you manually selected the lines ?

used add procedure ?

or add selection ?

i dont see in your screen shots the grey marker that denotes you have selected and ollydbg has added them to its trace database

after you hit f9 or f8 it should change the marker color to red

using f9 0r f8 and depending on the trace results is not really advisable
like its stated use ctrl+f11 or ctrl+f12

if you use f9 after you added the procedures ollydbg will also record
some dll entries
notable among them that gets logged umpteen times is
Ntdll.KiFastSystemCallRet on newer systems
it gets logged on all calls that end up in sysenter