January 2013 - Wine-bugs - list.winehq.org

[Bug 32558] New: Visual Studio 2010 (10.0) Express Edition web installer crashes due to winhttp reporting available chunk size > 32 KiB (heap corruption)
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=32558 Bug #: 32558 Summary: Visual Studio 2010 (10.0) Express Edition web installer crashes due to winhttp reporting available chunk size > 32 KiB (heap corruption) Product: Wine Version: 1.5.20 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: winhttp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, I noticed strange crashes with the web installer of Visual Studio 2010 (10.0) Express Edition. Sometimes the installer would just bail out silently during download. Prerequisite: 'winetricks -q dotnet20 dotnet40' Unfortunately +relay or even repeated installer runs succeed most of the time so it's not easily to reproduce/track down (also depends on client connection to server). Also running the inner installer under debugger changes symptoms. Fortunately I managed get a crash with +relay at one time (using inner installer). --- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+winhttp,+relay wine ./setup.exe /web /CreatedTemp /NoExclude /InstalledFrom . >>log.txt 2>&1 ... 002a:trace:loaddll:load_native_dll Loaded L"Z:\\home\\focht\\Downloads\\test\\dlmgr.dll" at 0x364c0000: native ... 0030:Call oleaut32.SysAllocString(00c00840 L"dlmgr: Starting download attempt 1 of 3 for http://go.microsoft.com/fwlink/?LinkId=165067&clcid=0x409 using Http") ret=3593f268 0030:Ret oleaut32.SysAllocString() retval=01560ec4 ret=3593f268 ... 0030:Call ntdll.RtlAllocateHeap(00453000,00000008,00008000) ret=364e1884 0030:Ret ntdll.RtlAllocateHeap() retval=0045bdc8 ret=364e1884 ... 0042:Call KERNEL32.CreateFileW(0186f540 L"C:\\users\\focht\\Temp\\30319.01\\1033\\VC_EXP\\wcu\\watson\\dw20shared.msi",00000002,00000000,00000000,00000002,00000080,00000000) ret=364db8ff 0042:Ret KERNEL32.CreateFileW() retval=000001e8 ret=364db8ff ... 0042:Call winhttp.WinHttpQueryHeaders(00000003,00000005,00000000,0b56e850,0b56e840,00000000) ret=364d77ed 0042:trace:winhttp:WinHttpQueryHeaders 0x3, 0x00000005, (null), 0xb56e850, 0xb56e840, (nil) 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:trace:winhttp:query_headers attribute L"Content-Length" 0042:trace:winhttp:get_header_index L"Content-Length" 0042:trace:winhttp:get_header_index returning 12 0042:trace:winhttp:query_headers returning string: L"1850368" 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 2 0042:Ret winhttp.WinHttpQueryHeaders() retval=00000001 ret=364d77ed 0042:Call winhttp.WinHttpQueryDataAvailable(00000003,00000000) ret=364d77a6 0042:trace:winhttp:WinHttpQueryDataAvailable 0x3, (nil) 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000c) ret=7e2dc554 0042:Ret ntdll.RtlAllocateHeap() retval=0186fa68 ret=7e2dc554 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0042:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,0186fa68,00000010) ret=7e2dc85b 0042:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:Ret winhttp.WinHttpQueryDataAvailable() retval=00000001 ret=364d77a6 --- snip --- Download for first component is 1850368 bytes in total. The installer allocates a 32 KiB buffer and begins async download using winhttp. The "good" sequence reads like this: --- snip --- ... 0044:Call winhttp.WinHttpReadData(00000003,0045bdc8,00001554,00000000) ret=364d7787 0042:Call ntdll.RtlFreeHeap(00110000,00000000,01718950) ret=7e2dc63a 0044:trace:winhttp:WinHttpReadData 0x3, 0x45bdc8, 5460, (nil) 0042:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0044:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0044:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0044:Call ntdll.RtlAllocateHeap(00110000,00000000,00000014) ret=7e2dc554 0044:Ret ntdll.RtlAllocateHeap() retval=01718cb0 ret=7e2dc554 0044:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0044:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01718cb0,00000010) ret=7e2dc85b 0042:trace:winhttp:query_headers attribute L"Transfer-Encoding" 0042:trace:winhttp:get_header_index L"Transfer-Encoding" 0042:trace:winhttp:get_header_index returning -1 0042:trace:winhttp:read_data *** async=1, to_read=5460, num_bytes: 5460, ret=1, callback=0x364da8e0, buffer=0x45bdc8 0042:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 0042:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 5460 0042:Call KERNEL32.WriteFile(000001e8,0045bdc8,00001554,0b56e814,00000000) ret=364db83b 0042:Ret KERNEL32.WriteFile() retval=00000001 ret=364db83b ... 0044:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b ... 0044:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 0044:Ret winhttp.WinHttpReadData() retval=00000001 ret=364d7787 --- snip --- "trace:winhttp:read_data ***" trace message was added by me for diagnosis immediately before the send callback (also heap magic and size dump because +heap is not usable here). At one point we get this interesting sequence: --- snip --- ... 000d:Call winhttp.WinHttpQueryDataAvailable(00000003,00000000) ret=364d77a6 000d:trace:winhttp:WinHttpQueryDataAvailable 0x3, (nil) 000d:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 000d:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 000d:Call ntdll.RtlAllocateHeap(00110000,00000000,0000000c) ret=7e2dc554 000d:Ret ntdll.RtlAllocateHeap() retval=01718cb0 ret=7e2dc554 000d:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 000d:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01718cb0,00000010) ret=7e2dc85b 000d:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0042:trace:winhttp:query_data 73440 bytes available 000d:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0042:trace:winhttp:send_callback 0x1718bc0, 0x00040000, 0xb56e90c, 4 000d:Ret winhttp.WinHttpQueryDataAvailable() retval=00000001 ret=364d77a6 ... 0042:Call winhttp.WinHttpReadData(00000003,0045bdc8,00011ee0,00000000) ret=364d7787 000d:Call ntdll.RtlFreeHeap(00110000,00000000,01870290) ret=7e2dc63a 0042:trace:winhttp:WinHttpReadData 0x3, 0x45bdc8, 73440, (nil) 000d:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 3 0042:trace:winhttp:grab_object handle 0x3 -> 0x1718bc0 0042:Call ntdll.RtlAllocateHeap(00110000,00000000,00000014) ret=7e2dc554 0042:Ret ntdll.RtlAllocateHeap() retval=01870290 ret=7e2dc554 0042:trace:winhttp:addref_object 0x1718bc0 -> refcount = 4 0042:Call KERNEL32.QueueUserWorkItem(7e2dc7e9,01870290,00000010) ret=7e2dc85b 0042:Ret KERNEL32.QueueUserWorkItem() retval=00000001 ret=7e2dc85b 0044:trace:winhttp:query_headers attribute L"Transfer-Encoding" 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 3 0044:trace:winhttp:get_header_index L"Transfer-Encoding" 0042:Ret winhttp.WinHttpReadData() retval=00000001 ret=364d7787 0044:trace:winhttp:get_header_index returning -1 0042:trace:winhttp:release_object object 0x1718bc0 refcount = 2 0042:Call ntdll.RtlFreeHeap(00110000,00000000,01718cb0) ret=7e2dc63a 0042:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e2dc63a 0044:trace:winhttp:read_data *** async=1, to_read=73440, num_bytes: 73440, ret=1, callback=0x364da8e0, buffer=0x45bdc8 0044:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 0044:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 73440 ... --- snip --- 73440 bytes available reported and WinHttpReadData() is called from installer with the _same_ original buffer (0x45bdc8) which was allocated with 32 KiB (0x8000 bytes) - no realloc in between! This obviously leads to a heap overwrite and some time later to crashes. --- snip --- ... 000d:trace:winhttp:read_data *** async=1, to_read=5760, num_bytes: 5760, ret=1, callback=0x364da8e0, buffer=0x45bdc8 000d:trace:winhttp:read_data *** buf heap magic=0x455355, size=0x8000 000d:trace:winhttp:send_callback 0x1718bc0, 0x00080000, 0x45bdc8, 5760 000d:Call KERNEL32.WriteFile(000001e8,0045bdc8,00001680,0b76e814,00000000) ret=364db83b 000d:Ret KERNEL32.WriteFile() retval=00000001 ret=364db83b 000d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000080) ret=364ee12c 000d:Ret ntdll.RtlAllocateHeap() retval=0186fc18 ret=364ee12c 000d:Call KERNEL32.GetLastError() ret=364dfd2f 000d:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 000d:Call KERNEL32.GetLastError() ret=364dfd2f 000d:Ret KERNEL32.GetLastError() retval=00002f76 ret=364dfd2f 000d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x364e4b6f ip=364e4b6f tid=000d 000d:trace:seh:raise_exception info[0]=00000000 000d:trace:seh:raise_exception info[1]=98211559 000d:trace:seh:raise_exception eax=982114ad ebx=00000002 ecx=0b76e30c edx=00000000 esi=0b76e53a edi=0b76e53a 000d:trace:seh:raise_exception ebp=0b76e740 esp=0b76e2bc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 --- snip --- I added a small code snippet to automatically report/truncate available chunk size to 32 KiB if larger. --- snip --- ... fixme:winhttp:query_data truncating data avail from 50400 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 89632 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 71264 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 91776 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 116608 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 93920 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 69792 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 96064 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 67616 to 32768 bytes! fixme:winhttp:query_data truncating data avail from 59328 to 32768 bytes! ... --- snip --- With that change in place the web installer runs rock stable, sometimes reaching download speeds of 2-3 MiB/s using winhttp (not maxing out my connection - that might be server-side bandwidth issue). I've not found any useful info on MSDN about a 32 KiB limit on winhttp chunk size. Maybe the MS guys who wrote the installer made some assumption about some underlying native winsock implementation limitation on Windows. It might be interesting to see what max. chunk size native winhttp reports to clients. 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.

