http://bugs.winehq.org/show_bug.cgi?id=10134
--- Comment #26 from Anastasius Focht focht@gmx.net 2008-02-26 15:06:32 --- Hello,
--- snip --- The bug is that the app is accessing the internals of the activation context, and passing the magic number as a pointer. It looks like it's confusing an activation context stack frame with the actual context. Of course never returning a context at all from QueryActCtx would fix it, but I have a hard time believing that it's the correct fix. --- snip ---
What kind of information do you need for a better fix? As I said in comment #17, the culprit seems to be the following call to KERNEL32.QueryActCtxW() from app:
--- snip wine trace --- .. 0043:Call KERNEL32.LoadLibraryExW(791bd8f8 L"kernel32.dll",00000000,00000000) ret=791b7b63 0043:Ret KERNEL32.LoadLibraryExW() retval=7b820000 ret=791b7b63 0043:Call KERNEL32.GetProcAddress(7b820000,792405fc "QueryActCtxW") ret=792405e1 0043:Ret KERNEL32.GetProcAddress() retval=7b829fac ret=792405e1 0043:Call KERNEL32.QueryActCtxW(00000000,00000000,00000000,00000001,0034f9b0,00000008,0034f9c0) ret=7924064e 0043:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 1 0x34f9b0 8 0x34f9c0 0043:Ret KERNEL32.QueryActCtxW() retval=00000001 ret=7924064e 0043:Call shlwapi.StrCmpW(790413f8 L"SXS_ACTIVATION_CONTEXT",79248834 L"SXS_ACTIVATION_CONTEXT") ret=7904136c .. --- snip wine trace ---
The parameters of the call are hard coded (commented for you pleasure)
--- snip app call parameter setup --- .. xor ebx, ebx .. push 8 pop edi .. lea eax, [ebp-4] ; pcbLen push eax push edi ; cbBuff = 8 = sizeof(ACTIVATION_CONTEXT_BASIC_INFORMATION) lea eax, [ebp-14h] ; pvBuff push eax push 1 ; ulClass = 1 = ActivationContextBasicInformation push ebx ; pvSubInst = NULL push ebx ; hActCtx = NULL push ebx ; dwFlags = 0 call QueryActCtxW .. --- snip app call parameter setup ---
I wrote a test client calling the same function on XP with same parameters. There is no activation context handle returned back in basic info structure (both members are cleared). Though I admit that I don't understand why this query is actually done when no info is returned.
Wine instead returns default process actctx with catastrophic result ... Later the code goes as follows (only relevant parts) :
--- snip app evaluation of returned data --- .. mov eax, [ebp-8] ; pvBuff (PACTIVATION_CONTEXT_BASIC_INFORMATION) mov eax, [eax] ; pvBuff->hActCtx cmp eax, ebx ; hActCtx == NULL ? jz no_actctx_handle .. push 4 ; sizeof(HANDLE) push eax ; hActCtx .. call some_sub_xxx .. no_actctx_handle: .. ret --- snip app evaluation of returned data ---
--- snip app uses context handle --- some_sub_xxx: .. mov eax, [ebp+10h] ; hActCtx (from previous snippet) mov eax, [eax] ; whoops ... probably not intended (ActCtx->magic) cmp eax, 0FFFFFFFFh jz go_home push eax call AddRefActCtx ; *boom* .. --- snip app uses context handle ---
--- snip dlls/ntdll/actctx.c --- typedef struct _ACTIVATION_CONTEXT { ULONG magic; int ref_count; struct file_info config; struct file_info appdir; struct assembly *assemblies; unsigned int num_assemblies; unsigned int allocated_assemblies; } ACTIVATION_CONTEXT; --- snip dlls/ntdll/actctx.c ---
Maybe there is one indirection missing, like you said (handle -> &actctx vs. handle -> frame ptr -> acttcx).
I've never seen queries with such parameters in regular apps. Maybe this is just a special thing to .NET framework/apps and maybe other OS components. I don't like the road .NET sometimes takes either (directly accessing/peeking into internal/undocumented windows structures) ... it makes it a somewhat tedious task to get fully working .NET support into wine. Though in the long run it will actually help/boost wine.
Anyway I still think fixing QueryActCtxW() (and not using SEH) would be the better solution regardless what kind of brain damage is present ...
But in the end you are the boss.
Regards