August 2020 - Wine-bugs - list.winehq.org

[Bug 35910] New: not open programs
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=35910 Bug ID: 35910 Summary: not open programs Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: midela73(a)gmail.com Created attachment 47958 --> http://bugs.winehq.org/attachment.cgi?id=47958 not open programs not open programs -- 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 19

[Bug 42011] New: Eve Online Launcher doesn't display correctly
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=42011 Bug ID: 42011 Summary: Eve Online Launcher doesn't display correctly Product: Wine Version: 2.0-rc1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 56451 --> https://bugs.winehq.org/attachment.cgi?id=56451 Terminal Output Hello everyone, I am trying to get "Eve Online" running on my openSUSE "Tumbleweed" system. Unfortunately the Launcher doesn't display any graphics or text, just a grey box except for the "minimize", "maximize" etc. icons in the upper right corner which do work. Please let me know should you need further information. Maik -- 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 12

[Bug 42473] New: Eve Online Launcher is completely white ( no content displayed)
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=42473 Bug ID: 42473 Summary: Eve Online Launcher is completely white (no content displayed) Product: Wine Version: 1.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: d.marksbarber(a)gmail.com Distribution: --- Created attachment 57329 --> https://bugs.winehq.org/attachment.cgi?id=57329 Error when attempting to refresh the launcher's GUI I am running wine 1.8 on Ubuntu, attempting to play Eve Online. Downloading the game seems to work fine, running the game seems to work fine. But logging in through the client has been disabled. So logging in through the launcher is a must. Unfortunately no content (main launcher) is displayed, so I am unable to see the login buttons and such. Eve's launcher has a fall back to a less GUI intensive launcher which is basically just a downloader, I have not found an option to log in through that launcher as of posting this. Is there a fix for this issue? -- 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 17

