[Bug 10134] regtlib.exe from .NET 1.1's dotnetfx. exe installer crashes with heap problem

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Feb 26 15:06:34 CST 2008


http://bugs.winehq.org/show_bug.cgi?id=10134





--- Comment #26 from Anastasius Focht <focht at 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


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list