2 7

[Bug 31322] New: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes because TPIDRURW (user TLS register) TEB value is not preserved by kernel
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=31322 Bug #: 31322 Summary: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes because TPIDRURW (user TLS register) TEB value is not preserved by kernel Product: Wine Version: 1.5.9 Platform: arm OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, split off from bug 31308 (see there for details). TPIDRURW (user TLS register) TEB value is not preserved by kernel (currently either reset to zero or left with same values across context switches). 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.

2 15

[Bug 31308] New: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes due to invalid user TLS register value access
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=31308 Bug #: 31308 Summary: Remote Tools for Visual Studio 2012 RC for Windows on ARM (WoA) crashes due to invalid user TLS register value access Product: Wine Version: 1.5.9 Platform: arm OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, for André, some toy to play with ;-) "Remote Tools for Visual Studio 2012 RC" for Windows on ARM (WoA) can be downloaded here: http://www.microsoft.com/visualstudio/11/en-us/downloads#remote-tools It crashes on my quad Cortex-A9 based i.mx6 Sabre with Ubuntu Linux 12.04 --- snip --- Unhandled exception: page fault on read access to 0xc2083992 in 32-bit code (0x00419d44). Register dump: Thumb User Mode Pc:419d44 Sp:4134f720 Lr:418ed1 Cpsr:200f0030(--C-) r0:0208 r1:0001 r2:4134f7c8 r3:0208 r4:c208398a r5:4134f7c8 r6:0000 r7:4134f728 r8:dddd r9:04e4 r10:0100 Fp:4134f758 Ip:4134f518 Stack dump: 0x4134f720: 00000000 00000000 4134f7c8 00000100 0x4134f730: 00000001 8161b1cd 4134f748 00000100 0x4134f740: 4134f7c8 00000001 4134fd38 00446530 0x4134f750: 000004e4 4006e000 4134f790 00418f91 0x4134f760: 4134fac8 000004e4 00000000 00000000 0x4134f770: 00446998 00446308 42164138 40a72801 Backtrace: =>0 0x00419d44 in rtools_setup_arm (+0x19d44) (0x4134f758) 1 0x00418ed1 in rtools_setup_arm (+0x18ed0) (0x4134f758) 0x00419d44: ldr r4, [r4, #8] Modules: Module Address Debug info Name (77 modules) ELF 8000- 12000 Deferred <wine-loader> PE 400000- 454000 Export rtools_setup_arm ELF 40031000-4003f000 Deferred libsm.so.6 ... System information: Wine build: wine-1.5.9-186-g1f6febe Platform: arm Host system: Linux Host version: 3.2.0-1000-linaro-lt-mx6 --- snip --- WINEDEBUG=+tid,+seh,+relay doesn't reveal much, might be app init/startup code: --- snip --- $ wine ./rtools_setup_arm.exe ... 0024:Call KERNEL32.GetLastError() ret=00416973 0024:Ret KERNEL32.GetLastError() retval=00000000 ret=00416973 0024:Call KERNEL32.MultiByteToWideChar(000004e4,00000001,4130f7c8 " \x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94"...,00000100,00000000,00000000) ret=00418e95 0024:Ret KERNEL32.MultiByteToWideChar() retval=00000100 ret=00418e95 0024:trace:seh:raise_exception info[0]=00000000 0024:trace:seh:raise_exception info[1]=c2083992 0024:trace:seh:raise_exception Pc:419d44 Sp:4130f720 Lr:418ed1 Cpsr:200f0030 r0:0208 r1:0001 r2:0100 r3:0208 0024:trace:seh:raise_exception r4:c208398a r5:4130f7c8 r6:0000 r7:4130f728 r8:dddd r9:04e4 r10:0100 Fp:4130f758 Ip:4130f518 0024:trace:seh:call_stack_handlers calling handler at 0x403e3900 code=c0000005 flags=0 0024:Call KERNEL32.UnhandledExceptionFilter(4130f574) ret=403e3964 wine: Unhandled page fault on read access to 0xc2083992 at address 0x419d44 (thread 0024), starting debugger... 0024:trace:seh:start_debugger Starting debugger "winedbg --auto 35 68" ... --- snip --- Winedbg's builtin disassembler isn't really helpful, it's missing various thumb(2) opcodes. Fortunately there is a free IDA 6.2 demo version for Linux which also supports ARM family for download: http://www.hex-rays.com/products/ida/support/download_demo.shtml This is an invaluable tool which can be used to improve winedbg's disassembler and investigate other problems on ARM. The code in question: --- snip --- ... .text:00419D40 MRC p15, 0, R4,c13,c0, 2 .text:00419D44 LDR R4, [R4,#8] ... --- snip --- ARM info center CP15 c13 register summary: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/CIHFGF… Another resource: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACEAI… Opcode_2=3 register "TPIDRURO" is actually ARM HW TLS register, used by libc (__get_tls()). Opcode_2=2 register "TPIDRURW" is "Software Thread ID, User, R/W" Not sure if this is a "free for use" register or if any user space threading library code actually manages this register. One would have to search eglibc sources for ARM and any userspace libraries mapped into process address space, not part of Wine. The values don't seem very random but they point to invalid (not mapped) memory locations. I couldn't find any MCR opcodes in application code, so it's probably written elsewhere. This linux kernel patch has a bit of information: http://www.kernelhub.org/?p=2&msg=57979 It got committed to Linux 3.3.5: http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.3.5 (search for TPIDRURW). I'm running 3.2.0 so it's obviously not cleared by kernel side on context switch. Anyway, I fear this will be most likely upstream if the kernel deliberately clears it on every context switch (starting with 3.3.5). $ du -sh rtools_setup_arm.exe 16M rtools_setup_arm.exe $ sha1sum rtools_setup_arm.exe 6f75e6dad60b64e1f074884829b63ca00bcdb531 rtools_setup_arm.exe 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.

