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

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

Summary: regtlib.exe from .NET 1.1's dotnetfx.exe installer
                    crashes with heap problem
           Product: Wine
           Version: CVS/GIT
          Platform: Other
               URL: http://www.microsoft.com/downloads/details.aspx?displayl
                    ang=en&FamilyID=262D25E3-F589-4842-8157-034D1E7CF3A3
        OS/Version: other
            Status: NEW
          Keywords: download, Installer
          Severity: normal
          Priority: P2
         Component: wine-ole
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

This one was mentioned at the end of bug 5358, but I only just
now got around to isolating it.  I ran into this in the context of bug
5358 (Microsoft Dynamics GP Trial).  That app comes with dotnetfx.exe,
which fails to install.  The problem is a heap corruption or something
in our COM implementation, as it fails slightly faster and cleaner with
WINEDEBUG=warn+heap, and succeeds with native dcom98.
The problem can be reproduced with the .net 1.1 installer downloadable
from Microsoft.  This has the same md5 signature as the one on the cdrom.

Oddly, when I first hit this it took ten seconds, the second
time it took half an hour, no idea why the speed difference.
I think it might be WINEDEBUG=warn+heap makes it run slow,
that's another sign of an uninitialized variable.

Here's the script I used to demonstrate the bug.  I'll attach fail.log.

set -x
wineserver -k
rm -rf .wine
export WINE=$HOME/wine-git/wine
export WINEPREFIXCREATE=$HOME/wine-git/tools/wineprefixcreate
sh ~/bin/winetricks fakeie6

# install .net 1.1
test -f dotnetfx.exe || wget
http://download.microsoft.com/download/a/a/c/aac39226-8825-44ce-90e3-bf8203e...
# fwiw, md5sum dotnetfx.exe is 52456ac39bbb4640930d155c15160556

# 
WINEDEBUG=warn+heap,+process $WINE dotnetfx.exe

# Here's how it fails:
#trace:process:CreateProcessW app
L"c:\windows\system32\URTTEMP\regtlib.exe" cmdline
L""c:\windows\system32\URTTEMP\regtlib.exe"
"c:\windows\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb""
#warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic
for 0x11a1a8
#wine: Unhandled page fault on read access to 0xaaaaaaba at address 0x7ec89683
(thread 0023), starting debugger...

# OK, so run just the failing command:
WINEDEBUG=warn+heap,+ole $WINE c:\windows\system32\URTTEMP\regtlib.exe
c:\windows\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb > fail.log 2>&1

# Yep, that fails very nicely -- but passes with native dcom98!
sh ~/bin/winetricks dcom98
WINEDEBUG=warn+heap,+process $WINE c:\windows\system32\URTTEMP\regtlib.exe
c:\windows\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb > ok.log 2>&1

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

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

--- Comment #1 from Dan Kegel   2007-10-22 07:28:38 ---
gaah, the microsoft dynamics gp trial bug is bug 8178.

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

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