[Bug 46194] New: Windows PowerShell Core 6.2 Preview 2 for ARM64 crashes due to decoding of instruction from incorrect PC (write watch access causes SIGSEGV)
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=46194 Bug ID: 46194 Summary: Windows PowerShell Core 6.2 Preview 2 for ARM64 crashes due to decoding of instruction from incorrect PC (write watch access causes SIGSEGV) Product: Wine Version: 3.21 Hardware: aarch64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, essentially the same problem domain as bug 46187 ("Windows PowerShell Core 6.2 Preview 2 for ARM32 crashes due to unhandled trap_no 0 (write watch access causes SIGSEGV)") Also mentioned briefly in bug 46155 ("Windows PowerShell Core 6.1 for ARM64 crashes on unimplemented function KERNEL32.dll.RaiseFailFastException") -> the failfast is a result of this one. Download: https://github.com/PowerShell/PowerShell/releases https://github.com/PowerShell/PowerShell/releases/download/v6.2.0-preview.2… --- snip --- $ WINEDEBUG=+seh,+loaddll,+virtual wine64 ./pwsh.exe ... 0009:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 003a0000 202000 00000004 0009:trace:virtual:map_view got mem in reserved area 0x18f30000-0x192d0000 0009:trace:virtual:VIRTUAL_DumpView View: 0x18f30000 - 0x192cffff (valloc) 0009:trace:virtual:VIRTUAL_DumpView 0x18f30000 - 0x192cffff -Hrw- 0009:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x18f30000 00090168 1000 00000004 0009:trace:virtual:VIRTUAL_DumpView View: 0x18f30000 - 0x192cffff (valloc) 0009:trace:virtual:VIRTUAL_DumpView 0x18f30000 - 0x18fc0fff cHrw- 0009:trace:virtual:VIRTUAL_DumpView 0x18fc1000 - 0x192cffff -Hrw- 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x83fc2c pc=83fc2c tid=0009 0009:trace:seh:raise_exception info[0]=0000000000000000 0009:trace:seh:raise_exception info[1]=0000000018f30000 0009:trace:seh:raise_exception x0=0000000018f30000 x1=00000000002ad8a0 x2=0000000000000000 x3=0000000000000008 0009:trace:seh:raise_exception x4=000000007bd4bdf8 x5=000000007bd4bdb0 x6=0000007fba705f10 x7=0000007fba78a978 0009:trace:seh:raise_exception x8=000000000000c000 x9=00000000002ad9d8 x10=00000000ffffffff x11=00000000ffffffff 0009:trace:seh:raise_exception x12=0000000000000000 x13=0000000018f30040 x14=0000000000000001 x15=000000007bd2da70 0009:trace:seh:raise_exception x16=000000007bd2e010 x17=0000007fba895860 x18=000000007ffd8000 x19=0000000000a77348 0009:trace:seh:raise_exception x20=0000000018f30000 x21=0000000018f30000 x22=0000000000f30000 x23=0000000000090168 0009:trace:seh:raise_exception x24=0000000000a6a270 x25=00000000000000c4 x26=0000000000a69ea8 x27=0000000000030000 0009:trace:seh:raise_exception x28=0000000000595290 fp=00000000002ada30 lr=000000000083fbdc sp=00000000002ada30 0009:trace:seh:raise_exception pc=000000000083fc2c 0009:trace:seh:call_vectored_handlers calling handler at 0x5e4550 code=c0000005 flags=0 ... 0009:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub 0009:fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x000003ff,(nil),0x0001,0x00000000,0x2abc50,(nil)): stub 0009:err:eventlog:ReportEventW L"Application: pwsh.exe\nCoreCLR Version: 4.6.26919.2\nDescription: The process was terminated due to an internal error in the .NET Runtime at IP 000000000083FC2C (0000000000570000) with exit code 80131506.\n" 0009:fixme:advapi:DeregisterEventSource (0xcafe4242) stub 0009:trace:seh:raise_exception code=80000100 flags=1 addr=0x7bcd5ff4 pc=7bcd5ff4 tid=0009 0009:trace:seh:raise_exception info[0]=0000000000a63cfc 0009:trace:seh:raise_exception info[1]=0000000000a63896 wine: Call from 0x7bcd5ff4 to unimplemented function KERNEL32.dll.RaiseFailFastException, aborting 0009:trace:seh:call_vectored_handlers calling handler at 0x5e4550 code=80000100 flags=1 0009:trace:seh:call_vectored_handlers handler at 0x5e4550 returned 0 0009:trace:seh:call_stack_handlers calling handler at 0x7b4dd704 code=80000100 flags=1 wine: Unimplemented function KERNEL32.dll.RaiseFailFastException called at address 0x7bcd5ff4 (thread 0009), starting debugger... 0009:trace:seh:start_debugger Starting debugger "winedbg --auto 8 164" ... Modules: Module Address Debug info Name (65 modules) PE 3d0000- 45d000 Deferred hostpolicy PE 570000- ac8000 Deferred coreclr ELF 7b400000- 7b82e000 Deferred kernel32<elf> \-PE 7b420000- 7b82e000 \ kernel32 ELF 7bc00000- 7bd4d000 Deferred ntdll<elf> \-PE 7bc20000- 7bd4d000 \ ntdll ELF 7c000000- 7c004000 Deferred <wine-loader> PE 140000000- 140041000 Deferred pwsh PE 180000000- 18005d000 Deferred hostfxr ... ELF 7fbaa8c000- 7fbaabe000 Deferred ld-linux-aarch64.so.1 ELF 7fbaabf000- 7fbaac0000 Deferred [vdso].so Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\home\focht\projects\woa-winrt\powershell620-arm64\pwsh.exe 0000002b 0 00000009 0 <== ... System information: Wine build: wine-3.21-4-gfc4d5d49c6 Platform: arm64 Version: Windows 7 Host system: Linux Host version: 4.18.14-yocto-standard --- snip --- Debugger session: --- snip --- $ gdb wine64 GNU gdb (GDB) 8.2 ... (gdb) run pwsh.exe Starting program: /home/focht/projects/wine/mainline-install-aarch64/bin/wine64 pwsh.exe ... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ... 0009:fixme:wer:WerRegisterRuntimeExceptionModule (L"Z:\\home\\focht\\projects\\woa-winrt\\powershell620-arm64\\mscordaccore.dll", 0x570000) stub! [New LWP 1027] 0009:fixme:msvcrt:_control87 not implemented Thread 1 "pwsh.exe" received signal SIGSEGV, Segmentation fault. 0x000000000083fc2c in ?? () (gdb) info reg x0 0x18f30000 418578432 x1 0x2ad8a0 2807968 x2 0x0 0 x3 0x8 8 x4 0x1 1 x5 0x4 4 x6 0x1 1 x7 0x7bd4cba0 2077543328 x8 0xc000 49152 x9 0x2ad9d8 2808280 x10 0xffffffff 4294967295 x11 0xffffffff 4294967295 x12 0x0 0 x13 0x18f30040 418578496 x14 0x1 1 x15 0x7bd4cb38 2077543224 x16 0x7bd2e010 2077417488 x17 0x7fbf4d6860 548670367840 x18 0x7ffd8000 2147319808 x19 0xa77348 10974024 x20 0x18f30000 418578432 x21 0x18f30000 418578432 x22 0xf30000 15925248 x23 0x90168 590184 x24 0xa6a270 10920560 x25 0xc4 196 x26 0xa69ea8 10919592 x27 0x30000 196608 x28 0x595290 5853840 x29 0x2ada30 2808368 x30 0x83fbdc 8649692 sp 0x2ada30 0x2ada30 pc 0x83fc2c 0x83fc2c cpsr 0x0 [ EL=0 ] fpsr 0x10 16 fpcr 0x0 0 (gdb) bt #0 0x000000000083fc2c in ?? () #1 0x0000000000a69ea8 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) x/10i $pc => 0x83fc2c: stur wzr, [x13, #-64] 0x83fc30: ldr x11, [x19, #256] 0x83fc34: stp x22, x21, [x13, #-56] 0x83fc38: add x8, x13, x8, lsl #2 0x83fc3c: stur x8, [x13, #-40] 0x83fc40: ldr x8, [sp, #16] 0x83fc44: stp x8, xzr, [x13, #-16] 0x83fc48: ldur x8, [x13, #-40] 0x83fc4c: add x9, x8, x27, lsl #1 0x83fc50: sub x8, x11, #0x1 --- snip --- Disassembly of surrounding code: --- snip --- 00000001802CFBC0 48 08 00 90 ADRP X8, #VirtualAlloc(a)PAGE 00000001802CFBC4 08 7D 41 F9 LDR X8, [X8,#VirtualAlloc(a)PAGEOFF] 00000001802CFBC8 83 00 80 52 MOV W3, #4 00000001802CFBCC 02 00 82 52 MOV W2, #0x1000 00000001802CFBD0 E1 02 00 91 ADD X1, X23, #0 00000001802CFBD4 80 02 00 91 ADD X0, X20, #0 00000001802CFBD8 00 01 3F D6 BLR X8 00000001802CFBDC 40 02 00 B5 CBNZ X0, loc_1802CFC24 ... 00000001802CFC24 E8 13 40 F9 LDR X8, [SP,#0x70+var_50] 00000001802CFC28 8D 02 01 91 ADD X13, X20, #0x40 00000001802CFC2C BF 01 1C B8 STUR WZR, [X13,#-0x40] ; *boom* 00000001802CFC30 6B 82 40 F9 LDR X11, [X19,#0x100] 00000001802CFC34 B6 D5 3C A9 STP X22, X21, [X13,#-0x38] 00000001802CFC38 A8 09 08 8B ADD X8, X13, X8,LSL#2 00000001802CFC3C A8 81 1D F8 STUR X8, [X13,#-0x28] 00000001802CFC40 E8 0B 40 F9 LDR X8, [SP,#0x70+var_60] 00000001802CFC44 A8 7D 3F A9 STP X8, XZR, [X13,#-0x10] 00000001802CFC48 A8 81 5D F8 LDUR X8, [X13,#-0x28] ... --- snip --- The problem domain is the same as bug 46187 - a write watch gets triggered and Wine's signal/exception handling needs to figure it out. In case of aarch32 signal handlers it's a bit easier: the Linux kernel provides the information if the fault was caused by read or write access, see my comment https://bugs.winehq.org/show_bug.cgi?id=46187#c1 for details. In case of aarch64 signal handlers the situation is a bit complicated. The Linux kernel exposes this information to userspace - but only via extended user/signal context information ('esr_context'). https://github.com/torvalds/linux/commit/15af1942dd61ee236a48b3de14d6f31c0b… --- quote --- arm64: Expose ESR_EL1 information to user when SIGSEGV/SIGBUS This information is useful for instruction emulators to detect read/write and access size without having to decode the faulting instruction. The current patch exports it via sigcontext (struct esr_context) and is only valid for SIGSEGV and SIGBUS. Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> --- quote --- https://github.com/torvalds/linux/blob/e195ca6cb6f21633e56322d5aa11ed59cdb2… Wine currently uses a rather crude but acceptable way to figure read-or-write access out by decoding the faulting instruction. https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/signal_arm64.c… --- snip --- 614 static inline DWORD is_write_fault( ucontext_t *context ) 615 { 616 DWORD inst = *(DWORD *)PC_sig(context); 617 if ((inst & 0xbfff0000) == 0x0c000000 /* C3.3.1 */ || 618 (inst & 0xbfe00000) == 0x0c800000 /* C3.3.2 */ || 619 (inst & 0xbfdf0000) == 0x0d000000 /* C3.3.3 */ || 620 (inst & 0xbfc00000) == 0x0d800000 /* C3.3.4 */ || 621 (inst & 0x3f400000) == 0x08000000 /* C3.3.6 */ || 622 (inst & 0x3bc00000) == 0x38000000 /* C3.3.8-12 */ || 623 (inst & 0x3fe00000) == 0x3c800000 /* C3.3.8-12 128bit */ || 624 (inst & 0x3bc00000) == 0x39000000 /* C3.3.13 */ || 625 (inst & 0x3fc00000) == 0x3d800000 /* C3.3.13 128bit */ || 626 (inst & 0x3a400000) == 0x28000000) /* C3.3.7,14-16 */ 627 return EXCEPTION_WRITE_FAULT; 628 return EXCEPTION_READ_FAULT; 629 } --- snip --- Looks like it was "borrowed" from QEMU user: https://github.com/qemu/qemu/commit/661f7fa4b088f2734050a751dd9d1d836b49e981 --- quote --- tcg-aarch64: Properly detect SIGSEGV writes Since the kernel doesn't pass any info on the reason for the fault, disassemble the instruction to detect a store. Reviewed-by: Alex Bennée <alex.bennee(a)linaro.org> Reviewed-by: Claudio Fontana <claudio.fontana(a)huawei.com> Signed-off-by: Richard Henderson <rth(a)twiddle.net> --- quote --- The faulting instruction is: "stur wzr, [x13, -64]" ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile: https://static.docs.arm.com/ddi0487/ca/DDI0487C_a_armv8_arm.pdf --- quote --- C6.2.266 STUR Store Register (unscaled) calculates an address from a base register value and an im mediate offset, and stores a 32-bit word or a 64-bit doubleword to the calculated address, from a register. For information about memory accesses, see Load/Store addressing modes on page C1-149 32-bit variant Applies when size == 10 STUR <Wt>, [<Xn|SP>{, #<simm>}] 64-bit variant Applies when size == 11 STUR <Xt>, [<Xn|SP>{, #<simm>}] Decode for all variants of this encoding integer scale = UInt(size); bits(64) offset = SignExtend(imm9, 64); Assembler symbols <Wt> Is the 32-bit name of the general-purpose register to be transferred, encoded in the "Rt" field. <Xt> Is the 64-bit name of the general-purpose register to be transferred, encoded in the "Rt" field. <Xn|SP> Is the 64-bit name of the general-purpose base register or stack pointer, encoded in the "Rn" field. <simm> Is the optional signed immediate byte offset, in the range -256 to 255, defaulting to 0 and encoded in the "imm9" field. --- quote --- wzr = zero register in 32-bit context 0xb81c01bf 10111000|00011100|00000001|10111111 ----------------------------------- 10 111 0 00|00 0 11100|0000 00 00|101 11111 sz = 10 = 32-bit variant opc = 0 imm9 = 0x1c0 Rn = 5 Rt = 0x1f Using: https://yurichev.com/mirrors/ARMv8-A_Architecture_Reference_Manual_(Issue_A… ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a Section C3.1 "A64 instruction index by encoding": AArch64 main encoding table ... C3.3.12 Load/store register (unscale immediate) --- After spending some hour on looking at ARMv8 processor manuals with magnifying glass, doing manual instruction decoding, almost questioning myself ... I finally spotted the problem. It was decoding an instruction from Wine's own code, not the faulting instruction. Haha - nice one. https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/signal_arm64.c… --- snip --- 428 static EXCEPTION_RECORD *setup_exception( ucontext_t *sigcontext, raise_func func ) 429 { ... 448 /* now modify the sigcontext to return to the raise function */ 449 SP_sig(sigcontext) = (ULONG_PTR)stack; 450 PC_sig(sigcontext) = (ULONG_PTR)func; 451 REGn_sig(0, sigcontext) = (ULONG_PTR)&stack->rec; /* first arg for raise_func */ 452 REGn_sig(1, sigcontext) = (ULONG_PTR)&stack->context; /* second arg for raise_func */ 453 454 return &stack->rec; 455 } --- snip --- https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/signal_arm64.c… --- snip --- 636 static void segv_handler( int signal, siginfo_t *info, void *ucontext ) 637 { 638 EXCEPTION_RECORD *rec; 639 ucontext_t *context = ucontext; ... 656 rec = setup_exception( context, raise_segv_exception ); 657 if (rec->ExceptionCode == EXCEPTION_STACK_OVERFLOW) return; 658 659 switch(signal) 660 { 661 case SIGILL: /* Invalid opcode exception */ 662 rec->ExceptionCode = EXCEPTION_ILLEGAL_INSTRUCTION; 663 break; 664 case SIGSEGV: /* Segmentation fault */ 665 rec->ExceptionCode = EXCEPTION_ACCESS_VIOLATION; 666 rec->NumberParameters = 2; 667 rec->ExceptionInformation[0] = is_write_fault(context); 668 rec->ExceptionInformation[1] = (ULONG_PTR)info->si_addr; 669 break; --- snip --- At the point of 'is_write_fault' call, the context PC is already set to 'raise_segv_exception' function. I guess this code path was never tested - until now ;-) Ideally the instruction disassembly approach should be reconsidered in favour of using extended context information. This will also help later when handling FPU/SIMD/SVE specific exceptions. But that requires more efforts -> future work task. $ sha1sum PowerShell-6.2.0-preview.2-win-arm64.zip 731bf722a0083fbd101598fa42c9f1a0170d6548 PowerShell-6.2.0-preview.2-win-arm64.zip $ du -sh PowerShell-6.2.0-preview.2-win-arm64.zip 40M PowerShell-6.2.0-preview.2-win-arm64.zip Regards -- 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 25776] New: Windows Live Mesh installer renders incorrectly
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=25776 Summary: Windows Live Mesh installer renders incorrectly Product: Wine Version: 1.3.11 Platform: x86-64 URL: http://explore.live.com/windows-live-mesh?os=other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: trygve.vea(a)gmail.com Created an attachment (id=32848) --> (http://bugs.winehq.org/attachment.cgi?id=32848) Terminal output, wine 1.3.11 While attempting to test bug 4538, I'm unable to install Windows Live Mesh due to the installer rendering incorrectly (PS: Prerequisite for getting thus far is setting Windows version to Windows 7). There are no visible buttons, only some text. Uploaded attachment shows terminal output. Will upload screenshot shortly. -- 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 16884] New: .NET 3.0: WCF installer fails due to LsaLookupNames2 stub
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=16884 Summary: .NET 3.0: WCF installer fails due to LsaLookupNames2 stub Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16883 the next one... Prerequisites: --- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- The WCF installer still fails: "c:\\windows\\temp\\dd_wcf_retCA5476.txt": --- snip --- ServiceModelReg [14:57:53:680]: Starting tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"'. ServiceModelReg [14:57:55:965]: Microsoft (R) 32-bit MOF Compiler Version 1.50.1085.0001 ServiceModelReg [14:57:55:966]: Copyright (c) Microsoft Corp. 1997-1999. All rights reserved. ServiceModelReg [14:58:03:464]: ServiceModelReg [14:58:03:467]: Parsing MOF file: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof ServiceModelReg [14:58:06:160]: MOF file has been successfully parsed ServiceModelReg [14:58:06:164]: Storing data in the repository... ServiceModelReg [14:58:07:047]: An error occurred while creating object 3 defined on lines 20 - 24: ServiceModelReg [14:58:07:053]: 0X80041002 Class, instance, or property 'HostingModel' was not found. ServiceModelReg [14:58:07:280]: Compiler returned error 0x80041001 ServiceModelReg [14:58:07:280]: ServiceModelReg [14:58:07:291]: ServiceModelReg [14:58:07:330]: Tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"' exited with code '3'. ServiceModelReg [14:58:07:473]: Warning: Failure executing "C:\windows\system32\wbem\mofcomp.exe" with parameters ""C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"": System.ApplicationException: Unexpected result 3 executing C:\windows\system32\wbem\mofcomp.exe with "C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof" at System.ServiceModel.Install.InstallHelper.ExecuteWait(String program, String parameters, Int32[] allowedExitCodes) at System.ServiceModel.Install.WmiInstallComponent.OnInstall(OutputLevel outputLevel) ServiceModelReg [14:58:08:291]: Error: WMI classes are not installed. ServiceModelReg [14:58:08:304]: Repairing: Windows CardSpace (idsvc) ServiceModelReg [14:58:08:610]: Repairing: Net.Tcp Port Sharing Service (NetTcpPortSharing) ServiceModelReg [14:58:09:011]: System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) at System.Security.Principal.NTAccount.Translate(Type targetType) at System.Security.AccessControl.CommonObjectSecurity.ModifyAccess(AccessControlModification modification, AccessRule rule, Boolean& modified) at System.Security.AccessControl.CommonObjectSecurity.AddAccessRule(AccessRule rule) at System.ServiceModel.Install.ListenerServiceInstallComponent.SetConfigSecurity(OutputLevel outputLevel) at System.ServiceModel.Install.ListenerServiceInstallComponent.OnReinstall(OutputLevel outputLevel) at System.ServiceModel.Install.ServiceInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/11/2009 14:58:09 === --- snip --- Relevant trace log: --- snip --- 0035:fixme:advapi:LsaLookupNames2 (0xcafe,0x00000000,0x00000001,0x1421c0,0x33efdc,0x33efd0) stub ... 0035:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b844f54 ip=0x7b844fd7 tid=0035 0035:trace:seh:raise_exception info[0]=80131501 0035:trace:seh:raise_exception eax=7b82cc91 ebx=7b8c3940 ecx=00000000 edx=0033f0b8 esi=0033f0b8 edi=e0434f4d 0035:trace:seh:raise_exception ebp=0033f080 esp=0033f01c cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 0035:trace:seh:call_stack_handlers calling handler at 0x79f9a3c8 code=e0434f4d flags=1 0035:CALL MSVCR80._except_handler4_common(7a381240,79e717fb,0033f02c,0033f0d0,0033ecb8,0033eb60) ret=79f9a3e7 0035:RET MSVCR80._except_handler4_common() retval=00000001 ret=79f9a3e7 0035:trace:seh:call_stack_handlers handler at 0x79f9a3c8 returned 1 0035:trace:seh:call_stack_handlers calling handler at 0x7a3197d4 code=e0434f4d flags=1 0035:CALL MSVCR80.__CxxFrameHandler3() ret=7bc729f1 0035:RET MSVCR80.__CxxFrameHandler3() retval=00000001 ret=7bc729f1 0035:trace:seh:call_stack_handlers handler at 0x7a3197d4 returned 1 0035:trace:seh:call_stack_handlers calling handler at 0x79f948ec code=e0434f4d flags=1 .... 0035:fixme:advapi:RegisterEventSourceW (L".",L"System.ServiceModel.Install 3.0.0.0"): stub 0035:fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000000,(nil),0x0001,0x00000000,0xa55c64,0xa55b0c): stub 0035:err:eventlog:ReportEventW L"System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.\r\n at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)\r\n at System.Security.Principal.NTAccount.Transla"... --- snip --- Oh joy, LSA again ... There already exist other bugs falling into same problem domain, example: bug 16418 If developer resources are short maybe this could be part of some SoC project: making transition from current approach towards LSA rpc interface and lsass (and fleshing out stubs of course). http://www.hsc.fr/ressources/articles/win_net_srv/msrpc_lsarpc.html I fleshed the stub a bit just for proof and it gets the WCF installer further. 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 11

