Hi Alexandre, A user recently reported another app that doesn't work due to Armadillo copy protection. This scheme requires SetThreadContext/GetThreadContext to work properly and currently they do not. These two functions require the thread to be suspended, therefore they always return a bogus context (blocking on a wineserver wait pipe). I wrote a patch for this a while ago: http://navi.cx/svn/misc/trunk/winekb/patches/thread-context.patch However you felt it had races in it. There were two possible races I could see: - The race between suspending the thread and the sigcontext being uploaded. This was not a problem with my patch as Get/SetThreadContext loop. - A race where you can call SuspendThread again before the SIGUSR1 handler has completed. I believe this was the sticking point last time, no? But I can't see how this can happen because SIGUSR1 is blocked while it's being handled. So in the following sequence: PROCESS A: SuspendThread() PROCESS A: GetThreadContext() PROCESS B: SIGUSR1 PROCESS B: upload sigcontext PROCESS B: block PROCESS A: GetThreadContext() returns PROCESS A: ResumeThread PROCESS B: unblock, download sigcontext, restore, finish I do not see where the races are. Could you please re-examine this patch and let me know if there are any more problems with it? Dealing with the set/thread context operations in SIGUSR1 makes sense because they are only allowed when the target thread is suspended. thanks -mike