[Bug 8439] Visual Studio .NET (7) install fails
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Mar 29 19:25:14 CDT 2008
http://bugs.winehq.org/show_bug.cgi?id=8439
--- Comment #16 from Anastasius Focht <focht at gmx.net> 2008-03-29 19:25:13 ---
Created an attachment (id=11733)
--> (http://bugs.winehq.org/attachment.cgi?id=11733)
patch which prevents incorrect write-protect attributes on file targets
Hello,
another patch to get full installation working.
This was a bit nasty to investigate/debug because the VS.NET installer takes a
huge nap until the real installation of components starts (30-60 minutes
depending on machine speed).
I hope James will optimize the table joins one day further (low priority).
Prerequisite: clean ~/.wine, winetricks vcrun6 gecko, shell32 patch applied
As I already outlined in another VS.NET bug report, the AeDebug "Auto" key gets
modified in early stage (by ms debugging service component -> "0").
This has the consequence that in case of unhandled exceptions, winedbg is no
longer automagically runaway-spawned, hiding possible problems.
Instead "nice" message boxes are popping up, asking the user what to do.
So all that is needed is to prevent any unhandled exceptions caused by
component installers ;-)
When the "mobile device support" component within VB.NET component is selected,
the .NET compact framework is installed too (= default).
Unfortunately this leads to a problem at late installation stage which unearths
msi bug.
There is a small .NET executable temporarily extracted and spawned with the
following command line:
--- snip ---
genxml.exe "C:\Program Files\Microsoft Visual Studio .NET
2003\Setup\conman_ds_package.xsl" "C:\windows\profiles\All Users\Application
Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl" "C:\Program
Files\Microsoft Visual Studio .NET
2003\CompactFrameworkSDK\ConnectionManager\Bin" "C:\Program Files\Microsoft
Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Target"
"C:\windows\profiles\All Users\Application
Data\Microsoft\VisualStudio\Devices\7.1" "C:\Program Files\Microsoft Visual
Studio .NET 2003\CompactFrameworkSDK\v1.0.5000"
C:\windows\Microsoft.NET\Framework\v1.1.4322 "C:\Program Files\Microsoft Visual
Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Bin"
--- snip ---
(I renamed it for my own purpose to debug it)
This tool throws unhandled (managed) exception.
--- snip managed exception frame ---
First chance exception generated: (0x04790188)
<System.UnauthorizedAccessException>
Unhandled exception generated: (0x04790188)
<System.UnauthorizedAccessException>
_className=<null>
_exceptionMethod=<null>
_exceptionMethodString=<null>
_message=(0x0478ff84) "Access to the path "C:\windows\profiles\All
Users\Application
Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl" is denied."
_innerException=<null>
_helpURL=<null>
_stackTrace=(0x047901c8) array with dims=[96]
_stackTraceString=<null>
_remoteStackTraceString=<null>
_remoteStackIndex=0x00000000
_HResult=0x80070005
_source=<null>
_xptrs=0x00000000
_xcode=0xe0434f4d
--- snip managed exception frame ---
The managed code for that small app resembles like this:
--- snip managed app code ---
..
if (File.Exists(path))
{
StreamReader reader = File.OpenText(path);
str = reader.ReadToEnd();
reader.Close();
str = str.Replace( ... values_supplied_with_commandline_args ... );
StreamWriter writer = File.CreateText(str3);
writer.Write(str);
writer.Close();
}
..
--- snip managed app code ---
Badly written ... there is no exception handler which guards
StreamReader/Writer and other file operation failures.
The corresponding wine trace:
--- wine trace ---
0009:Call KERNEL32.GetFullPathNameW(0033f22c L"C:\\windows\\profiles\\All
Users\\Application
Data\\Microsoft\\VisualStudio\\Devices\\7.1\\conman_ds_package.xsl",00000105,0033f020,0033efe8)
ret=791bd775
0009:Ret KERNEL32.GetFullPathNameW() retval=00000067 ret=791bd775
..
0009:Call KERNEL32.CreateFileW(0477a7a8 L"C:\\windows\\profiles\\All
Users\\Application
Data\\Microsoft\\VisualStudio\\Devices\\7.1\\conman_ds_package.xsl",40000000,00000001,00000000,00000002,00000080,00000000)
ret=003fa308
0009:Ret KERNEL32.CreateFileW() retval=ffffffff ret=003fa308
0009:Call KERNEL32.GetLastError() ret=003fa30e
0009:Ret KERNEL32.GetLastError() retval=00000005 ret=003fa30e
..
<managed exception later>
--- wine trace ---
What happens?
Let's look into that target directory:
--- snip ---
[focht at nexus 7.1]$ ls -lsa
..
8 -r--r--r-- 1 focht focht 2487 2003-03-19 08:44 conman_ds_package.xsl
32 -r--r--r-- 1 focht focht 26432 2003-03-19 08:44 conman_ds_platform.xsl
8 -r--r--r-- 1 focht focht 1621 2003-03-19 08:44 conman_ds_startup.xsl
8 -r--r--r-- 1 focht focht 3365 2003-03-19 08:44 conman_ds_transport.xsl
--- snip ---
The files were installed by VS.NET installer at earlier stage - and have
write-protection set (mounted DVD ISO).
This is the cause of the exception when the output file is to be opened.
Msi's copy_file() calls CopyFileW() (dlls/kernel32/path.c) at some point to
copy files from source media to target.
CopyFileW's target inherits the source file attributes ->
GetFileInformationByHandle( source ...) -> DVD ISO, hence the target "write
protect".
When I looked at other installed files, I noticed a strange thing...
Various files were write-protected and some not.
--- snip target (wine drive_c) ---
[focht at nexus VS7Debug]$ pwd
/home/focht/.wine/drive_c/Program Files/Common Files/Microsoft Shared/VS7Debug
[focht at nexus VS7Debug]$ ls -lsa
..
64 -r--r--r-- 1 focht focht 57344 2003-03-19 10:56 coloader.dll
12 -r--r--r-- 1 focht focht 5120 2003-03-19 03:24 coloader.tlb
64 -rw-rw-r-- 1 focht focht 57344 2003-03-19 10:56 csm.dll
336 -rwxrwxr-x 1 focht focht 335872 2003-03-19 10:55 mdm.exe
196 -rw-rw-r-- 1 focht focht 192512 2003-03-19 10:58 msdbg2.dll
196 -rw-rw-r-- 1 focht focht 192512 2003-03-19 11:00 pdm.dll
196 -rwxrwxr-x 1 focht focht 192512 2003-03-19 07:23 vs7jit.exe
--- snip target (wine drive_c) ---
--- snip source (mounted DVD iso) ---
[focht at nexus vs7debug]$ pwd
/mnt/iso/program files/common files/microsoft shared/vs7debug
[focht at nexus vs7debug]$ ls -lsa
..
56 -r-xr-xr-x 1 root root 57344 2003-03-19 10:56 coloader.dll
5 -r-xr-xr-x 1 root root 5120 2003-03-19 03:24 coloader.tlb
56 -r-xr-xr-x 1 root root 57344 2003-03-19 10:56 csm.dll
328 -r-xr-xr-x 1 root root 335872 2003-03-19 10:55 mdm.exe
188 -r-xr-xr-x 1 root root 192512 2003-03-19 10:58 msdbg2.dll
188 -r-xr-xr-x 1 root root 192512 2003-03-19 11:00 pdm.dll
188 -r-xr-xr-x 1 root root 192512 2003-03-19 07:23 vs7jit.exe
--- snip source (mounted DVD iso) ---
At certain installer stages, components are (re)installed again (no skip
condition met).
For example some tools ship with .NET Framework SDK and the same tools ship
with VS.NET 7.1 main installer.
Msi encounters a permission problem while copying the files again
(STATUS_ACCESS_DENIED -> NTSTATUS = 0xC0000022).
The "copy_install_file Overwriting existing file: 0" indicates that msi fixed
it by adjusting file attributes to "normal".
This is the explanation why there is a mixture of write-protected and
non-write-protected files.
Now the real problem: msi's copy_install_file()/copy_file() doesn't honour the
"File" Table, "Attribute" column in case of attribute "none/normal".
If you use ORCA tool on .msi "File" table you will see various files with zero
attribute value (while others have 0x400 = readonly):
--- snip VS.NET msi "file" table data ---
conman_ds_package_xml_1________.3643236F_FC70_11D3_A536_0090278A1BB8
SDE_ConMan_AppData_Devices________.3643236F_FC70_11D3_A536_0090278A1BB8
132950|conman_ds_package.xsl 2487 0 17472
--- snip VS.NET msi "file" table data ---
"0" means "normal" attributes
I attached a small patch which resets the target attributes to "normal" if
necessary.
This lets the VS.NET 2003 enterprise edition installer finish a full
installation (= all components selected).
Though the separate MSDN library sub-installer has a problem which I will look
later into.
Anyway ... even with a full installation now succeeding this doesn't
necessarily mean VS.NET works.
There are various installer gaps which lead to later problems.
I already mentioned the most prominent: msi not publishing assemblies into
GAC/SxS.
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