[Bug 16886] New: .NET 3.0: WCF installer requires ChangeServiceConfig2 with SERVICE_CONFIG_FAILURE_ACTIONS support
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=16886 Summary: .NET 3.0: WCF installer requires ChangeServiceConfig2 with SERVICE_CONFIG_FAILURE_ACTIONS support Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, actually bug 16883 contained two bugs and this one slipped through. ChangeServiceConfig2W API needs SERVICE_CONFIG_FAILURE_ACTIONS support. --- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- Relevant log: --- snip --- ServiceModelReg [16:55:11:288]: Repairing: Windows CardSpace (idsvc) ServiceModelReg [16:55:11:307]: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.ServiceModel.Install.NativeMethods.ChangeFailureActions(ServiceHandle hService, Int32 dwInfoLevel, SERVICE_FAILURE_ACTIONS& lpInfo) at System.ServiceModel.Install.ServiceHandle.SetFailureActions(TimeSpan resetPeriod, TimeSpan[] restartPeriods) at System.ServiceModel.Install.ServiceInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.InfoCardServiceInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.ServiceInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/11/2009 16:55:11 === --- snip --- After fleshing out programs/services/svcctl_ChangeServiceConfig2W() a bit the problem is prevented (fake seems also ok). 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 9

[Bug 16891] New: .NET 3.0: Windows Workflow Foundation installer claims .NET 2.0 Framework needed, MsiNetAssemblySupport/msi fusion version retrieval bug
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=16891 Summary: .NET 3.0: Windows Workflow Foundation installer claims .NET 2.0 Framework needed, MsiNetAssemblySupport/msi fusion version retrieval bug Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16888 another subinstaller "Windows Workflow Foundation" fails, claiming ".NET 2.0 Framework is required". This is of course already installed as part of prerequisite. Prerequisites: --- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- The corresponding logfile "dd_WF_3.0_x86retMSI48DE.txt" reveals nothing, it's empty. Using ORCA on "WF_3.0_x86.msi" shows that MsiNetAssemblySupport >="2.0.50727" condition needs to be satisfied. The "MsiNetAssemblySupport" property should be set in set_msi_assembly_prop() but it doesn't seem so. Trace log shows: --- snip --- 0016:Call version.GetFileVersionInfoSizeW(00149050 L"C:\\windows\\Microsoft.NET\\Framework\\v3.0\\fusion.dll",0032f2d0) ret=6024ad80 0016:Call KERNEL32.GetModuleHandleExW(00000000,00149050,0032ef90) ret=609ecc77 0016:Ret KERNEL32.GetModuleHandleExW() retval=00000000 ret=609ecc77 0016:Call KERNEL32.LoadLibraryExW(00149050 L"C:\\windows\\Microsoft.NET\\Framework\\v3.0\\fusion.dll",00000000,00000002) ret=609ecc99 0016:Call PE DLL (proc=0x60c431f0,module=0x60c40000 L"psapi.dll",reason=PROCESS_ATTACH,res=(nil)) ... 0016:Ret PE DLL (proc=0x60bd98c4,module=0x60bd0000 L"fusion.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0016:Ret KERNEL32.LoadLibraryExW() retval=60bd0000 ret=609ecc99 0016:Call KERNEL32.FindResourceW(60bd0000,00000001,00000010) ret=609ecd25 0016:Ret KERNEL32.FindResourceW() retval=00000000 ret=609ecd25 0016:Call KERNEL32.FreeLibrary(60bd0000) ret=609ecd94 ... 0016:Ret KERNEL32.FreeLibrary() retval=00000001 ret=609ecd94 0016:Call KERNEL32.SetLastError(00000714) ret=609ed6e6 0016:Ret KERNEL32.SetLastError() retval=00000714 ret=609ed6e6 0016:Ret version.GetFileVersionInfoSizeW() retval=00000000 ret=6024ad80 --- snip --- Looking into "C:\\windows\\Microsoft.NET\\Framework\\v3.0\\fusion.dll" path there is no native fusion.dll. Hence Wine's builtin fusion.dll is loaded by LoadLibraryExW(). The builtin fusion doesn't contain version resource so it fails. This is a subtile problem: adding version resource to Wine's fusion might cause problems because every .NET Framework might ship it's own version of fusion which ought to override builtin fusion. http://msdn.microsoft.com/en-us/library/aa370325.aspx Usually: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion.dll C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\fusion.dll AFAIK .NET 3.0 and 3.5 don't bring their own fusion version (someone might check a real Windows installation with these Frameworks present). The problem is how dlls/msi/package.c:get_fusion_filename() works. At the point where the installation fails the following registry data is present at the location get_fusion_filename() reads: --- snip --- [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup] [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP] [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] "Increment"="42" "Install"=dword:00000001 "MSI"=dword:00000001 "SP"=dword:00000000 [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\1033] "Install"=dword:00000001 "MSI"=dword:00000001 "SP"=dword:00000000 [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0] [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup] [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\Windows Communication Foundation] "InstallSuccess"=dword:00000001 "ReferenceInstallPath"="C:\\Program Files\\Reference Assemblies\\Microsoft\\Framework\\v3.0\\" "RuntimeInstallPath"="C:\\windows\\Microsoft.NET\\Framework\\v3.0\\Windows Communication Foundation\\" "Version"="3.0.04506.30" [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.0\Setup\Windows Presentation Foundation] @="Windows Presentation Foundation" "InstallRoot"="C:\\windows\\Microsoft.Net\\Framework\\v3.0\\WPF\\" "InstallSuccess"=dword:00000001 "ProductVersion"="3.0.6920.0" "Version"="3.0.6920.0" "WPFCommonAssembliesPathx86"="C:\\windows\\system32\\" "WPFNonReferenceAssembliesPathx86"="C:\\windows\\Microsoft.Net\\Framework\\v3.0\\WPF\\" "WPFReferenceAssembliesPathx86"="C:\\Program Files\\Reference Assemblies\\Microsoft\\Framework\\v3.0\\" --- snip --- I don't know how Windows msi does MsiNetAssemblySupport. Maybe a check for real existence of (native) fusion.dll to prevent false load of "builtin" fusion is better. If native fusion is not present in full path, that .NET Framework subkey data (version) can't be used for MsiNetAssemblySupport property. 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 16888] New: .NET 3.0: WCF installer requires httpapi.dll with some stubs
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=16888 Summary: .NET 3.0: WCF installer requires httpapi.dll with some stubs Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16883 the next one... Prerequisites: --- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- The WCF installer still fails: --- snip --- ServiceModelReg [15:38:17:256]: Repairing: Net.Tcp Port Sharing Service (NetTcpPortSharing) ServiceModelReg [15:38:17:279]: Uninstalling: HTTP Namespace Reservations ServiceModelReg [15:38:17:294]: System.DllNotFoundException: Unable to load DLL 'httpapi.dll': Exception from HRESULT: 0x8007007E at System.ServiceModel.Install.NativeMethods.HttpTerminate(Int32 Flags, IntPtr pReserved) at System.ServiceModel.Install.HttpNamespaceReservationInstallComponent.get_IsInstalled() at System.ServiceModel.Install.HttpNamespaceReservationInstallComponent.Uninstall(OutputLevel outputLevel) at System.ServiceModel.Install.ServiceModelInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/11/2009 15:38:17 === --- snip --- Native httpapi override makes things only worse since it expects http service present ... --- snip --- ... 0035:CALL HTTPAPI.HttpInitialize(<unknown, check return>) ret=036a22c0 0035:trace:ntdll:NtCreateFile handle=0x67a16094 access=c0100000 name=L"\\Device\\Http\\Control" objattr=00000040 root=(nil) sec=(nil) io=0x33ed54 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000000 ea=0x18fb28.0x0000001f 0035:trace:service:OpenSCManagerW ((null),(null),0x00000001) 0035:trace:service:sc_handle_alloc sc_handle type=0 -> 0x18fb28 ... 0013:trace:service:svcctl_OpenSCManagerW ((null), (null), 1) ... 0035:trace:service:OpenSCManagerW returning 0x18fb28 (access : 0x00000001) 0035:trace:service:OpenServiceW 0x18fb28 L"HTTP" 20 0035:trace:service:sc_handle_alloc sc_handle type=1 -> 0x18f658 ... 0018:trace:service:svcctl_OpenServiceW (L"HTTP", 0x14) ... 0035:trace:service:sc_handle_destroy_service destroying service 0x18f658 0035:trace:service:CloseServiceHandle 0x18fb28 ... 0035:trace:service:sc_handle_destroy_manager destroying SC Manager 0x18fb28 0035:RET HTTPAPI.HttpInitialize(00000001,00000002,00000000) retval=00000003 ret=036a22c0 ... Uninstalling: HTTP Namespace Reservations Error: Path not found fixme:advapi:RegisterEventSourceW (L".",L"System.ServiceModel.Install 3.0.0.0"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000000,(nil),0x0001,0x00000000,0xa534b4,0xa5335c): stub err:eventlog:ReportEventW L"System.ComponentModel.Win32Exception: Path not found\r\n at System.ServiceModel.Install.HttpNamespaceReservationInstallComponent.get_IsInstalled()\r\n at System.ServiceModel.Install.HttpNamespaceReservationInstallComponent.Uninstall(OutputLevel outputLevel)\r\n at System.ServiceModel.Install.Se"... fixme:advapi:DeregisterEventSource (0xcafe4242) stub err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603 ... --- snip --- It seems better to provide a simple httpapi stub dll. MSDN for more info (only version 1 API seems requested): http://msdn.microsoft.com/en-us/library/aa364627.aspx http://msdn.microsoft.com/en-us/library/aa364625.aspx After generating a stub dll with winedump and some trial & error sessions, the minimum required stubs are as follows: --- snip --- HttpDeleteServiceConfiguration -> return NO_ERROR (0) HttpInitialize -> return NO_ERROR (0) HttpQueryServiceConfiguration -> return ERROR_FILE_NOT_FOUND (2) (most likely means the service not installed, passed args can be left untouched with this error) HttpSetServiceConfiguration -> return NO_ERROR (0) HttpTerminate -> return NO_ERROR (0) --- snip --- With those stubs in place, the HTTP api related actions (fake) succeed. --- snip --- ServiceModelReg [16:30:52:470]: Uninstalling: HTTP Namespace Reservations ServiceModelReg [16:30:52:472]: Warning: HTTP namespace reservations are not installed. ServiceModelReg [16:30:52:472]: Installing: HTTP Namespace Reservations ServiceModelReg [16:30:52:473]: Information: The ServiceModelReg tool has completed successfully. --- snip --- and the WCF installer claims success. 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 12

[Bug 16883] New: .NET 3.0: WCF installer fails due bug in services.exe svcctl_GetServiceKeyNameW
by wine-bugs＠winehq.org 22 Mar '21

22 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=16883 Summary: .NET 3.0: WCF installer fails due bug in services.exe svcctl_GetServiceKeyNameW Product: Wine Version: 1.1.12 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =10cc340b-f857-4a14-83f5-25634c3bf043 OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after getting past bug 16882 (WMI is needed) we resume where we left: bug 16878 --- 1. clean WINEPREFIX 2. sh mywinetricks -q wmicore 3. sh winetricks -q dotnet20 4. download .NET 3.0 Framework installer from: http://download.microsoft.com /download/4/d/a/4da3a5fa-ee6a-42b8-8bfa-ea5c4a458a7d/dotnetfx3setup.exe (sha1sum: a566bcd2ffffc3842a95adc57f7df3f8cd11577f) 5. export _SFX_CAB_SHUTDOWN_REQUEST=1 (workaround, see bug 9158) 6. wine ./dotnetfx3setup.exe It might take a while until all required packages are downloaded using BITS. Note: If you need to redo steps, backup the directory "dotnetfx304506.30" from "c:\\windows\\temp" to a different location, remove ~/.wine, copy "dotnetfx304506.30" again to "c:\\windows\\temp" to prevent BITS from downloading over and over again. --- The WCF installer still fails: "c:\\windows\\temp\\dd_dotnetfx3error.txt": --- snip --- [01/11/09,14:18:10] Windows Communication Foundation: [2] Error: Installation failed for component Windows Communication Foundation. MSI returned error code 1603 [01/11/09,14:18:21] WapUI: [2] DepCheck indicates Windows Communication Foundation is not installed. --- snip --- "c:\\windows\\temp\\dd_wcf_retMSI1CB9.txt": --- snip --- 1: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe /r /x /y /v 2: 1: ERROR: Process returned non-0 value! CMDLINE: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe /r /x /y /v 2: 1: Failed 2: --- snip --- --- snip --- ServiceModelReg [14:18:09:203]: Starting tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"'. ServiceModelReg [14:18:09:328]: Microsoft (R) 32-bit MOF Compiler Version 1.50.1085.0001 ServiceModelReg [14:18:09:329]: Copyright (c) Microsoft Corp. 1997-1999. All rights reserved. ServiceModelReg [14:18:09:423]: ServiceModelReg [14:18:09:425]: Parsing MOF file: C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof ServiceModelReg [14:18:09:446]: MOF file has been successfully parsed ServiceModelReg [14:18:09:447]: Storing data in the repository... ServiceModelReg [14:18:10:115]: An error occurred while creating object 3 defined on lines 20 - 24: ServiceModelReg [14:18:10:116]: 0X80041002 Class, instance, or property 'HostingModel' was not found. ServiceModelReg [14:18:10:122]: Compiler returned error 0x80041001 ServiceModelReg [14:18:10:122]: ServiceModelReg [14:18:10:122]: ServiceModelReg [14:18:10:124]: Tool 'C:\windows\system32\wbem\mofcomp.exe' with parameters '"C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"' exited with code '3'. ServiceModelReg [14:18:10:166]: Warning: Failure executing "C:\windows\system32\wbem\mofcomp.exe" with parameters ""C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof"": System.ApplicationException: Unexpected result 3 executing C:\windows\system32\wbem\mofcomp.exe with "C:\windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModel.mof" at System.ServiceModel.Install.InstallHelper.ExecuteWait(String program, String parameters, Int32[] allowedExitCodes) at System.ServiceModel.Install.WmiInstallComponent.OnInstall(OutputLevel outputLevel) ServiceModelReg [14:18:10:231]: Error: WMI classes are not installed. ServiceModelReg [14:18:10:233]: Repairing: Windows CardSpace (idsvc) ServiceModelReg [14:18:10:251]: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.ServiceModel.Install.NativeMethods.ChangeFailureActions(ServiceHandle hService, Int32 dwInfoLevel, SERVICE_FAILURE_ACTIONS& lpInfo) at System.ServiceModel.Install.ServiceHandle.SetFailureActions(TimeSpan resetPeriod, TimeSpan[] restartPeriods) at System.ServiceModel.Install.ServiceInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.InfoCardServiceInstallComponent.OnInstall(OutputLevel outputLevel) at System.ServiceModel.Install.ServiceInstallComponent.Reinstall(OutputLevel outputLevel) at Microsoft.Tools.ServiceModel.ServiceModelReg.PerformAction(ActionItem actionItem, Nullable`1 confirmUninstall) at Microsoft.Tools.ServiceModel.ServiceModelReg.Run(String[] args) at Microsoft.Tools.ServiceModel.ServiceModelReg.TryRun(String[] args) === Verbose logging stopped: 1/11/2009 14:18:10 === --- snip --- Ok, lets leave the WMI failures aside (despite having native WMI core installed) and see how far it goes. That infocard service (re)install looks bugged: --- snip --- 0035:trace:service:OpenSCManagerW ((null),(null),0x00000001) 0035:trace:service:sc_handle_alloc sc_handle type=0 -> 0x18ef38 0013:trace:service:svcctl_OpenSCManagerW ((null), (null), 1) 0035:trace:service:OpenSCManagerW returning 0x18ef38 (access : 0x00000001) 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=0017b820 ret=79e808d5 0035:trace:service:GetServiceKeyNameW 0x18ef38 L"" 0x88e170 0x33f1f0 0014:trace:service:svcctl_GetServiceKeyNameW (L"idsvc", 256) 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=00a4333c ret=79e808d5 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=0017b820 ret=79e808d5 0035:trace:service:GetServiceDisplayNameW 0x18ef38 L"idsvc" 0x17b820 0x33f1f0 0013:trace:service:svcctl_GetServiceDisplayNameW (L"idsvc", 1) 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=00a4333c ret=79e808d5 0035:CALL MSVCR80.memset(0033f0c4,00000000,0000002c,0033f0bc) ret=79eef4cb 0035:RET MSVCR80.memset() retval=0033f0c4 ret=79eef4cb 0035:CALL MSVCR80.memcpy() ret=79e770f8 0035:RET MSVCR80.memcpy() retval=0033f02c ret=79e770f8 0035:CALL MSVCR80.memset(0033ea2c,00000000,0000001c,0033ea70) ret=79e7d873 0035:RET MSVCR80.memset() retval=0033ea2c ret=79e7d873 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=0017b820 ret=79e808d5 0035:CALL MSVCR80.memcpy() ret=79e808d5 0035:RET MSVCR80.memcpy() retval=00a4363c ret=79e808d5 0035:CALL MSVCR80.memcpy() ret=79e770f8 0035:RET MSVCR80.memcpy() retval=0033f10c ret=79e770f8 0035:CALL MSVCR80.memcmp(008647a8,032e66b9,00000012) ret=79efee2f 0035:RET MSVCR80.memcmp() retval=00000000 ret=79efee2f 0035:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b844f54 ip=0x7b844fd7 tid=0035 0035:trace:seh:raise_exception info[0]=80131509 0035:trace:seh:raise_exception eax=7b82cc91 ebx=7b8c3940 ecx=00000000 edx=0033f0f0 esi=0033f0f0 edi=e0434f4d 0035:trace:seh:raise_exception ebp=0033f0b8 esp=0033f054 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 0035:trace:seh:call_stack_handlers calling handler at 0x79f9a3c8 code=e0434f4d flags=1 0035:CALL MSVCR80._except_handler4_common(7a381240,79e717fb,0033f064,0033f108,0033ecf0,0033eb90) ret=79f9a3e7 0035:RET MSVCR80._except_handler4_common() retval=00000001 ret=79f9a3e7 0035:trace:seh:call_stack_handlers handler at 0x79f9a3c8 returned 1 0035:trace:seh:call_stack_handlers calling handler at 0x7a3197d4 code=e0434f4d flags=1 --- snip --- If we dump the corresponding SCM entry: --- snip --- 000d:trace:service:scmdatabase_load_services Loading service L"idsvc" 000d:trace:service:load_service_config Image path = L"\"C:\\windows\\Microsoft.NET\\Framework\\v3.0\\Windows Communication Foundation\\infocard.exe\"" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"Windows CardSpace" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) --- snip --- That GetServiceKeyNameW() API failure seems to be ok because the app passes the key name itself "idsvc" and not the service display name. The following GetServiceDisplayNameW() also fails, leading to app error/exception. If you look closer, you see svcctl_GetServiceDisplayNameW (L"idsvc", 1) -> buffer length "1" passed. This is clearly not what the app intended. The app reuses the length parameter from GetServiceKeyNameW(), passing it again into GetServiceDisplayNameW() but Wine changed it to "1" which seems incorrect. --- snip programs/services/rpc.c --- DWORD svcctl_GetServiceKeyNameW( SC_RPC_HANDLE hSCManager, LPCWSTR lpServiceDisplayName, WCHAR *lpBuffer, DWORD cchBufSize, DWORD *cchLength) { ... entry = scmdatabase_find_service_by_displayname(manager->db, lpServiceDisplayName); if (entry != NULL) { ... else { *cchLength = 1; err = ERROR_SERVICE_DOES_NOT_EXIST; } scmdatabase_unlock(manager->db); if (err != ERROR_SUCCESS && cchBufSize > 0) lpBuffer[0] = 0; return err; } --- snip programs/services/rpc.c -- This doesn't look right, a conformance test case should reveal the correct behaviour. I already verified this with a patch. 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 12