I got this program.. it has a two session max... i wanna defeat that..
I've pinpointed the problem to be here

004f9154 CALL DWORD PTR DS:[545E40] (olly : USER32.ShowWindow)

From here the code will run into USER32, kernel etc.
Now the 'problem' is when it returns, it doesnt do it to the successive address (004f915a), depending on whetether its successfull or not, it will return to either 004f914b (success) OR 004fd1bf (wich is the deathtrap)

Now.... I dont get how a call to user32.showwindow can have an impact on the next instruction to be executed... so to speak.. I think of it in terms of

1 do somethig
2. return
3. call 1.
4. do something else

eip = 3 and we would go 3,1,2,4 ... right ? Obviosly not .. perhaps someone has the patience to explain it to the n00b ?

the flow may not necessarily be linear it all depends on how it is coded

for example try assembling this with masm or use ollydbg inline assembing feature and step through you will see it will never reach the exitprocess

.CODE
infinite_routine:
pop edx
start:
push labeltrick
retn
labeltrick:
call infinite_routine
labelneverreach:
invoke ExitProcess,NULL
end start


here is disassembly
00401000 POP EDX
00401001 >PUSH timepass.00401007
00401006 RETN
00401007 CALL timepass.00401000
0040100C PUSH 0
0040100E CALL <JMP.&KERNEL32.ExitProcess>

does you 3,1,2,4 work on above code

as far as window creation is considered all windows will have a message loop which waits for messages if it gets notified of a message the loop checks if the message is from the window it is supposed to be or is it from some other window if it is from window that it is supposed to be then it
translates it and sends it to winproc else it will discard the message and loop again waiting for message
==============================================
v--------------------------------------------------------------------- ---------->|
|------------msg from my window --->translate--->send to winproc--->|
v
getmsg <
^
|-------------msg from other window--->|
^------------------------------------------<|
==============================================

now winproc is registered using RegisterWindowClass
this winproc will handle all messages
so you have to look in winproc to ascertain behaviour

the flow may not necessarily be linear it all depends on how it is coded

for example try assembling this with masm or use ollydbg inline assembing feature and step through you will see it will never reach the exitprocess

.CODE
infinite_routine:
pop edx
start:
push labeltrick
retn
labeltrick:
call infinite_routine
labelneverreach:
invoke ExitProcess,NULL
end start


here is disassembly
00401000 POP EDX
00401001 >PUSH timepass.00401007
00401006 RETN
00401007 CALL timepass.00401000
0040100C PUSH 0
0040100E CALL <JMP.&KERNEL32.ExitProcess>

does you 3,1,2,4 work on above code

as far as window creation is considered all windows will have a message loop which waits for messages if it gets notified of a message the loop checks if the message is from the window it is supposed to be or is it from some other window if it is from window that it is supposed to be then it
translates it and sends it to winproc else it will discard the message and loop again waiting for message
==============================================
v--------------------------------------------------------------------- ---------->|
|------------msg from my window --->translate--->send to winproc--->|
v
getmsg <
^
|-------------msg from other window--->|
^------------------------------------------<|
==============================================

now winproc is registered using RegisterWindowClass
this winproc will handle all messages
so you have to look in winproc to ascertain behaviour

omg .. my head hurts lol .. i get your point... sorta... given me some ideas..

another note ; debugging the app, sudenly i see this on the stack
VNCHOOKS.00CC15C0

What ? what's vnc doing inthere ? yes, i get got vnc running on the box... is it VNC that injects/hooks processes to better grab their graphics, or should i be worried lol ?

would you estimate you're on the right track when the 'third session' throws an ACCESSVIOLATION READING BAADF011

?? lol

Thanks to all who helped me ... especially "Ricardo Narvaja"

it turned out to be a mutex ... i simply rename it before its created to.. whatever, and all is good !!