Hello, this is my first post here, and I don't know if this is a known problem or not, nor if it is really a bug, but I couldn't find anything similar on the forum.

I'm currently debugging a game, but sometimes Olly enters in a continuous loop locking itself, from which it exits apparently randomly after some time. This occurs only when the debugged app loads or unloads any modules, or when it creates or terminates a thread.

From my debugging, I've discovered that this happens in Olly's loop of patches (the one in the function at 0x0049E214). At the end it always jumps back:

0049E4B7 |. 3B05 E8784D00 |CMP EAX,DWORD PTR DS:[4D78E8]
0049E4BD |.^ 0F8C AAFDFFFF \JL OllyDbg.0049E26D

Here eax ranges from 0x0 to 0xE, while [4D78E8] is something big like 0xB8D.

Note that this happens even if only one patch or breakpoint is applied. Do anyone has any clue what is this?

thanks, og.

the address you mention is t_table -> t_sorted -> no of actual entries

004D78E8 <OLLYDBG.data.n> 69 00 00 00 i...

0049E4B7 |. 3B05 E8784D00 |CMP EAX, DWORD PTR DS:[<data.n>]

table belongs to table of allocated memory

004D77E0 <OLLYDBG.hw> 00 00 00 00 54 61 62 6C 65 20 6F 66 20 61 6C 6C ....Table of all
004D77F0 6F 63 61 74 65 64 20 6D 65 6D 6F 72 79 00 00 00 ocated memory...


typedef struct t_table { // Window with sorted data and bar
HWND hw; // Handle of window or NULL
t_sorted data; // Sorted data


typedef struct t_sorted { // Descriptor of sorted table
char name[MAX_PATH]; // Name of table, as appears in error
int n; // Actual number of entries

max_path == 0x104

eax is count

there doesnt seem to be any infinite loop from what you posted

count is increasing from 0 to your actual entry 0xb8d and when it reaches b8d it will get out it cannot loop infinitely unless otherwise something is screwing the count for ever

count is increased a few lines before in some cases otherwise it is initialised to 0 in all other cases

you are probably not in any bug from what i see



0049E4AD |> \FF45 F8 |INC DWORD PTR SS:[EBP-8] <--------------------- increased
0049E4B0 |. 8345 E0 48 |ADD DWORD PTR SS:[EBP-20], 48
0049E4B4 |> 8B45 F8 MOV EAX, DWORD PTR SS:[EBP-8] <---------------- accessed
0049E4B7 |. 3B05 E8784D00 |CMP EAX, DWORD PTR DS:[<data.n>] <------- compared

0049E263 |. 33D2 XOR EDX, EDX ; OLLYDBG.<ModuleEntryPoint> <---- zeroed
0049E265 |. 8955 F8 MOV DWORD PTR SS:[EBP-8], EDX ; OLLYDBG.<ModuleEntryPoint> initilaised to zero
0049E268 |. E9 47020000 JMP OLLYDBG.0049E4B4

You're right. I thought there was the problem because a 'Execute till return' took more than I waited. Actually this routine runs normally.

But it keeps being recalled. From what I see now, WinProc keeps being recalled with WM_USER+75.

I can't trace more because WinProc returns to user32, which stops with an INT 2B.

What message is that?


og.

int 2b is nt!kiCallBackReturn

int 2e is nt!KiSystemService (obsolete in newer processers which use SysEnter)

both are entry points from user mode to kernel mode

int 2b is used by user32.dll to deal with win32k.sys system calls ((ServiceId == eax) > 0x1000)

you should be able to trace when it finishes its work and returns back to user mode try taking a look at NtContinue() and find the Context->eip you should be able to guess and break on return

Sorry, I didn't mean the interrupt, but the windows message (WM_USER+75). And actually, this start happening after the first time I enable one patch, and continues to happen even if I disable it afterwards.

From what I see the sub at 0x0045A41C is the one sending the message. It seems to be the callback from EnumChildWindows, which is called at 0x0045A4A6. The never ending loop is the one in the calling routine:

004610DF |> \83BC24 A80000>|CMP DWORD PTR SS:[ESP+A8],0
004610E7 |. 74 1A |JE SHORT OLLYDBG.00461103

This cmp always fails. Or almost always... It takes a long time before the jump occurs. I mean this because I discovered that setting Olly's process priority to low in task manager and waiting some time eventually makes the loop finish... Maybe this loop is waiting for something on the debugged process?

I'm still looking for a solution, og.

wm_user+ 0x75 == WM_USER_CHMEM range of debggees memory changed

why dont you open the plugin.h in and see the #defines ???

if you program is selfmodifying itself then ollydbg will record all those patches in its list

and it can hold a maximum of 0x1000 patches in its list then it will over flow and loose the first patch and so on

so at any given time you can access the last 0x1000 patches (that was done by you or by the program itself)

a circular buffer