2 22

[Bug 15619] New: Visual Studio 2008 Installer Hangs after err:seh:setup_exception_record stack overflow
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=15619 Summary: Visual Studio 2008 Installer Hangs after err:seh:setup_exception_record stack overflow Product: Wine Version: 1.1.6 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: peterbelm(a)gmail.com Created an attachment (id=16642) --> (http://bugs.winehq.org/attachment.cgi?id=16642) Terminal output When running the Visual Studio 2008 installer the setup window appears, and starts loading installation components, after about 30 seconds full processor usage, err:seh:setup_exception_record stack overflow appears in the terminal output (see attachment) the progress bar increases slightly, and then it seems to hang. Checking with strace on the setup.exe process (the main one, the other one gives me 'Operation not permitted', even when sudo'ing it) shows it is waiting to read from a pipe, which is red when doing 'ls -l', I assume that means the pipe doesn't exist any more? -- 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.

2 6

[Bug 29905] New: Microsoft Visual Studio 2008: attaching to process fails with "unknown error: 0x80070003" (support of "Session" namespace for named objects needed)
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=29905 Bug #: 29905 Summary: Microsoft Visual Studio 2008: attaching to process fails with "unknown error: 0x80070003" (support of "Session" namespace for named objects needed) Product: Wine Version: 1.4-rc3 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello, prerequisite: 'winetricks -q dotnet30' Unfortunately for installation of Visual Studio 2008 Professional/Enterprise editions you have to resort to hacks. NOTE: Remote debugging capability is not available in Visual Studio 2005/2008 express editions (free for download). Bug 29354 (installer fails due to ProductID being set during client side "ValidateProductID" standard action -> don't set property) Bug 10601 (GAC API for managed assembly installation needs reparse point/junction API support -> force msi_install_assembly()/IAssemblyCache_InstallAssembly to succeed on failure) The installer still fails in the end but it's enough to have a "half" usable IDE/build environment (.NET Framework 3.5 and some .NET service packs get skipped due to Mono registry/fake mess while other components fail to install). Unlike Visual Studio 2005 which uses wtsapi (bug 29903), Visual Studio 2008 retrieves the process list by different means and displays the process in "standard" transport mode. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE $ wine ./devenv.exe --- snip --- 1) Menu "extras" -> "attach to process" 2) select one process, click "attach" It starts the debugging environment but fails half-through with "unknown error: 0x80070003" --- snip --- ... 0082:Call KERNEL32.ProcessIdToSessionId(00000085,0032e5f0) ret=3f083224 0082:Ret KERNEL32.ProcessIdToSessionId() retval=00000001 ret=3f083224 ... 0082:Call KERNEL32.CreateFileMappingW(ffffffff,0032e604,00000004,00000000,0000003c,0032e610 L"Session\\0\\Microsoft_VS90_causality_sharedmemory-133") ret=3f089149 0082:Ret KERNEL32.CreateFileMappingW() retval=00000000 ret=3f089149 0082:Call KERNEL32.GetLastError() ret=3f08897a 0082:Ret KERNEL32.GetLastError() retval=00000003 ret=3f08897a ... 0082:Call KERNEL32.FormatMessageW(00001300,00000000,80070003,00000400,0032e638,00000000,00000000) ret=3f2b9072 0082:Ret KERNEL32.FormatMessageW() retval=00000000 ret=3f2b9072 ... 0082:Call oleaut32.SysAllocString(03d19b60 L"Der Vorgang wird nicht unterst\00fctzt. Unbekannter Fehler: 0x80070003.") ret=3f247a9f ... --- snip --- For communication between target and debugger a shared memory location is created. The shared memory (file mapping) is created using a special namespace syntax: "Session\\0\\Microsoft_VS90_causality_sharedmemory-133" Wineserver doesn't support "Session\<id>" yet, hence CreateFileMappingW() fails. (another run with +server): --- snip --- 0009: create_mapping( access=000f000f, attributes=00000080, protect=00000043, size=0000003c, file_handle=0000, objattr={rootdir=0010,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=10000000,AceFlags=0,Sid={S-1-5-21-0-0-0-1000}}}},name=L"Session\\0\\Microsoft_VS90_causality_sharedmemory-18"} ) 0009: create_mapping() = OBJECT_PATH_NOT_FOUND { handle=0000 } --- snip --- Source: http://source.winehq.org/git/wine.git/blob/ba715798094896e8b98fc5803e16b00f… "Kernel Object Namespaces": http://msdn.microsoft.com/en-us/library/aa382954.aspx --- quote --- ... In addition to the "Global\" prefix, client processes can use the "Local\" prefix to explicitly create an object in their session namespace. These keywords are case sensitive. The "Session\" prefix is reserved for system use and you should not use it in names of kernel objects. ... <user comments> This documentation effectively states that 'Global', 'Local' and 'Session' are all valid as name prefixes (but not as names). There appears to be no documentation that says 'Session' cannot be used as a prefix or that it is reserved for use as a prefix. By referring to 'Session' as it does, it strongly implies that this a fully legal and valid way to enable applications in one session to interact with applications in another session. I think Microsoft should consider adding more detail about whether 'Session' is or is not valid for use by developers, and if so exactly what it can and cannot be used for. [user reponse] Global\ refers to the Global Namespace, Local\ refers to the current session's namespace, Session\x\ refers to x's namespace where x is the session id (not LUID or anything special, just a counter) --- quote --- "Memory mapped files from XP to Vista" http://blogs.msdn.com/b/maartenb/archive/2008/05/07/memory-mapped-files-fro… --- quote --- ... Online search for "sessions\1\basenamedobject" gives hits that point to Terminal Services. There appear to be Local Global and Session namespaces. So prior to Vista and Server 2008 all services shared the same namespace as the first user logging in to the machine. This was session 0. With Vista this is no longer the case. Just like all compatibility issues it is explained in the cookbook. --- quote --- There is a workaround for this problem. You can force a "normal" shared memory mapping name by setting to WinVer to "Windows 2000" prior running the IDE. Some components don't really support running WinVer < "Windows XP" anymore hence this might break some stuff (VS2008 refuses to install with W2K mode). At least this prevents the error message when attaching. It doesn't really break/pause the remote process (might be bug 25462). 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.

2 10

[Bug 24583] New: Wine 1.3.3 can't run Visual Studio 2008 (VC9) installer
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=24583 Summary: Wine 1.3.3 can't run Visual Studio 2008 (VC9) installer Product: Wine Version: 1.3.3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: simons(a)cryp.to Created an attachment (id=31046) --> (http://bugs.winehq.org/attachment.cgi?id=31046) Output printed by wine while attempting to run the installer I ran the installer of the full version (not VC express) using the latest release of wine. The installer starts up and works for a while, but ultimately it aborts with an unhandled exception. -- 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.

2 5

[Bug 20227] New: msi: Table Join on two tables that have same (non-join) column name causes only first column data to be returned.
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=20227 Summary: msi: Table Join on two tables that have same (non-join) column name causes only first column data to be returned. Product: Wine Version: 1.1.30 Platform: All OS/Version: All Status: UNCONFIRMED Severity: major Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: ngallaher+winehq(a)deepthought.org Created an attachment (id=23863) --> (http://bugs.winehq.org/attachment.cgi?id=23863) Patch for TableJoin bug Imagine the following tables Table foo: string color string flavor Table bar: string color string flavor with query "Select foo.color, bar.flavor from foo, bar where foo.color=bar.color" The current version returns the data from columns foo.color and foo.flavor. This is because when the tables are joined, the original tablename identifiers are dropped on the floor, resulting in a table with two 'color' and two 'flavor' columns. The VIEW_find_column() function then returns the first column found that matches the requested name. This can be traced to a deficiency in VIEW_find_column() which only uses the column names in its comparison. Further, the sql parser does not preserve the table identifier, but this is easily fixed. A patch, including test case is attached. This behaviour was observed when trying to install Visual Studio 2008 Standard Edition. -- 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.

2 13

[Bug 15671] New: Visual Studio 2008 Express web install fails with "Sharing violation" on $shtdwn$.req
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=15671 Summary: Visual Studio 2008 Express web install fails with "Sharing violation" on $shtdwn$.req Product: Wine Version: 1.1.6 Platform: Other URL: http://www.microsoft.com/express/download/#webInstall OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com To get the installer to even try, you have to do "winetricks volnum". The next problem is while copying file 41 of 41, $shtdwn$.req, it gets a sharing violation. The file it's trying to copy is there, but can't be opened, possibly because it has never been closed. 002f:Call KERNEL32.CreateFileA(0100afa0 "c:\\21309f2f7662773b82c3\\$shtdwn$.req",c0000000,00000003,00000000,00000001,04000002,00000000) ret=0100355e trace:file:CreateFileW returning 0x68 002f:Ret KERNEL32.CreateFileA() retval=00000068 ret=0100355e 002f:Call KERNEL32.WriteFile(00000068,0100a5a0,00000314,0032fe70,00000000) ret=010035b5 trace:file:WriteFile 0x68 0x100a5a0 788 0x32fe70 (nil) 002f:Ret KERNEL32.WriteFile() retval=00000001 ret=010035b5 002f:Call KERNEL32.SetEnvironmentVariableA(01002388 "_SFX_CAB_SHUTDOWN_REQUEST",0100afa0 "c:\\21309f2f7662773b82c3\\$shtdwn$.req") ret=010035cb ... ... trace:text:DrawTextExW L"Setup is copying required resources to your temp directory.\r\nCopying file 41 of 41.\r\n\r\nCopying setup file: $shtdwn$.req", -1, [(0,0)-(360,70)] 00000050 ... 0032:Call KERNEL32.CopyFileExW(0033e80c L"C:\\21309f2f7662773b82c3\\$shtdwn$.req",0033e5fc L"C:\\windows\\temp\\SIT42147.tmp\\$shtdwn$.req",3aaed850,0000000 0,0033ddbc,00000002) ret=3aaed716 warn:file:CreateFileW Unable to create file L"C:\\21309f2f7662773b82c3\\$shtdwn$.req" (status c0000043) warn:file:CopyFileW Unable to open source L"C:\\21309f2f7662773b82c3\\$shtdwn$.req" 0032:Call oleaut32.SysAllocString(00787cf0 L"Setup has encountered a problem while trying to copy:\r\nC:\\21309f2f7662773b82c3\\$shtdwn$.req\r\nPress Retry to attempt the copy again. Press Cancel to cancel setup.") ret=3aae49ab Interestingly, even on Windows this file can't be opened sometimes early in an installer; see http://www.digitalformula.net/infrastructure/how-to-perform-an-unattended-i… It's an interesting mystery. What triggers that file to be closed on Windows? -- 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.

2 4

[Bug 14875] New: VS 2008 Express Editions (SP1) installer fails with directory resolution error (bug in msi appsearch action)
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=14875 Summary: VS 2008 Express Editions (SP1) installer fails with directory resolution error (bug in msi appsearch action) Product: Wine Version: CVS/GIT Platform: PC URL: http://www.microsoft.com/express/download/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, downloaded full DVD image of Visual Studio 2008 Express Edition with SP1. Minimal set of prerequisites needed to reproduce this bug: 1. sh winetricks volnum (bug 5351) 2. MsiSetExternalUIRecord patch (bug 10547) The installer stops with error "directory resolution failed". --- snip --- 002c:Call msi.MsiGetPropertyW(00000001,00cee4c8 L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8",39e262f8,0032ab10) ret=39e55231 002c:trace:msi:MSI_GetProperty 1 L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8" 0x39e262f8 0x32ab10 .. 002c:trace:msi:MSI_DatabaseOpenViewW L"SELECT `Value` FROM `_Property` WHERE `_Property`='VS7.3643236F_FC70_11D3_A536_0090278A1BB8'" 0x32a9c4 .. 002c:Ret msi.MsiGetPropertyW() retval=000000ea ret=39e55231 .. 002c:Call KERNEL32.FormatMessageW(00000b00,3aa70000,0000108e,00000400,0032a7bc,00000000,00000000) ret=39ea74fb 002c:Ret KERNEL32.FormatMessageW() retval=00000024 ret=39ea74fb .. 002c:Call oleaut32.SysAllocString(00cdcd08 L"Microsoft Visual C++ 2008 Express Edition with SP1 - DEU") ret=39e4bc58 .. 002c:Call oleaut32.SysAllocString(00cee978 L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8: Fehler bei Verzeichnisaufl\00f6sung.") ret=39e4bc58 .. 002c:Call oleaut32.SysFreeString(010ab66c L"ERROR processed; exception was thrown for retail build\n\tDeveloper Comment: \n\tBuild Time: Thu Dec 11 15:04:18 2003\n\tDWORD: 234") ret=39e40e56 .. 002c:Call oleaut32.SysFreeString(010ab5ec L"Microsoft Visual C++ 2008 Express Edition with SP1 - DEU") ret=39e40e5f .. 002c:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0032a9d8) ret=39e80d28 002c:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b8433b0 --- snip --- Property "VS7.3643236F_FC70_11D3_A536_0090278A1BB8" (= Visual Studio install directory) does not exist (anymore) at this install stage. Besides from a bug in dlls/msi/install.c:msi_strcpy_to_awstring(), which results in wrong ERROR_MORE_DATA for empty unicode strings (see previous snippet, str=L"" + len=0), the following sequences lead to this bug... The installation directory property is created/set first here: --- snip --- .. 002c:trace:msi:MsiDoActionW L"CA_SetVcvars32batProp_x86_deu.3643236F_FC70_11D3_A536_0090278A1BB8" 002c:trace:msi:ACTION_PerformUIAction Performing action (L"CA_SetVcvars32batProp_x86_deu.3643236F_FC70_11D3_A536_0090278A1BB8") .. 002c:trace:msi:ACTION_CustomAction Handling custom action L"CA_SetVcvars32batProp_x86_deu.3643236F_FC70_11D3_A536_0090278A1BB8" (33 L"CA_SetVcvars32bat_x86_deu.3643236F_FC70_11D3_A536_0090278A1BB8" L"[#FL_vsvars_bat_10582_x86_ln.3643236F_FC70_11D3_A536_0090278A1BB8];[#FL_vcvars32_bat_5369_x86_ln.3643236F_FC70_11D3_A536_0090278A1BB8];@SET VSINSTALLDIR=[VS7.3643236F_FC70_11D3_A536_0090278A1BB8]|@SET VCINSTALLDIR=[VC7.3643236F_FC70_11D3_A536_0090278A1BB8]|@SET FrameworkDir=[Framework_x86.3643236F_FC"...) .. 002c:trace:msi:MSI_GetPropertyW returning L"C:\\Program Files\\Microsoft Visual Studio 9.0\\" for property L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8" .. --- snip --- ("@SET VSINSTALLDIR=[VS7.3643236F_FC70_11D3_A536_0090278A1BB8]") But is removed/reset at later install stage, when this custom action is run: --- snip --- 002c:trace:msi:ACTION_CustomAction Handling custom action L"CA_VIntegration_Exec_VS7_x86_deu.3643236F_FC70_11D3_A536_0090278A1BB8" (33 L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8" L"[VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8]") 002c:trace:msidb:MSI_CreateRecord 1 .. 002c:trace:msi:MSI_GetPropertyW property L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8" not found .. 002c:trace:msi:MSI_SetPropertyW 0xbcbec8 L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8" L"" .. 002c:trace:msi:MSI_GetPropertyW property L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8" not found 002c:trace:msi:MSI_DatabaseOpenViewW L"DELETE FROM `_Property` WHERE `_Property` = 'VS7.3643236F_FC70_11D3_A536_0090278A1BB8'" 0x32b298 .. --- snip --- The removal/reset was due to property L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8" not existing. Using ORCA tool on msi setup database, one can find this property referenced in "AppSearch" table: --- snip --- Property ; Signature VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8 VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 --- snip --- Signature is "VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" "CompLocator" table: --- snip --- Signature ; ComponentId ; Type VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 {2883180F-8F0F-4B82-B0BA-D48CE920DFAF} 0 --- snip --- "Component" table: --- snip --- Component ; ComponentId ; Directory ; Attribute ; Condition ; KeyPath VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8 {2883180F-8F0F-4B82-B0BA-D48CE920DFAF} VS7.3643236F_FC70_11D3_A536_0090278A1BB8 0 --- snip --- Armed with this information, one can find the following in trace log: --- snip --- 002c:trace:msi:iterate_appsearch L"VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8" L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" 002c:trace:msi:ACTION_AppSearchGetSignature package 0xbcbec8, sig 0x32b304 .. 002c:trace:msi:ACTION_AppSearchGetSignature failed to query signature for L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" 002c:trace:msi:ACTION_AppSearchComponents L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" .. .. 002c:trace:msi:MsiLocateComponentW L"{2883180F-8F0F-4B82-B0BA-D48CE920DFAF}" 0x32b040 0x32b248 002c:trace:msi:MsiGetProductCodeW L"{2883180F-8F0F-4B82-B0BA-D48CE920DFAF}" 0x32afae .. 002c:trace:msi:MSIREG_OpenUserDataComponentKey L"{2883180F-8F0F-4B82-B0BA-D48CE920DFAF}" .. 002c:trace:msi:MSIREG_OpenUserDataComponentKey squished (L"F0813882F0F828B40BAB4DC89E02FDFA") .. 002c:trace:msi:ACTION_AppSearchReg L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" .. 002c:trace:msi:ACTION_AppSearchReg failed to query RegLocator for L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" 002c:trace:msi:ACTION_AppSearchIni L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" .. 002c:trace:msi:ACTION_AppSearchIni failed to query IniLocator for L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" 002c:trace:msi:ACTION_AppSearchDr L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" .. 002c:trace:msi:ACTION_AppSearchDr failed to query DrLocator for L"VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" .. --- snip --- This results in property "VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8" and depending property "VS7.3643236F_FC70_11D3_A536_0090278A1BB8" reset. MSDN info for AppSearch table here: http://msdn.microsoft.com/en-us/library/aa367579.aspx and AppSearch action: http://msdn.microsoft.com/en-us/library/aa367578.aspx Specifically: --- quote --- The AppSearch action requires that the Signature table be present in the installation package. [..] A signature that is not in the Signature table denotes a directory and the action sets the property to the directory path for that signature. --- quote --- This "VInt_VS7_X86_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" key is not present in "Signature" table, it's actually a directory. If we look in the previously posted "Component" table we see the directory is actually "VS7.3643236F_FC70_11D3_A536_0090278A1BB8" By looking into "Directory" table we find the following: --- snip --- Directory ; Directory Parent ; DefaultDir VS7.3643236F_FC70_11D3_A536_0090278A1BB8 ProgramFilesFolder_x86.3643236F_FC70_11D3_A536_0090278A1BB8 VS90.NET|Microsoft Visual Studio 9.0 --- snip --- So "VS7.3643236F_FC70_11D3_A536_0090278A1BB8_RO.3643236F_FC70_11D3_A536_0090278A1BB8" should resolve to "VS7.3643236F_FC70_11D3_A536_0090278A1BB8" -> L"C:\\Program Files\\Microsoft Visual Studio 9.0\\" (install dir) This looks like bug in wine msi appsearch action impl. 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.

2 15

[Bug 29921] New: Microsoft Visual Studio 2008 Express installer shows highlighted items incorrectly
by wine-bugs＠winehq.org 19 Jul '21

19 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=29921 Bug #: 29921 Summary: Microsoft Visual Studio 2008 Express installer shows highlighted items incorrectly Product: Wine Version: 1.4-rc4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ehoover(a)mines.edu Classification: Unclassified Created attachment 38933 --> http://bugs.winehq.org/attachment.cgi?id=38933 Screenshot depicting the problem Any checkbox or button selected in the installer window will "disappear". The installer still functions, but the issue is very visually disturbing. -- 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.

2 20