[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
Wed Jan 30 15:21:12 CST 2008


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





--- Comment #18 from Anastasius Focht <focht at gmx.net>  2008-01-30 15:21:08 ---
Created an attachment (id=10535)
 --> (http://bugs.winehq.org/attachment.cgi?id=10535)
patch which fixes another .net 1.1 crash by adding CoGetContextToken stub

Hello again,

well I tracked down the remaining major .NET 1.1 installation crashes,
preventing the installer from finishing successfully. Enjoy.

After applying previous activation context patch
(http://bugs.winehq.org/attachment.cgi?id=10372) there is another crash
happening when the regsvcs.exe tool is spawned from installer.
You can provoke the crash by manually running the tool after killing the
installer.

--- snip ---
..
Microsoft (R) .NET Framework Services Installation Utility Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002.  All rights reserved.

fixme:shell:URL_ParseUrl failed to parse L"x"

The following installation error occurred:
1: Assembly not found: 'x'.
wine: Unhandled privileged instruction at address 0x75ece7c5 (thread 0014),
starting debugger...
Unhandled exception: privileged instruction in 32-bit code (0x75ece7c5).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:75ece7c5 ESP:0034f998 EBP:0034f9d0 EFLAGS:00210216(   - 00      -RIAP1)
 EAX:75ece72e EBX:00000000 ECX:0013e8d0 EDX:0034f9cc
 ESI:80004005 EDI:00009c40
Stack dump:
0x0034f998:  00009c40 80004005 0034f9d0 0034f9b8
0x0034f9a8:  00000000 0034f9cc 0013e8d0 75ece72e
0x0034f9b8:  791dc5f7 75ece7b8 791f0fc4 0034f9cc
0x0034f9c8:  001322d0 001322d0 0034fe1c 791dc685
0x0034f9d8:  0034f9e8 00009c40 001322d0 001322d0
0x0034f9e8:  00000001 001322d0 00000002 791b3ce4
Backtrace:
=>1 0x75ece7c5 dll_cs_debug+0x5() in ole32 (0x0034f9d0)
  2 0x791dc685 in mscorwks (+0x2c685) (0x0034fe1c)
  3 0x791f9208 in mscorwks (+0x49208) (0x0034fe2c)
  4 0x7921d1fb in mscorwks (+0x6d1fb) (0x0034feb8)
  5 0x7921d2b6 in mscorwks (+0x6d2b6) (0x0034fee8)
  6 0x791c6f1a in mscorwks (+0x16f1a) (0x0034ff08)
  7 0x7b87195e start_process+0xee(arg=0x0)
[/usr/local/src/wine-git/dlls/kernel32/process.c:883] in kernel32 (0x0034ffe8)
  8 0x60024567 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x75ece7c5 dll_cs_debug+0x5 in ole32: outl      %eax,$0xec
--- snip ---

This was a bit nasty to track down due to usage of undocumented windows
structures.
The crash happens because .NET code peeks into undocumented (?) areas of OLE
Apartment structure and happily uses the data found there in ways not intended. 

I condensed the relevant app code and added some comments

--- snip app code #1 ---
..
mov     eax, large fs:18h  ; get the TEB address
mov     eax, [eax+0F80h]   ; offset of COM TLS structure -> OLE apartment
test    eax, eax
jz      short _ole_not_initialized
cmp     dword ptr [eax+38h], 0 ; pApartment->some_member == NULL ?
jz      short _some_member_null
mov     eax, large fs:18h
mov     eax, [eax+0F80h]
mov     eax, [eax+38h]
..
--- snip app code #1 ---

My guess is wine's OLE apartment structure layout defined in
"dlls/ole32/compobj_privare.h" most likely does not match windows layout.

Due to that mismatch, pApartment+0x38h is referenced as "valid" data (ptr) and
used in an interface call manner, leading to crash:

--- snip app code #2 ---
..
mov     ecx, [eax] ; eax = pApartment->some_member (from previous snippet #1)
lea     edx, [ebp-4] ; var
push    edx
push    offset _some_data
push    eax
call    dword ptr [ecx] ; looks like iface/vtable->member( ...)
--- snip app code #2 ---

*boom* at first instructions pointed by ecx ... obviously.

One way to fix this nasty code would be to adjust wine's "apartment" struct in
a way that it contains NULL at that specific offset, preventing further usage.

Fortunately I found another much cleaner way to get out of this brain damage
without guessing/mimicking windows data structure offsets.

It seems .NET devs used a second method for retrieving the data, which works in
newer windows versions (according to MSDN from win2K up).
This second method was not obvious because only a simple flag was checked at
the time the shutdown code ran.
This flag had the special meaning that a specific API was available:
CoGetContextToken() - exported by ole32.
This "newer api available" flag was initialized at app startup when it checked
for the export.
If that export exists (flag), this function is called instead of above code
(app code #1).

CoGetContextToken is documented here:
http://msdn2.microsoft.com/en-us/library/ms679665(VS.85).aspx

I added a simple stub to ole32 (returning E_NOTIMPL) and it worked. No crash
;-)

With the attached "CoGetContextToken" stub patch applied the installation
proceeds and finishes

Near the end of installation there is another (rather harmless) crash in
installer when registering ASP.NET (IIS) helper components.

--- snip ---
wine: Unhandled exception 0xc06d007e at address 0x7b8414e0 (thread 003f),
starting debugger...
Unhandled exception: 0xc06d007e in 32-bit code (0x7b841558).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
 EIP:7b841558 ESP:0034f888 EBP:0034f8ec EFLAGS:00200212(   - 00      - -IA1)
 EAX:7b82c201 EBX:7b8ae084 ECX:00000000 EDX:79e90e60
 ESI:79e90e60 EDI:00000000
Stack dump:
0x0034f888:  0034f960 00000004 0034f8a8 7ffd8c00
0x0034f898:  c06d007e 00000000 00000000 7b8414e0
0x0034f8a8:  00000001 0034f910 79e90e60 00000000
0x0034f8b8:  0034f8d8 7b863163 7ffd8c00 00000000
0x0034f8c8:  00000000 00000000 7b863129 7b8ae084
0x0034f8d8:  0034f8f8 7b86319d 79e61310 00000000
Backtrace:
=>1 0x7b841558 RaiseException+0x78(code=0xc06d007e, flags=0x0,
nbargs=0x79e90e60, args=0x34f960)
[/usr/local/src/wine-git/dlls/kernel32/except.c:85] in kernel32 (0x0034f8ec)
  2 0x79e9082c in aspnet_isapi (+0x3082c) (0x0034f954)
  3 0x79e8fd99 in aspnet_isapi (+0x2fd99) (0x0034fa04)
  4 0x00000000 (0x00000000)
--- snip ---

You can fix this by placing native "loadperf.dll" from windows install into
your wine system32 directory.

Though not perfect (some issues left) the installer now finishes successfully.

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