http://bugs.winehq.org/show_bug.cgi?id=17135
Summary: virtual write watches cause problems in multithreaded
.NET code (simultaneous GC heap allocations)
Product: Wine
Version: 1.1.13
Platform: Other
URL: http://www.microsoft.com/downloads/details.aspx?FamilyID
=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=18992)
--> (http://bugs.winehq.org/attachment.cgi?id=18992)
Winedbg session of migpolwin
Hello,
while testing some older .NET 1.x stuff I encountered mysterious (rare) install
errors which did not happen until recently.
The problem is caused by the addition of virtual write watch support
(technically a regression).
--- snip ---
$ git bisect good
af8bb2e9222a79cc6ef2fa22c4eac75122eac5de is first bad commit
commit af8bb2e9222a79cc6ef2fa22c4eac75122eac5de
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Nov 25 12:07:35 2008 +0100
ntdll: Add support for virtual write watches.
:040000 040000 99d51bad8c4d6a32417c8ed53edeee43370bd463
ffc461379b1aa89527cacadc5555d0d9eaa77a56 M dlls
:040000 040000 eb2d3dc044c246182b50c6fd4650ce0242ad4f4b
3523f1756ea054c4c3ad26f78a8161c46330bb5f M include
:040000 040000 e4ba31cd1e60853ad020f15bef20883951424793
4f34f4d2a0e87e51a7d53ed15a39b718bbaaa856 M server
$ wine --version
wine-1.1.9-66-g81b9ca5
--- snip ---
Unfortunately tracking the problem down is not easy as it exhibits only
sporadically in .NET Framework 1.0 and 1.1 installer.
Multi-core CPU/machines seem to escalate this problem further.
Basically you have to loop .NET Framework 1.1 install again and again in clean
WINEPREFIX until you hit exception dialog.
--- snip ---
$ wine --version
wine-1.1.13-272-gf63d950
--- snip ---
--- loop ---
$ wineserver -k
$ rm -rf .wine
$ wine dotnetfx11.exe /q:a /c:"install.exe /qb /l"
--- loop ---
The installer is almost at its end, running the .NET 1.0 -> 1.1 migration tool.
When the exception dialog pops up, dismiss the message with "OK", the installer
will finish.
Manually run the migration tool thereafter.
If the installer finished without exception dialog, there is no use in manually
re-running the migration tool, it will skip the steps which will lead to
exception.
Some +tid,+seh,+relay,+virtual,+ntdll trace log (multithreaded
execution/output):
Both threads of interest causing faults almost simultaneously:
--- snip ---
...
0032:trace:virtual:virtual_handle_fault 0x47ca000, 1
002f:trace:virtual:virtual_handle_fault 0x47cbffc, 1
0032:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47ca000-0x47cafff
0032:trace:virtual:VIRTUAL_DumpView View: 0x4750000 - 0x674ffff (valloc)
0032:trace:virtual:VIRTUAL_DumpView 0x4750000 - 0x47cafff c-rw-
0032:trace:virtual:VIRTUAL_DumpView 0x47cb000 - 0x47d1fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView 0x47d2000 - 0x574ffff --rw-
0032:trace:virtual:VIRTUAL_DumpView 0x5750000 - 0x5755fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView 0x5756000 - 0x5761fff c-rw-
0032:trace:virtual:VIRTUAL_DumpView 0x5762000 - 0x674ffff --rw-
002f:trace:virtual:VIRTUAL_SetProt 0x47cb000-0x47cbfff c-rw-
002f:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47cb000-0x47cbfff
002f:trace:virtual:VIRTUAL_DumpView View: 0x4750000 - 0x674ffff (valloc)
002f:trace:virtual:VIRTUAL_DumpView 0x4750000 - 0x47cbfff c-rw-
002f:trace:virtual:VIRTUAL_DumpView 0x47cc000 - 0x47d1fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView 0x47d2000 - 0x574ffff --rw-
002f:trace:virtual:VIRTUAL_DumpView 0x5750000 - 0x5755fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView 0x5756000 - 0x5761fff c-rw-
002f:trace:virtual:VIRTUAL_DumpView 0x5762000 - 0x674ffff --rw-
0032:trace:seh:raise_exception code=c0000005 flags=0 addr=0x791b3e04
ip=0x791b3e04 tid=0032
0032:trace:seh:raise_exception info[0]=00000001
0032:trace:seh:raise_exception info[1]=047cb000
0032:trace:seh:raise_exception eax=00000000
ebx=047c002f:trace:virtual:VIRTUAL_SetProt 0x47cc000-0x47ccfff c-rw-
002f:trace:virtual:VIRTUAL_SetProt handling write watch on 0x47cc000-0x47ccfff
--- snip ---
Both "VIRTUAL_SetProt handling write watch" (VIRTUAL_SetProt -> if
(view->protect & VPROT_WRITEWATCH)) and "virtual_handle_fault" TRACE msg were
added by me to show the code flow before the exception.
Thread 0x2f ought to fix the problem by "accidentally" resetting the write
watch also for code executed in thread 0x32.
Attached is a winedbg session showing the same problem.
Only threads 0x18 and 0x1B are of interest.
Thread 0x18 is actually zeroing GC heap memory at this point, causing the
fault.
I first thought about a race condition in fault handler while adjusting vm page
protection but multiple threads causing faults/page protection changes should
be serialized by "csVirtual" critical section.
Just to be sure, my Linux kernel:
--- snip ---
2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
--- snip ---
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.
http://bugs.winehq.org/show_bug.cgi?id=9738
Summary: Fails to Install .Net Framework 1.1
Product: Wine
Version: 0.9.3.
Platform: Macintosh
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: wine-net
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: youngjova(a)optonline.net
Created an attachment (id=8171)
--> (http://bugs.winehq.org/attachment.cgi?id=8171)
Error Log
Microsoft .Net Framework 1.1 setup has ended prematurely.
I was trying to install a program from UniversalRemote.com. Everything
downloaded fine but it couldn't intall.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10772
Summary: ChurchWindows 2006 Trial fails on .net 1.1 installer?
Product: Wine
Version: CVS/GIT
Platform: Other
URL: http://churchwindows.com
OS/Version: other
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: wine-dotnet
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
Installer seems to hang. Console shows:
...
Registration of
c:\windows\Microsoft.NET\Framework\v1.1.4322\Microsoft.Vsa.Vb.CodeDOMProcessor.tlb
successful.
fixme:virtual:NtAllocateVirtualMemory MEM_WRITE_WATCH type not supported
fixme:advapi:RegisterEventSourceA ((null),".NET Runtime"): stub
fixme:advapi:RegisterEventSourceW (L"",L".NET Runtime"): stub
fixme:advapi:ReportEventW
(0xcafe4242,0x0001,0x0000,0x00000000,(nil),0x0001,0x00000000,0x7e31990c,(nil)):
stub
err:eventlog:ReportEventW L".NET Runtime version 1.1.4322.573- RegSvcs.exe -
Common Language Runtime Debugging Services: Application has generated an
exception that could not be handled....
Unhandled Exception: StackOverflowException.
wine: Unhandled page fault on read access to 0xc07e3e11 at address 0x7ef83d41
(thread 0041), starting debugger...
Backtrace:
=>1 0x7ef83d41 check_actctx+0x11(h=<is not available>)
[dlls/ntdll/actctx.c:574] in ntdll (0x0034f928)
2 0x7ef8416b RtlAddRefActivationContext+0xb(handle=0xc07e3e11)
[dlls/ntdll/actctx.c:2292] in ntdll (0x0034f930)
3 0x7ee3fe91 AddRefActCtx+0x11(hActCtx=0xc07e3e11)
[dlls/kernel32/actctx.c:187] in kernel32 (0x0034f940) ...
0x7ef83d41 check_actctx+0x11 [dlls/ntdll/actctx.c:574] in ntdll: cmpl
$0xc07e3e11,0x0(%edx)
574 switch (actctx->magic)
Pressing ^C in the console lets the installer seem to
complete, but it hangs at the 'finish' dialog, and you have
to kill wineserver.
To start up, the app needs mfc40 (which is harder now that
the url winetricks uses is offline; anyone know a new one?)
Don't know what happens if you have mfc40, haven't grabbed a copy.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10126
Summary: .Net 1.1 fails on install in regsvcs.exe
Product: Wine
Version: 0.9.47.
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-dotnet
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jjmckenzie51(a)sprintpcs.com
Created an attachment (id=8695)
--> (http://bugs.winehq.org/attachment.cgi?id=8695)
Dump log from regsvcs.exe error.
While attempting to install .Net 1.1 regsvcs.exe caused a coredump error.
Attached is the dump log.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
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: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
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-bf8203…
# 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
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=15748
Summary: .NET 1.1's dotnetfx fails to install, aborts when it
can't stop the msi service?
Product: Wine
Version: 1.1.7
Platform: Other
OS/Version: other
Status: NEW
Keywords: download, Installer, regression
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
winetricks dotnet11, or any other way of running the .net 1.1
runtime installer, seems to abort for me with a dialog saying
An error occurred while Windows Installer was initializing...
C:\\windows\\temp\\dotNetFx.log says
StopDarwinService() - Call to ControlService() failed!
GetLastError() returned: <183>
183 is ERROR_ALREADY_EXISTS.
Wine's log says
003d:Call advapi32.OpenServiceA(0013c4f0,00402740 "msiserver",00000024)
ret=0040b496
...
trace:service:OpenServiceW returning 0x135278
003d:Ret advapi32.OpenServiceA() retval=00135278 ret=0040b496
003d:Call advapi32.QueryServiceStatus(00135278,0033f114) ret=0040b50f
trace:service:QueryServiceStatus 0x135278 0x33f114
trace:service:QueryServiceStatusEx 0x135278 0 0x33ef64 36 0x33ef88
...
003d:Ret advapi32.QueryServiceStatus() retval=00000001 ret=0040b50f
003d:Call advapi32.ControlService(00135278,00000001,0033f158) ret=0040b58d
trace:service:ControlService 0x135278 1 0x33f158
...
003d:Ret advapi32.ControlService() retval=00000000 ret=0040b58d
003d:Call KERNEL32.CreateFileA(00530ab0
"C:\\windows\\temp\\dotNetFx.log",40000000,00000003,0033ef1c,00000004,00000080,00000000)
ret=00410106
...
003d:Call user32.MessageBoxA(00000000,0033cec8 "An error occurred while Windows
Installer was initializing. Setup will now close.",0033dfcc "Microsoft .NET
Framework Setup",00000010) ret=0040a331
It seems to be aborting because it can't stop the msiserver service?
Which is strange, since it probably wasn't running...
I wonder if a conformance test for ControlService would be informative.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=33391
Bug #: 33391
Summary: Microsoft .NET Framework Version 2.0 x64 installer
prerequisite check fails (incorrect "VersionNT64" msi
property value)
Product: Wine
Version: 1.5.28
Platform: x86-64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello folks,
while investigating some 64-bit application installer I found a problem with
"VersionNT64" msi installer property.
--- snip ---
0027:trace:msi:MSI_EvaluateConditionW L"( ((VersionNT64 < 502) OR (VersionNT64
= 502 AND WindowsBuild < 3506)) )"
...
0027:trace:msi:MSI_EvaluateConditionW 1 <- L"( ((VersionNT64 < 502) OR
(VersionNT64 = 502 AND WindowsBuild < 3506)) )"
0027:trace:msi:ACTION_PerformAction Performing action
(L"CA_Check64OS.3643236F_FC70_11D3_A536_0090278A1BB8")
...
--- snip ---
It's ok to fail in Windows XP mode (VersionNT64 should be 501) but to my
surprise it also failed in later WinVer settings (Windows 2003, ...).
The reason is a "reuse" of string buffer which ought to hold WinVer encoded as
MajorVersion * 100 + MinorVersion.
Source:
http://source.winehq.org/git/wine.git/blob/40f3a9fa590b1e4ab785509bb389efbe…
--- snip ---
671 static VOID set_installer_properties(MSIPACKAGE *package)
672 {
673 WCHAR *ptr;
674 OSVERSIONINFOEXW OSVersion;
675 MEMORYSTATUSEX msex;
676 DWORD verval, len;
677 WCHAR pth[MAX_PATH], verstr[11], bufstr[22];
...
860 /* set the os things */
861 OSVersion.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEXW);
862 GetVersionExW((OSVERSIONINFOW *)&OSVersion);
863 verval = OSVersion.dwMinorVersion + OSVersion.dwMajorVersion * 100;
864 len = sprintfW( verstr, szFormat, verval );
865 switch (OSVersion.dwPlatformId)
866 {
867 case VER_PLATFORM_WIN32_WINDOWS:
868 msi_set_property( package->db, szVersion9x, verstr, len );
869 break;
870 case VER_PLATFORM_WIN32_NT:
871 msi_set_property( package->db, szVersionNT, verstr, len );
872 len = sprintfW( verstr, szFormat,OSVersion.wProductType );
873 msi_set_property( package->db, szMsiNTProductType, verstr, len
);
874 break;
875 }
876 len = sprintfW( verstr, szFormat, OSVersion.dwBuildNumber );
877 msi_set_property( package->db, szWindowsBuild, verstr, len );
878 len = sprintfW( verstr, szFormat, OSVersion.wServicePackMajor );
879 msi_set_property( package->db, szServicePackLevel, verstr, len );
880
881 len = sprintfW( bufstr, szFormat2, MSI_MAJORVERSION, MSI_MINORVERSION
);
882 msi_set_property( package->db, szVersionMsi, bufstr, len );
883 len = sprintfW( bufstr, szFormat, MSI_MAJORVERSION * 100 );
884 msi_set_property( package->db, szVersionDatabase, bufstr, len );
885
886 GetNativeSystemInfo( &sys_info );
887 len = sprintfW( bufstr, szIntFormat, sys_info.wProcessorLevel );
888 msi_set_property( package->db, szIntel, bufstr, len );
889 if (sys_info.u.s.wProcessorArchitecture ==
PROCESSOR_ARCHITECTURE_INTEL)
890 {
...
902 }
903 else if (sys_info.u.s.wProcessorArchitecture ==
PROCESSOR_ARCHITECTURE_AMD64)
904 {
905 msi_set_property( package->db, szMsiAMD64, bufstr, -1 );
906 msi_set_property( package->db, szMsix64, bufstr, -1 );
907 msi_set_property( package->db, szVersionNT64, verstr, -1 );
...
--- snip ---
"verstr" is overwritten several times.
At the point of setting "szVersionNT64" msi property, "verstr" simply contains
the last string buffer "reuse" value which is obviously not what we want here
...
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.
http://bugs.winehq.org/show_bug.cgi?id=14501
Summary: docs incorrectly claim that unc paths work
Product: Wine
Version: unspecified
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: documentation
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: codeslinger(a)compsalot.com
The docs for unc path are wrong they do not reflect reality.
According to the docs
http://www.winehq.org/site/docs/wineusr-guide/misc-things-to-configure#AEN4…
and also according to this rather odious comment
http://www.winehq.org/pipermail/wine-users/2007-August/027715.html
unc paths, should work, all you do is create a symlink and you are done.
Well, I am under intense deadline pressure and I just spent two days of effort
trying to get a client/server app to run that requires unc paths. And finally
after a lot of study and banging of head against brick wall, finally I find
this bug #425 which makes it pretty darn clear that not only does unc path not
work, but it never actually has worked!!!!
http://bugs.winehq.org/show_bug.cgi?id=425
So I ask that you kindly please fix the docs so that others are not subjected
to the same levels of tribulations which I have just needlessly gone through.
That bug has been open since 2002, I see no indication that it is going to get
fixed any time soon.
I have the highest respect and admiration for the winehq project and the people
who created it, but this sort of thing is a major black mark against wine. I
will be very reluctant to attempt to use wine in the future.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=17516
Summary: Safari 4 Beta Crashes on Launch
Product: Wine
Version: 1.1.15
Platform: PC
URL: http://www.apple.com/safari/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ead1234(a)hotmail.com
Created an attachment (id=19629)
--> (http://bugs.winehq.org/attachment.cgi?id=19629)
console output
Wine crashes when launching safari.
--
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.