--- Comment #2 from Dan Kegel   2007-10-22 07:34:36 ---
Created an attachment (id=8710)
 --> (http://bugs.winehq.org/attachment.cgi?id=8710)
warn+heap,+ole of regtlib.exe c:\w
indows\Microsoft.NET\Framework\v1.1.4322\mscorlib.tlb

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

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

--- Comment #3 from Dan Kegel   2007-10-22 07:35:29 ---
The slowdown might also have been because of a runaway
Installer.exe from a previous run.  Watch out for that.

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

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

James McKenzie  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

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

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

--- Comment #4 from James McKenzie   2007-11-22 09:47:00 ---
Dan:
When I attempt to run this on a Mac PowerBookPro with MacOSX 10.4.10 installed
I get a very interesting dump.  Attached is the WINEDEBUG=warn+heap,+process
$WINE dotnetfx.exe log file.
James

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

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

--- Comment #5 from James McKenzie   2007-11-22 09:50:21 ---
Created an attachment (id=9286)
 --> (http://bugs.winehq.org/attachment.cgi?id=9286)
warn+heap,+process dotnetfx.exe log file with crashdump on regtlib.exe
execution

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

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

--- Comment #6 from James McKenzie   2007-11-22 10:36:08 ---
Dan:
I duplicated what you did and yes, dcom98 does work.  Now to see if .NET 1.1
fully installed.

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

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

--- Comment #7 from James McKenzie   2007-11-22 21:10:07 ---
*** Bug 10126 has been marked as a duplicate of this bug. ***

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

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

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |1.0.0

--- Comment #8 from Dan Kegel   2007-11-22 23:32:30 ---
Seems important enough for 1.0.

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

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

--- Comment #9 from Rob Shearman   2007-11-27 13:17:41 ---
Created an attachment (id=9372)
 --> (http://bugs.winehq.org/attachment.cgi?id=9372)
Fix multiple frees of the same piece of data

Should fix the crash Dan reported. Also sent to wine-patches.

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

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

--- Comment #10 from James McKenzie   2007-12-04 07:57:23 ---
Bug fixed in 0.9.50, but regsvcs.exe crashes instead now on a clean .wine.

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

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

--- Comment #11 from James McKenzie   2007-12-04 07:59:34 ---
Created an attachment (id=9485)
 --> (http://bugs.winehq.org/attachment.cgi?id=9485)
zipped log of running regsvcs.exe /bootstrapi

WINEDEBUG=+file,+relay wine
'C:\Windows\Microsoft.NET\Framework\v1.1.4322\RegSvcs.exe' /bootstrapi
zipped log file

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

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

--- Comment #12 from James McKenzie   2007-12-15 10:41:42 ---
With 0.9.51 I managed to get to the Install completed message.
I had to stop the install at
c:\windows\Microsoft.NET\Framework\v1.1.4322\RegSvcs.exe /bootstrapi
and run this command separately, which successfully completed.
Started installation a second time and it stopped again at this point, killed
process and it went through to:
c:\windows\Microsoft.NET\Framework\v1.1.4322\migpolwin.exe -migrate 1.1.4322
1.0.375
Killed off install and ran this separately and it finished successfully.
Running the install a third time resulted in a 'Install finished sucessfully'
after
killing off both the regsvcs and migpolwin processes.

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

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

--- Comment #13 from Dan Kegel   2008-01-09 17:42:12 ---
regsvcs crashes for me even if I run it standalone :-(

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

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

--- Comment #14 from James McKenzie   2008-01-09 18:18:47 ---
I will recheck if this still works with 0.9.52, it was working with 0.9.50.

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

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

--- Comment #15 from James McKenzie   2008-01-09 18:49:14 ---
Confirmed.  Regsvcs.exe does not run now :-(

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

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

--- Comment #16 from James McKenzie   2008-01-09 18:51:26 ---
Created an attachment (id=10145)
 --> (http://bugs.winehq.org/attachment.cgi?id=10145)
Error log for DotNet 1.1 installation.

Log file from .Net 1.1 installation with builtin rcprt4.dll

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

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

Ralph Prichard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

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

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

--- Comment #17 from Anastasius Focht   2008-01-19 16:13:24 ---
Created an attachment (id=10372)
 --> (http://bugs.winehq.org/attachment.cgi?id=10372)
patch which fixes .net 1.1 ActivationContextBasicInformation query crash

Hello,

well the crash seems to be related to undocumented behavior when querying for 
activation context basic info class.

--- snip ---
...
0022:trace:actctx:RtlFindActivationContextSectionString 00000001 (null) 2
L"rsaenh.dll" 0x34f0d0
0022:trace:actctx:RtlFindActivationContextSectionString 00000001 (null) 2
L"crypt32.dll" 0x34e740
0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 2
0x34f90c 48 0x34f948
0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 2
0x34f928 48 0x34f95c
0022:trace:actctx:RtlQueryInformationActivationContext 00000000 (nil) (nil) 1
0x34f9b0 8 0x34f9c0
0022:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc24531
0022:trace:seh:raise_exception  info[0]=00000000
0022:trace:seh:raise_exception  info[1]=c07e3e11
0022:trace:seh:raise_exception  eax=c07e3e10 ebx=00000000 ecx=00000000
edx=c07e3e11 esi=006d3a20 edi=7bc30c80
0022:trace:seh:raise_exception  ebp=0034f928 esp=0034f928 cs=0073 ds=007b
es=007b fs=0033 gs=003b flags=00210293
...
Backtrace:
=>1 0x7bc24531 check_actctx+0x11(h=0xc07e3e11)
[/usr/local/src/wine-git/dlls/ntdll/actctx.c:574] in ntdll (0x0034f928)
  2 0x7bc2495b RtlAddRefActivationContext+0xb(handle=0xc07e3e11)
[/usr/local/src/wine-git/dlls/ntdll/actctx.c:2292] in ntdll (0x0034f930)
  3 0x7b830c01 AddRefActCtx+0x11(hActCtx=0xc07e3e11)
[/usr/local/src/wine-git/dlls/kernel32/actctx.c:187] in kernel32 (0x0034f940)
  4 0x790598c5 in fusion (+0x198c5) (0x0034f988)
  5 0x792487fb in mscorwks (+0x987fb) (0x0034f9c4)
  6 0x7923d769 in mscorwks (+0x8d769) (0x0034fca8)
  7 0x791c6e73 in mscorwks (+0x16e73) (0x0034fee8)
  8 0x791c6ef3 in mscorwks (+0x16ef3) (0x0034ff08)
...
--- snip ---
> From what I've seen while debugging the crash wine actually returns the default

process activation context when it shouldn't
(dlls/ntdll/actctx.c:RtlQueryInformationActivationContext() ->
find_query_actctx()).

.NET crashes while doing some operations on the returned context.

The culprit seems to be calls like this:

QueryActCtxW -> RtlQueryInformationActivationContext( dwFlags = 0, hActCtx =
NULL, pvSubInstance = NULL, ulInfoClass = ActivationContextBasicInformation,
buf, sizeof(buf), &required_size);

Unfortunately MSDN doesn't tell anything about this case,
ActivationContextBasicInformation class isn't documented at all.
I wrote some tests which call this function with
ActivationContextBasicInformation class and permutated args.

The function succeeds in Windows XP Sp2 (returns TRUE) and initializes the
ACTIVATION_CONTEXT_BASIC_INFORMATION structure members to zero (preinit magic
numbers for each struct member to detect any explicit init by internal API) and
sets required size to sizeof(ACTIVATION_CONTEXT_BASIC_INFORMATION) == 8.

Attached patch fixes the problem by not returning default activation context
for ActivationContextBasicInformation info class when none of dwFlags bits are
set or input handle is NULL.
Although the patch fixes the crash, the calls with
ActivationContextBasicInformation class need some test cases to qualify for GIT
... I leave this as exercise to someone else - as usual ;-)

Regards

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

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

--- Comment #18 from Anastasius Focht   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

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

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

Alan Jackson  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

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

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

Louis Lenders  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #19 from Louis Lenders   2008-02-03 07:04:58 ---
> Though not perfect (some issues left) the installer now finishes successfully.

Yip , that's true, but while trying to run a simple .net app (i used fastmd5
again) it pops up a messagebox, that it failed to find some resources. So maybe
the install is still screwed up?

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

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

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #20 from Anastasius Focht   2008-02-03 12:44:41 ---
Hello,

--- quote ---
Yip , that's true, but while trying to run a simple .net app (i used fastmd5
again) it pops up a messagebox, that it failed to find some resources. So maybe
the install is still screwed up?
--- quote ---

That's why I said "some issues left" :-)
Registering assemblies into GAC and pre JIT-ing (ngen tool) doesn't work right
now due to a bug in shlwapi's UrlCombineW().

Because of this bug, .NET 1.x fusion loader won't find any referenced
assemblies on app startup, leading to rather cryptic "resource not found" error
message.

--- snip trace ---
..
001f:Call shlwapi.UrlCombineW(005436d8
L"C:\windows\Microsoft.NET\Framework\v1.1.4322/",0053b590
L"C:\windows\Microsoft.NET\Framework\v1.1.4322\System.dll",00544728
L"hS\0108S",0033e320,00000000) ret=7904e23d
..
001f:Ret  shlwapi.UrlCombineW() retval=00000000 ret=7904e23d
001f:Call shlwapi.UrlIsW(00544728
L"file:///C:/windows/Microsoft.NET/Framework/v1.1.4322/System.dll/",00000003)
ret=7904e250
001f:Ret  shlwapi.UrlIsW() retval=00000001 ret=7904e250
001f:Call shlwapi.UrlUnescapeW(00544728
L"file:///C:/windows/Microsoft.NET/Framework/v1.1.4322/System.dll/",00542688,0033e35c,00000000)
ret=7904e267
001f:Ret  shlwapi.UrlUnescapeW() retval=00000000 ret=7904e267
..
--- snip trace ---

The returned combined URL/path is invalid.
Fusion internally re-verifies paths before mapping dlls and rejects it.

reduced: "c:\test/" + "c:\test\mylib.dll"

wine -> "file:///c:\test\mylib.dll/" (wrong)
windows -> "file:///c:\test\mylib.dll" (correct, I wrote a small test case
and tested with Windows XP SP2).

So get that bug fixed and apps/fusion will find the requested assemblies.

--

For trace/logging purposes you can enable fusion's verbose logging:

--- snip ---
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"ForceLog"=dword:00000001
"LogResourceBinds"=dword:00000001
"LogFailures"=dword:00000001
"LogPath"="C:\Temp\FusionLogs"
--- snip ---

That will get you detailed CLR assembly search and loader logs.
Handy for diagnosing assembly loading problems.

Regards

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

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

--- Comment #21 from Dan Kegel   2008-02-22 00:02:07 ---
*** Bug 10772 has been marked as a duplicate of this bug. ***

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

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

--- Comment #22 from Dan Kegel   2008-02-25 16:46:45 ---
Alexandre says he just committed
http://winehq.org/pipermail/wine-cvs/2008-February/040705.html
which should obsolete the patch you gave in #17?

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

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

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #10372|0                           |1
        is obsolete|                            |

--- Comment #23 from Anastasius Focht   2008-02-25 18:02:39 ---
(From update of attachment 10372)
Hello,

@dank
--- quote ---
Alexandre says he just committed
http://winehq.org/pipermail/wine-cvs/2008-February/040705.html
which should obsolete the patch you gave in #17?
--- quote ---

Sure. Thats works too.

But if you allow to express my personal opinion ...

That commit might "cure" that specific bug but in overall it seems a bit
problematic to me.
Although ntdll.check_actctx is a wine internal helper, guarding it with SEH
hides bugs/gaps in ntdll activation context api which could be detected by
crashes otherwise (like the ActivationContextBasicInformation one).

Additionally it adds a good amount of access violations/exceptions (in case of
.NET) to logs/traces which makes it more difficult to track down the real
problems.
When I analyze traces/debug stuff I usually hunt for exceptions first... but
well.

Regards

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

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

--- Comment #24 from Alexandre Julliard   2008-02-26 03:36:18 ---
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.

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

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

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |8178
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Dan Kegel   2008-02-26 13:07:19 ---
This is, I think, the same as bug 11678, which is now fixed.
Microsoft Dynamics GP now installs .net 1.1 successfully.

I moved the issues from #19 and #20 into a new bug, 11742.

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

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

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

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

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

--- Comment #27 from Dan Kegel   2008-02-26 23:56:57 ---
Please do not post disassembled sections of microsoft code for any reason ever.

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

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

--- Comment #28 from Dmitry Timoshkov   2008-02-27 01:55:03 ---
(In reply to comment #27)
> Please do not post disassembled sections of microsoft code for any reason ever.

Even if that's the failing application code and not the OS one?

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

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

--- Comment #29 from Anastasius Focht   2008-02-27 04:06:00 ---
Hello,

@Dmitry Timoshkov  
--- quote ---
> Please do not post disassembled sections of microsoft code for any reason ever.

Even if that's the failing application code and not the OS one?
--- quote ---

Dan Kegel probably considers debugging *any* Microsoft produced code
(installers, apps) potentially hostile/harmful - that far extends the wine
restriction of not touching/looking at OS code.
My snippets are *application* layer snippets - I don't consider .NET Framework
a part of OS.

I mainly post short app traces/assembly/pseudo code snippets for following
reasons:

- document/show interesting problems to readers
- proof/evidence for people how stuff is accessed to justify my
conclusions/writings/patches/input for patches
- document my own work flow (bugzilla = "notepad") to be archived by
google/mailing lists

People aren't actually believing if I only write prose (good example from
recent times: "the PEB loader lock needs to be exposed").
In fact some .NET patches would never made possible .. not mentioning countless
analysis/patches from previous times.

Anyway if you really take your policy to that extent then you should also
disallow posting/attaching *any* backtraces and crashes from Microsoft related
products (installers, apps) because technically they contain disassembly
(although only a few opcode sequences from crash location).

If you really persist this way then you have lost another supporter.
I won't change my way of documenting bugs/supplying information. Period.

Regards

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

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

Ralph Prichard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]  |

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

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

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #30 from Alexandre Julliard   2008-03-07 11:28:29 ---
Closing bugs fixed in 0.9.57.

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

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|CVS/GIT                     |unspecified

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

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

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |dotnet
      Fixed by SHA1|                            |198a00bc9eeb2d2fcf5122fa8b7
                   |                            |de38bb4fb526d
          Component|ole                         |ntdll
           Hardware|Other                       |x86
            Version|unspecified                 |0.9.47.
                 OS|other                       |Linux

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

[WineHQ Bugzilla]

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

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://www.microsoft.com/do |https://web.archive.org/web
                   |wnloads/details.aspx?displa |/20090202091626/http://down
                   |ylang=en&FamilyID=262D25E3- |load.microsoft.com/download
                   |F589-4842-8157-034D1E7CF3A3 |/a/a/c/aac39226-8825-44ce-9
                   |                            |0e3-bf8203e74006/dotnetfx.e
                   |                            |xe