[Bug 8439] Visual Studio .NET (7) install fails

Tue Jan 29 12:27:24 CST 2008

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

--- Comment #1 from Anastasius Focht <focht at gmx.net>  2008-01-29 12:27:23 ---
Created an attachment (id=10514)
 --> (http://bugs.winehq.org/attachment.cgi?id=10514)
patch which fixes VS.NET 2003 (2002 too?) installer bug, shell execute app path
expansion

Hello,

--- snip ---
When you run it, it checks for installed components,
tells you you need IIS, and lets you continue without it.
When you click "Continue", it thinks for a couple seconds,
then the dialog goes away, and nothing happens.
--- snip ---

same happens with VS.NET 2003 (7.1).
VS.NET 2002 isn't that widespread/used anymore so if anyone owns VS.NET 2002
try the fix there too.

Because there is no error message associated and even +relay didn't show
anything suspicious this problem was somewhat tricky.

Relevant trace:

--- snip ---
..
0046:Call shell32.ShellExecuteExW(0034d068) ret=00409639
0046:trace:exec:SHELL_execute mask=0x00000040 hwnd=(nil) verb=(null)
file=L"setup.exe" parm=L"/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\"
/NoExclude" dir=L"D:\\wcu" show=0x00000001 class=not used
0046:Call ntdll.RtlAllocateHeap(00110000,00000000,0000020c) ret=67a1b416
0046:Ret  ntdll.RtlAllocateHeap() retval=001b1098 ret=67a1b416
0046:trace:exec:ShellExecute_FromContextMenu L"setup.exe"
0046:Call shlwapi.PathFindExtensionW(001b1098 L"setup.exe") ret=67a1cb7e
0046:Ret  shlwapi.PathFindExtensionW() retval=001b10a2 ret=67a1cb7e
0046:trace:exec:ShellExecute_GetClassKey ext = L".exe"
..
0046:Call KERNEL32.ExpandEnvironmentStringsW(0034bfbc
L"/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\"
/NoExclude",00000000,00000000) ret=67a1cf06
0046:Ret  KERNEL32.ExpandEnvironmentStringsW() retval=00000038 ret=67a1cf06
..
0046:trace:exec:SHELL_execute
execute:L"setup.exe",L"/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\"
/NoExclude",L"D:\\wcu"
0046:trace:exec:SHELL_ExecuteW Execute L"setup.exe
/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\" /NoExclude" from directory
L"D:\\wcu"
0046:Call KERNEL32.GetFileAttributesW(001b2628 L"D:\\wcu") ret=67a1df7f
0046:Ret  KERNEL32.GetFileAttributesW() retval=00000011 ret=67a1df7f
0046:Call KERNEL32.GetCurrentDirectoryW(00000104,0034a470) ret=67a1dfc1
0046:Ret  KERNEL32.GetCurrentDirectoryW() retval=0000000f ret=67a1dfc1
0046:Call KERNEL32.SetCurrentDirectoryW(001b2628 L"D:\\wcu") ret=67a1dfda
0046:Ret  KERNEL32.SetCurrentDirectoryW() retval=00000001 ret=67a1dfda
0046:Call KERNEL32.CreateProcessW(00000000,0034b7bc L"setup.exe
/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\"
/NoExclude",00000000,00000000,00000000,00000400,00000000,001b2628
L"D:\\wcu",0034a678,0034a6bc) ret=67a1ddc3
0046:trace:process:CreateProcessW app (null) cmdline L"setup.exe
/LAUNCHER=\"C:\\windows\\temp\\\"  /HWND=\"917812\" /NoExclude"
0046:trace:process:find_exe_file looking for L"setup.exe"
0046:trace:process:find_exe_file Trying native exe
L"C:\\windows\\temp\\setup.exe"
0046:trace:process:CreateProcessW starting L"C:\\windows\\temp\\setup.exe" as
Win32 binary (0x400000-0x4a4000)
0014:trace:relay:load_list L"RelayExclude" =
L"ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98"
0014:trace:relay:load_list L"RelayFromExclude" =
L"winex11.drv;user32;gdi32;advapi32;kernel32"
0014:Call KERNEL32.__wine_kernel_init() ret=7bc45638
0014:trace:process:init_current_directory starting in L"D:\\wcu\\" (nil)
0014:trace:process:__wine_kernel_init starting process
name=L"C:\\windows\\temp\\setup.exe" argv[0]=L"setup.exe"
..
0046:Ret  KERNEL32.CreateProcessW() retval=00000001 ret=67a1ddc3
..
0046:trace:exec:SHELL_ExecuteW returning 33 
--- snip ---

What happens ... 
Well, the installer spawns sub-installers - which coincidally have the same
filename.
Unfortunately the wrong setup.exe is spawned (main installer instead of
sub-installer) resulting in installer detecting a running instance of itself
(mutex) and silently terminating.
Parent then terminates too without any error.

CDROM disk layout ("d:\\"):

root directory: setup.exe (main installer)
sub directory: wcu\setup.exe (sub installer for prerequisites)

I first thought CreateProcessW() was to blame because it resolved the wrong
setup.exe but it was not the case.

CreateProcessW() works expected if given a short pathname of executable:

--- snip ---
search order:

   1. The directory from which the application loaded.
   2. The current directory for the parent process.
   3. The 32-bit Windows system directory. Use the GetSystemDirectory function
to get the path of this directory.
   4. The 16-bit Windows system directory. There is no function that obtains
the path of this directory, but it is searched. The name of this directory is
System.
   5. The Windows directory. Use the GetWindowsDirectory function to get the
path of this directory.
   6. The directories that are listed in the PATH environment variable. Note
that this function does not search the per-application path specified by the
App Paths registry key. To include this per-application path in the search
sequence, use the ShellExecute function.
--- snip ---

Because of this "setup.exe" is resolved to "d:\\setup.exe" (d:\\ = cdrom root
dir) = wrong.
The application filename needs to be expanded before the CreateProcess() call -
so only ShellExecute() is left as possible cause. 

In windows the sub-installer is created with full path "d:\\wcu\\setup.exe" -
so a filename expansion/resolve must take place in API.

I first used SearchPath() with explicit path to do LoadLibrary-like search in
SHELL_execute().
Later I found the more convenient PathFindOnPath() which does all in one call
without additional buffers/copying.

The attached patch fixes the VS.NET 2003 installer problem for me, starting the
correct prerequisites sub-installer.

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.