51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd
can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message...
A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle
__________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr
On Fri, Sep 28, 2001 at 11:16:40AM +0200, Eric Pouech wrote:
51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd
can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message...
Nope (or maybe I don't get your point). Most probably it's the standard CreateProcess(), WaitForSingleObject() combo to wait for successful program execution or so (which gets confirmed by the close address range between these two function calls). --> search.microsoft.com "CreateProcess WaitForSingleObject" for a description.
Andreas Mohr wrote:
On Fri, Sep 28, 2001 at 11:16:40AM +0200, Eric Pouech wrote:
51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd
can you check that at this point (DWORD*)0x403faec4 points to the handle of the event created above ? (0x7C IIRC) if it's the case, it means that the started program rely on some messages order to do some stuff the expected behavior would be for the second program to set the event (7c) under certain circumstances, which shall be triggered from a given message...
Nope (or maybe I don't get your point). Most probably it's the standard CreateProcess(), WaitForSingleObject() combo to wait for successful program execution or so (which gets confirmed by the close address range between these two function calls).
well, if I analyse the trace: 1844 08068938:Call kernel32.CreateEventA(00000000,00000001,00000000,100192a0 "TKMESG response trigger") ret=100168c1 1845 08068938:Ret kernel32.CreateEventA() retval=0000007c ret=100168c1 ... 51123 08068938:Call kernel32.ResetEvent(0000007c) ret=100169fd 51124 08068938:Ret kernel32.ResetEvent() retval=00000001 ret=100169fd +++ 0x7C is a handle to an event (and still valid at this point)
51125 08068938:Call kernel32.CreateProcessA(00000000,10019364 "tkwdog.exe",00000000,00000000,00000000,04000000,00000000,00000000,405f6b7c,405f6b6c) ret=10016a23 51126 fixme:module:CreateProcessA (D:\cae\pasic90\scs\TKWDOG.EXE,...): CREATE_DEFAULT_ERROR_MODE ignored 51127 fixme:pthread_kill_other_threads_np 51128 FIXME:pthread_rwlock_rdlock 51129 FIXME:pthread_rwlock_unlock 51130 FIXME:pthread_rwlock_rdlock 51131 FIXME:pthread_rwlock_unlock 51132 08068938:Ret kernel32.CreateProcessA() retval=00000001 ret=10016a23 51133 08068938:Call kernel32.WaitForSingleObject(0000007c,ffffffff) ret=10016a4d +++ the process that called CreateProcess waits on 0x7C, which is still the event above, and not a process handle, and then blocks forever 51134 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000001 ret=406c7efd 51135 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51136 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51137 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) 51138 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_NCHITTEST,wp=00000000,lp=010b01ac) retval=00000001 51139 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) 51140 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_SETCURSOR,wp=00010020,lp=02000001) retval=00000276 51141 096d4e18:Call window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) 51142 096d4e18:Ret window proc 0x40a134e0 (hwnd=00010020,msg=WM_MOUSEMOVE,wp=00000000,lp=010b01ac) retval=00000000 51143 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=406c7b80 51144 096d4e18:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=406c7b80 51145 096d4e18:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403faec4,ffffffff,00000000,00000000) ret=406c7efd
so I assume that thread 096d4e18 (in line 51145) should wait on a specific object too
however, what I don't know is what 096d4e18 is (thread of same process or newly created thread). looks more like and old thread but... on the other hand, since createprocess is called without the inherit flag and that no argument are given on the command line, the newly created process shouldn't wait on this event (0x7C), unless it opens the event with its name (Uwe, is there something like that after line 51145 ?), or there's a mess in message sending/processing (or wait for a window creation) that doesn't take place
A+
"eric" == eric pouech eric.pouech@wanadoo.fr writes:
... eric> however, what I don't know is what 096d4e18 is (thread of same eric> process or newly created thread). looks more like and old thread eric> but... on the other hand, since createprocess is called without eric> the inherit flag and that no argument are given on the command eric> line, the newly created process shouldn't wait on this event eric> (0x7C), unless it opens the event with its name (Uwe, is there eric> something like that after line 51145 ?), or there's a mess in eric> message sending/processing (or wait for a window creation) that eric> doesn't take place
This TKWDOG is some strange process. Starting is seperatly on WinXX doesn't give any visible output ( beside some window flashing up short and then vanishing again), but the taskmanager shows it running. I guess that this TKWDOG belongs to the license checking of that progarms (Synario SCS, Xilinux seems to use them too). TKWDOG has CreateProcess call(s?) too. I guess that TKWDOG is supposed to spwawn another process and finish and I suspect that this doen't happen in wine. Have to dig deeper when I find time...
Bye
On Fri, Sep 28, 2001 at 07:22:37PM +0200, Uwe Bonnes wrote:
"eric" == eric pouech eric.pouech@wanadoo.fr writes:
... eric> however, what I don't know is what 096d4e18 is (thread of same eric> process or newly created thread). looks more like and old thread eric> but... on the other hand, since createprocess is called without eric> the inherit flag and that no argument are given on the command eric> line, the newly created process shouldn't wait on this event eric> (0x7C), unless it opens the event with its name (Uwe, is there eric> something like that after line 51145 ?), or there's a mess in eric> message sending/processing (or wait for a window creation) that eric> doesn't take place
This TKWDOG is some strange process. Starting is seperatly on WinXX doesn't give any visible output ( beside some window flashing up short and then vanishing again), but the taskmanager shows it running. I guess that this TKWDOG belongs to the license checking of that progarms (Synario SCS, Xilinux seems to use them too). TKWDOG has CreateProcess call(s?) too. I guess that TKWDOG is supposed to spwawn another process and finish and I suspect that this doen't happen in wine. Have to dig deeper when I find time...
TK...(W)atch(DOG) ?
That would make quite some sense why it does some event waiting and stuff. I didn't analyze it further, though.
-
Andreas Mohr -
Eric Pouech -
eric pouech -
Uwe Bonnes