June 2009 - Wine-Bugs - list.winehq.org

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

March 22, 2021

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

[Bug 16893] New: .NET 3.0: Windows Workflow Foundation post-install: loadperf needs LoadPerfCounterTextStringsA/W stubs
by wine-bugs＠winehq.org March 22, 2021

March 22, 2021

http://bugs.winehq.org/show_bug.cgi?id=16893 Summary: .NET 3.0: Windows Workflow Foundation post-install: loadperf needs LoadPerfCounterTextStringsA/W 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 16891 the WF post install fails while running performance counter registration. Thanks to recent fixture of bug 12099 we have loadperf dll already in place... --- snip --- ... wine: Call from 0x7b844f54 to unimplemented function loadperf.dll.LoadPerfCounterTextStringsW, aborting fixme:advapi:CheckTokenMembership (0x188 0x1baf48 0x33e2c8) stub! fixme:imm:ImmDisableIME (-1): stub fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x000003e8,(nil),0x0008,0x0000011a,0x3009a1b4,0x7ed505c0): stub err:eventlog:ReportEventW L"performancecounterinstaller.exe" err:eventlog:ReportEventW L"3.0.4203.2" err:eventlog:ReportEventW L"44c6ca00" err:eventlog:ReportEventW L"kernel32.dll" err:eventlog:ReportEventW L"5.1.2600.2180" err:eventlog:ReportEventW L"00000000" err:eventlog:ReportEventW L"0" err:eventlog:ReportEventW L"00024f54" fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet Unhandled Exception: System.Runtime.InteropServices.SEHException: External component has thrown an exception. at System.Workflow.NativeMethods.LoadPerfCounterTextStrings(String commandLine, Boolean quietMode) at System.Workflow.PerformanceCounterInstaller.Install() at System.Workflow.PerformanceCounterInstaller.Main(String[] args) wine: Unimplemented function loadperf.dll.LoadPerfCounterTextStringsW called at address 0x7b844f54 (thread 000c), starting debugger... Unhandled exception: unimplemented function loadperf.dll.LoadPerfCounterTextStringsW called in 32-bit code (0x7b844fd7). --- snip --- To reproduce this problem manually, execute the following: --- snip --- $ pwd /home/focht/.wine/drive_c/windows/Microsoft.NET/Framework/v3.0/Windows Workflow Foundation $ wine ./PerformanceCounterInstaller.exe uninstall ... $ wine ./PerformanceCounterInstaller.exe install --- snip --- The uninstall step is needed otherwise the registry keys are not explicitly removed and "install" will short-circuit, not doing anything useful. With stubs to loadperf added in similar manner like UnloadPerfCounterTextStringsA/W, we can get past this: --- snip --- $ WINEDEBUG=+tid,+seh,+loadperf wine ./PerformanceCounterInstaller.exe install ... 0009:trace:loadperf:DllMain (0x0x60cb0000, 1, (nil)) 0009:fixme:loadperf:LoadPerfCounterTextStringsW (L" \"C:\\windows\\Microsoft.NET\\Framework\\v3.0\\Windows Workflow Foundation\\PerfCounters.ini\"", 1): stub ... --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 17902] New: ole32.CoGetClassObject: threads without apartment should use existing MTA
by wine-bugs＠winehq.org March 21, 2021

March 21, 2021

http://bugs.winehq.org/show_bug.cgi?id=17902 Summary: ole32.CoGetClassObject: threads without apartment should use existing MTA Product: Wine Version: 1.1.18 Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?FamilyID =fe6f2099-b7b4-4f47-a244-c96d69c35dec OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, there are apps which use free threaded COM (inproc) servers and call CoGetClassObject() from (new) threads that do not explicitly initialize COM. This is valid behaviour when one of the existing threads already created the MTA by calling CoInitializeEx(NULL, COINIT_MULTITHREADED). See: http://support.microsoft.com/kb/150777 --- quote --- Current implementations of COM allow a thread that does not explicitly initialize COM to be a part of the MTA. A thread that does not initialize COM is part of the MTA only if it starts using COM after at least one other thread in the process has previously called CoInitializeEx(NULL, COINIT_MULTITHREADED). (It is even possible that COM itself may have initialized the MTA when no client thread has explicitly done so; for example, a thread associated with an STA calls CoGetClassObject/CoCreateInstance[Ex] on a CLSID that is marked "ThreadingModel=Free" and COM implicitly creates an MTA into which the class object is loaded.) See the information on threading model interoperability below. However, this is a configuration that might cause problems, such as access violations, under certain circumstances. Therefore, it is strongly recommended that each thread that needs to do COM work initialize COM by calling CoInitializeEx and then, on completion of COM work, call CoUninitialize. The cost of "unnecessarily" initializing an MTA is minimal. --- quote --- An example app suffering from this is the managed console debugger from .NET 2.0 SDK "cordbg.exe": When trying to debug a simple console C# app created with symbols (.pdb format): --- snip --- wine "C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\csc.exe" /debug+ foo.cs --- snip --- Start debugger: --- snip --- wine "C:\\Program Files\\Microsoft.NET\\SDK\\v2.0\\Bin\\cordbg.exe foo.exe" --- snip --- The debugger will immediately begin to execute the app - not halting in Main() method (source). This is because symbol information can't be loaded using COR symbol binder which lives in a free threaded COM inproc server. 0A29FF9E-7F9C-4437-8B11-F424491E3931 -> CLSID_CorSymBinder Threads 0x38 (main) and 0x36 call "CoInitializeEx" with COINIT_MULTITHREADED, creating the MTA. Thread 0x3b is created later as pooled thread - part of MTA - to serve CLR debugger requests (work items). That thread never makes any init calls to COM (verified). --- snip --- ... 0038:Call KERNEL32.GetProcAddress(60970000,7a37e2ae "CoInitializeEx") ret=79e9d311 0038:Ret KERNEL32.GetProcAddress() retval=609750c8 ret=79e9d311 0038:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8 0038:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499 0038:Ret ntdll.RtlAllocateHeap() retval=0014f9c0 ret=60986499 0038:Call ntdll.RtlAllocateHeap(00110000,00000000,00000028) ret=609a750c 0038:Ret ntdll.RtlAllocateHeap() retval=001500e8 ret=609a750c 0038:Call KERNEL32.InitializeCriticalSection(001500f8) ret=609a7543 0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=609a7543 0038:Call ntdll.RtlAllocateHeap(00110000,00000008,0000007c) ret=60983f54 0038:Ret ntdll.RtlAllocateHeap() retval=00151df0 ret=60983f54 0038:Call KERNEL32.InitializeCriticalSection(00151e10) ret=60983fb4 0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=60983fb4 0038:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8 ... 0036:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8 0036:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499 0036:Ret ntdll.RtlAllocateHeap() retval=00151e78 ret=60986499 0036:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8 ... 003b:Call advapi32.RegOpenKeyExW(80000000,0310d170 L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32",00000000,00020019,0310d0dc) ret=79ea5b8a 003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a 003b:Call ... 003b:Call advapi32.RegOpenKeyExW(00000238,0310d270 L"2.0.50727",00000000,00020019,0310d0ec) ret=79ea5b8a 003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a 003b:Call advapi32.RegQueryValueExW(0000023c,7a136a40 L"ImplementedInThisVersion",00000000,0310d0e4,00000000,0310d0e8) ret=79ea5bd0 003b:Ret advapi32.RegQueryValueExW() retval=00000000 ret=79ea5bd0 003b:Call advapi32.RegCloseKey(0000023c) ret=7a1369f2 003b:Ret advapi32.RegCloseKey() retval=00000000 ret=7a1369f2 ... 003b:Call advapi32.RegOpenKeyExW(80000000,0310d318 L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32\\2.0.50727",00000000,00020019,0310d314) ret=79ea5b8a 003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a 003b:Call advapi32.RegQueryValueExW(00000238,79f873d0 L"Class",00000000,0310d2f8,00000000,0310d310) ret=79ea5bd0 003b:Ret advapi32.RegQueryValueExW() retval=00000002 ret=79ea5bd0 003b:Call advapi32.RegCloseKey(00000238) ret=79f88946 003b:Ret advapi32.RegCloseKey() retval=00000000 ret=79f88946 ... 003b:Call KERNEL32.GetProcAddress(60970000,7a37e222 "CoGetClassObject") ret=79e9d311 003b:Ret KERNEL32.GetProcAddress() retval=60974f78 ret=79e9d311 003b:Call ole32.CoGetClassObject(00175d3c,00000015,00000000,79f83a7c,0310d5e8) ret=7a041335 003b:err:ole:CoGetClassObject apartment not initialised 003b:Ret ole32.CoGetClassObject() retval=800401f0 ret=7a041335 003b:Call KERNEL32.GetLastError() ret=79e74ab4 003b:Ret KERNEL32.GetLastError() retval=0000007f ret=79e74ab4 000007f ret=78132d14 ... 003b:Call KERNEL32.FormatMessageW(000031ff,00000000,800401f0,00000400,0310d4f4,00000000,0310d4a0) ret=7a127c38 003b:Ret KERNEL32.FormatMessageW() retval=00000000 ret=7a127c38 --- quote --- The failure is due to Wine's CoGetClassObject() rejecting requests when no apartment in current thread (oletls) exists. --- snip dlls/ole32/compobj.c --- HRESULT WINAPI CoGetClassObject( REFCLSID rclsid, DWORD dwClsContext, COSERVERINFO *pServerInfo, REFIID iid, LPVOID *ppv) { LPUNKNOWN regClassObject; HRESULT hres = E_UNEXPECTED; APARTMENT *apt; TRACE("\n\tCLSID:\t%s,\n\tIID:\t%s\n", debugstr_guid(rclsid), debugstr_guid(iid)); if (!ppv) return E_INVALIDARG; *ppv = NULL; apt = COM_CurrentApt(); if (!apt) { ERR("apartment not initialised\n"); return CO_E_NOTINITIALIZED; } ... --- snip dlls/ole32/compobj.c --- Rather than failing CoGetClassObject() without apartment, it should look for an existing MTA and let the current thread use it. With the MTA being used, the inproc server is created and the app works as intended, e.g. symbols get loaded, source can be stepped ... 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 18531] New: FontValidator (.NET based app) needs OleInPlaceObject_InPlaceDeactivate properly implemented
by wine-bugs＠winehq.org March 21, 2021

March 21, 2021

http://bugs.winehq.org/show_bug.cgi?id=18531 Summary: FontValidator (.NET based app) needs OleInPlaceObject_InPlaceDeactivate properly implemented Product: Wine Version: 1.1.21 Platform: Other URL: http://www.microsoft.com/typography/FontValidator.mspx OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: shdocvw AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, now that some urlmon MIME support patches are on the way which are essential for this app ("text/xml" MIME is later needed to show XML content in embedded browser window) I file an "intermediate" bug that needs to be fixed before we can verify the new functionality with real apps ;-) The story is basically about in-place activation and deactivation of embedded browser control. The current shdocvw OleInPlaceObject_InPlaceDeactivate stub is mostly harmless for many embedded browser control hosting apps because they don't rely on the fact that in-place deactivation doesn't really take place (control will be destroyed shortly anyway). This app use case is a bit special hence the current in-place deactivation stub becomes the culprit. Steps to reproduce: 1. clean WINEPREFIX 2. winetricks -q dotnet20 3. start app, "Font files" -> "Add..." -> select whatever true/opentype font from your system 4. "Table tests" -> "Clear All" -> select only "BASE" (shortens test) 5. "Rasterization" -> deselect "Test rasterization of TrueType outlines" (shortens test) 6. hit "Start validation" The .NET 2.0 app creates an embedded browser control: --- snip --- ... 0029:trace:ole:CoCreateInstance (rclsid={8856f961-340a-11d0-a96b-00c04fd705a2}, pUnkOuter=(nil), dwClsContext=00000001, riid={00000000-0000-0000-c000-000000000046}, ppv=0x32e2a4) ... 0029:fixme:shell:URL_ParseUrl failed to parse L"Interop.SHDocVw" ... 0029:trace:win:WIN_CreateWindowEx L"Shell Embedding" L"Shell Embedding" ex=00000100 style=46010000 0,0 0x0 parent=0x500b4 menu=(nil) inst=0x61020000 params=0x136d00 ... 0029:trace:win:WIN_CreateWindowEx created window 0x100b6 ... 0029:trace:shdocvw:create_shell_embedding_hwnd parent=0x500b4 hwnd=0x100b6 ... 0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x500b4 0xadd434) 0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE ... 0029:trace:win:DestroyWindow (0x500b4) ... --- snip --- and a "parking window" to host the control in inactive/hidden state until the real hosting window is about to be created and displayed to avoid runtime penalties of destroying and recreating browser control each time. This blog gives some insight in the world of "parking windows": http://blogs.msdn.com/sburke/archive/2007/06/20/flashback-windows-forms-par… --- snip --- 0029:trace:win:WIN_CreateWindowEx L"WindowsFormsParkingWindow" L"WindowsForms10.Window.8.app.0.378734a" ex=00010000 style=02010000 0,0 0x0 parent=0xfffffffd menu=(nil) inst=0x400000 params=(nil) ... 0029:trace:win:WIN_CreateWindowEx created window 0x100b8 0029:trace:win:show_window hwnd=0x100b6, cmd=0, wasVisible 1 ... 0029:fixme:shdocvw:OleInPlaceObject_InPlaceDeactivate (0x136d00) 0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11 0029:trace:ole:GetErrorInfo (0, 0x32d9b0, 0x19a9c4) 0029:fixme:shdocvw:WebBrowser_QueryInterface (0x136d00)->({df0b3d60-548f-101b-8e65-08002b2bd119} 0x32d9a8) interface not supported 0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10 0029:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84385b ip=7b84385b tid=0029 ... 0029:trace:win:WIN_SetWindowLong 0x100b6 -4 61031784 W 0029:trace:win:alloc_winproc reusing 0xffff0057 for (nil)/0x61031784 0029:trace:win:WIN_DestroyWindow 0x500b4 --- snip --- The CLR exceptions resulting from E_NOTIMPL of OleInPlaceObject_InPlaceDeactivate are handled gracefully. The window which is the real target for the browser control gets created later: --- snip --- 0029:trace:win:WIN_CreateWindowEx L"C:\\windows\\temp\\tmp47b0.tmp.report.xml" L"WindowsForms10.Window.8.app.0.378734a" ex=00050040 style=46cf0000 -2147483648,-2147483648 376x358 parent=0x10088 menu=(nil) inst=0x400000 params=(nil) ... 0029:trace:win:WIN_CreateWindowEx hwnd 0x600b4 cs 0,0 376x358 ... 0029:trace:win:show_window hwnd=0x600b4, cmd=5, wasVisible 0 0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11 0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x600b4 0xaece88) 0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE 0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10 0029:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b84385b ip=7b84385b tid=0029 0029:trace:seh:raise_exception info[0]=80131509 0029:trace:seh:raise_exception eax=7b82ca1d ebx=7b8c2918 ecx=00000000 edx=0032d958 esi=0032d958 edi=e0434f4d 0029:trace:seh:raise_exception ebp=0032d920 esp=0032d8bc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 --- snip --- The CLR exception leads to following backtrace dialog (and abort): --- snip --- ************** Exception Text ************** System.InvalidOperationException: Unable to get the window handle for the 'AxWebBrowser' control. Windowless ActiveX controls are not supported. at System.Windows.Forms.AxHost.EnsureWindowPresent() at System.Windows.Forms.AxHost.InPlaceActivate() at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state) at System.Windows.Forms.AxHost.CreateHandle() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl() at System.Windows.Forms.Control.WmShowWindow(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ContainerControl.WndProc(Message& m) at System.Windows.Forms.Form.WmShowWindow(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) --- snip --- The activate_inplace() OLE verb bails out early because Wine thinks the control is in-place activated (This->inplace) -> real in-place deactivation never took place. .NET runtime tries to fetch hosted control's window handle which fails because no parent switch was done. Adding simple in-place deactivation (releasing IOleInPlaceSite, resetting This->inplace) lets this app succeed, having windows properly switched/re-parented. 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 18640] New: .NET 3.0 WPF requires IDirect3D9Ex to be functional
by wine-bugs＠winehq.org March 21, 2021

March 21, 2021

http://bugs.winehq.org/show_bug.cgi?id=18640 Summary: .NET 3.0 WPF requires IDirect3D9Ex to be functional Product: Wine Version: 1.1.22 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, another one, rotting on harddisk half a year now (since first .NET 3.0 voyage) - before it gets lost. --- snip --- ... fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17b328)->(0, 0x1814d0) fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17b328)->(0, 0x181568, 0x181580): Stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533546e4, (nil)) stub! ... err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller: Could not create display set. fixme:d3d9:IDirect3D9ExImpl_GetAdapterLUID (0x17a388)->(0, 0x19bcc0) fixme:d3d9:IDirect3D9ExImpl_GetAdapterDisplayModeEx (0x17a388)->(0, 0x19bd58, 0x19bd70): Stub! fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533547a4, (nil)) stub! err:ntdll:vDbgPrintExWithPrefix 65: MIL FAILURE: Unexpected HRESULT 0x88760827 in caller: The render thread failed unexpectedly. fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533548ac, (nil)) stub! ... fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework.resources" ... fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00001388,(nil),0x000b,0x00000102,0x3009a1b4,0x6cc5c4): stub err:eventlog:ReportEventW L"clr20r3" err:eventlog:ReportEventW L"viewer.exe" err:eventlog:ReportEventW L"1.0.0.0" err:eventlog:ReportEventW L"473fefa6" err:eventlog:ReportEventW L"presentationframework" err:eventlog:ReportEventW L"3.0.0.0" err:eventlog:ReportEventW L"45398c20" err:eventlog:ReportEventW L"6496" err:eventlog:ReportEventW L"be" err:eventlog:ReportEventW L"system.windows.markup.xamlparse" err:eventlog:ReportEventW L"NIL" fixme:advapi:DeregisterEventSource (0xcafe4242) stub ... Unhandled Exception: System.Windows.Markup.XamlParseException: Cannot create instance of 'MainWindow' defined in assembly 'Viewer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963dca5fb49a45ad'. Exception has been thrown by the target of an invocation. Error in markup file 'MainWindow.xaml'. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Windows.Markup.XamlParseException: 'Menu' object cannot be added to 'Grid'. Exception from HRESULT: 0x88980406 Error at object 'System.Windows.Controls.Menu' in markup file 'Viewer;component/mainwindow.xaml'. ---> System.Runtime.InteropServices.COMException (0x88980406): Exception from HRESULT: 0x88980406 at MS.Internal.HRESULT.Check(Int32 hr) at System.Windows.Media.Composition.DUCE.Channel.SyncFlush() at System.Windows.Media.MediaContext.CompleteRender() at System.Windows.Media.MediaContext.CreateChannels() at System.Windows.Media.MediaSystem.ConnectChannels(MediaContext mc) at System.Windows.Media.MediaContext..ctor(Dispatcher dispatcher) at System.Windows.Media.MediaContext.From(Dispatcher dispatcher) at System.Windows.Media.VisualCollection.Add(Visual visual) at System.Windows.Controls.UIElementCollection.AddInternal(UIElement element) at System.Windows.Controls.UIElementCollection.Add(UIElement element) at System.Windows.Controls.UIElementCollection.System.Collections.IList.Add(Object value) at System.Windows.Markup.BamlRecordReader.AddToContentProperty(Object container, Object contentProperty, Object value) ... --- snip --- IDirect3D9ExImpl_GetAdapterLUID IDirect3D9ExImpl_GetAdapterDisplayModeEx currently return D3DERR_DRIVERINTERNALERROR 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 41

[Bug 18638] New: .NET 3.0 apps abort with: Call from to unimplemented function GDI32.dll.GdiEntry13, aborting
by wine-bugs＠winehq.org March 21, 2021

March 21, 2021

http://bugs.winehq.org/show_bug.cgi?id=18638 Summary: .NET 3.0 apps abort with: Call from to unimplemented function GDI32.dll.GdiEntry13, aborting Product: Wine Version: 1.1.22 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, another one, rotting on harddisk half a year now (since first .NET 3.0 voyage) - before it gets lost. --- snip --- Wine: Call from 0x53214562 to unimplemented function GDI32.dll.GdiEntry13, aborting fixme:advapi:CheckTokenMembership (0x204 0x192490 0x7eb318a8) stub! fixme:imm:ImmDisableIME (-1): stub fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x000003e8,nil),0x0008,0x000000ea,0x3009a1b4,0x7ed505c0): stub err:eventlog:ReportEventW L"viewer.exe" err:eventlog:ReportEventW L"1.0.0.0" err:eventlog:ReportEventW L"473fefa6" err:eventlog:ReportEventW L"milcore.dll" err:eventlog:ReportEventW L"6.0.5840.16386" err:eventlog:ReportEventW L"4539975a" err:eventlog:ReportEventW L"0" err:eventlog:ReportEventW L"00084562" fixme:advapi:DeregisterEventSource (0xcafe4242) stub --- snip --- A simple stub is enough. See: http://msdn.microsoft.com/en-us/library/ms648442.aspx 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 18639] New: .NET 3.0 WPF needs NtSecureConnectPort stub
by wine-bugs＠winehq.org March 21, 2021

March 21, 2021

http://bugs.winehq.org/show_bug.cgi?id=18639 Summary: .NET 3.0 WPF needs NtSecureConnectPort stub Product: Wine Version: 1.1.22 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, another one, rotting on harddisk half a year now (since first .NET 3.0 voyage) - before it gets lost. --- snip --- $ wine ./Viewer.exe fixme:ole:CoGetContextToken stub fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework" fixme:shell:URL_ParseUrl failed to parse L"WindowsBase" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"PresentationCore" fixme:advapi:RegisterTraceGuidsW 0x6307f2 (nil) 0x32dfc4 1 0x32dfa0 (null) (null) 0x32dfa8 fixme:shell:URL_ParseUrl failed to parse L"Viewer.resources" fixme:shell:URL_ParseUrl failed to parse L"Viewer.resources" fixme:shell:URL_ParseUrl failed to parse L"Engine" fixme:shell:URL_ParseUrl failed to parse L"msvcm90" fixme:shell:URL_ParseUrl failed to parse L"Cube" fixme:advapi:RegisterTraceGuidsW 0x532dc234 (nil) 0x53218780 27 0x32d050 (null) (null) 0x53355f40 fixme:seh:RtlCaptureStackBackTrace (2, 3, 0x533546cc, (nil)) stub! wine: Call from 0x7bc3c616 to unimplemented function ntdll.dll.NtSecureConnectPort, aborting fixme:shell:URL_ParseUrl failed to parse L"PresentationFramework.resources" fixme:advapi:CheckTokenMembership (0x1c4 0x174c50 0x32d5f8) stub! fixme:imm:ImmDisableIME (-1): stub fixme:thread:NtQueryInformationThread Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime 2.0 Error Reporting"): stub fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00001388,(nil),0x000b,0x00000102,0x3009a1b4,0x7ed505c4): stub err:eventlog:ReportEventW L"clr20r3" err:eventlog:ReportEventW L"viewer.exe" err:eventlog:ReportEventW L"1.0.0.0" err:eventlog:ReportEventW L"473fefa6" err:eventlog:ReportEventW L"presentationframework" err:eventlog:ReportEventW L"3.0.0.0" err:eventlog:ReportEventW L"45398c20" err:eventlog:ReportEventW L"6496" err:eventlog:ReportEventW L"be" err:eventlog:ReportEventW L"system.windows.markup.xamlparse" err:eventlog:ReportEventW L"NIL" fixme:advapi:DeregisterEventSource (0xcafe4242) stub fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:NtQueryInformationThread info class 9 not supported yet Unhandled Exception: System.Windows.Markup.XamlParseException: Cannot create instance of 'MainWindow' defined in assembly 'Viewer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963dca5fb49a45ad'. Exception has been thrown by the target of an invocation. Error in markup file 'MainWindow.xaml'. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Window' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.FrameworkElement' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Documents.TextElement' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Media.FontFamily' threw an exception. ---> System.Runtime.InteropServices.SEHException: External component has thrown an exception. at NtSecureConnectPort(Void** , _UNICODE_STRING* , _SECURITY_QUALITY_OF_SERVICE* , _PORT_VIEW* , Void* , _REMOTE_PORT_VIEW* , UInt32* , Void* , UInt32* ) at MS.Internal.FontCache.LPCServices.TryConnectToLPCPort(String portName, Void* rawExpectedSid, Byte[] connectBuffer, Int32& errorCode) at MS.Internal.FontCache.LPCServices.TryConnectToLPCPort(String portName, Sid expectedSid, Byte[] connectBuffer, Int32& errorCode) at MS.Internal.FontCache.LPCProtocol.TryConnectToServer(Int32 timeout, Int32& errorCode) at MS.Internal.FontCache.IPCCacheManager.GetServerSectionName(Int32 timeout, Int32& errorCode) at MS.Internal.FontCache.CacheManager.GetServerCache() at MS.Internal.FontCache.CacheManager.Lookup(IFontCacheElement e) at System.Windows.Media.FontFamily.PreCreateDefaultFamilyCollection() at System.Windows.Media.FontFamily..cctor() ... at Viewer.App.Main() wine: Unhandled exception 0xe0434f4d at address 0x7b844f6c (thread 003e), starting debugger... Unhandled exception: 0xe0434f4d in 32-bit code (0x7b844fef). --- snip --- A simple stub returning STATUS_NOT_IMPLEMENTED is enough. 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 17

[Bug 17212] New: Unimplemented function ntoskrnl.exe.KeInitializeMutex
by wine-bugs＠winehq.org March 20, 2021

March 20, 2021

http://bugs.winehq.org/show_bug.cgi?id=17212 Summary: Unimplemented function ntoskrnl.exe.KeInitializeMutex Product: Wine Version: 1.1.13 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntoskrnl AssignedTo: wine-bugs(a)winehq.org ReportedBy: mc2374(a)mclink.it Created an attachment (id=19133) --> (http://bugs.winehq.org/attachment.cgi?id=19133) Console output from the aborted installation Trying to install Acronis True Image Home 11. After some 'err' and 'fixme' (mostly in the msi component), the installation process halts with the above console message and throws 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 28

[Bug 16041] New: Acronis Crash while install
by wine-bugs＠winehq.org March 20, 2021

March 20, 2021

http://bugs.winehq.org/show_bug.cgi?id=16041 Summary: Acronis Crash while install Product: Wine Version: 1.1.8 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: james2432(a)gmail.com Created an attachment (id=17266) --> (http://bugs.winehq.org/attachment.cgi?id=17266) Backtrace of acronis 12 crashing While running the acronis home 12 the installer crashes -- 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 19

[Bug 16946] New: Calling CloseServiceHandle() multiple times on same client side service handle corrupts heap
by wine-bugs＠winehq.org March 19, 2021

March 19, 2021

http://bugs.winehq.org/show_bug.cgi?id=16946 Summary: Calling CloseServiceHandle() multiple times on same client side service handle corrupts heap Product: Wine Version: 1.1.12 Platform: Other URL: http://www.nbc.com/Video/NBCDirectInstaller.exe OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, I've seen this some time ago but forgot about it until encountering it again recently while investigating bug 16626 (this is follow up bug). Prerequisite: --- snip --- $ rm -rf ~/.wine $ winetricks -q wmp10 dotnet20 mdac28 $ wine NBCDirectInstaller.exe --- snip --- The installer uses managed (.NET) wrapper for SCM to fetch a list of current services using EnumServicesStatus(). First call to EnumServicesStatus() to query for buffer size and second time to get the real list. Although M$ .NET Framework error handling is somewhat questionable (it doesn't even check for failure on first call), it's actually Wine's management of client side service handles that causes the breakage. --- snip --- ... 0009:Call advapi32.OpenSCManagerW(00000000,00000000,00000004) ret=03f72620 0009:trace:service:OpenSCManagerW ((null),(null),0x00000004) 0009:trace:service:sc_handle_alloc sc_handle type=0 -> 0x1b1fc0 ... 0013:trace:service:svcctl_OpenSCManagerW ((null), (null), 4) ... 0009:trace:service:OpenSCManagerW returning 0x1b1fc0 (access : 0x00000004) 0009:Ret advapi32.OpenSCManagerW() retval=001b1fc0 ret=03f72620 ... 0009:Call advapi32.EnumServicesStatusW(001b1fc0,00000030,00000003,00000000,00000000,0032f32c,0032f328,0032f324) ret=03f726df 0009:fixme:service:EnumServicesStatusW 0x1b1fc0 type=30 state=3 (nil) 0 0x32f32c 0x32f328 0x32f324 0009:Ret advapi32.EnumServicesStatusW() retval=00000000 ret=03f726df 0009:Call KERNEL32.GetLastError() ret=03f726e5 0009:Ret KERNEL32.GetLastError() retval=00000005 ret=03f726e5 0009:Call KERNEL32.LocalAlloc(00000000,00000000) ret=04248243 0009:Ret KERNEL32.LocalAlloc() retval=03ec9988 ret=04248243 0009:Call advapi32.EnumServicesStatusW(001b1fc0,00000030,00000003,03ec9988,00000000,0032f32c,0032f328,0032f324) ret=03f726df 0009:fixme:service:EnumServicesStatusW 0x1b1fc0 type=30 state=3 0x3ec9988 0 0x32f32c 0x32f328 0x32f324 0009:Ret advapi32.EnumServicesStatusW() retval=00000000 ret=03f726df 0009:Call KERNEL32.GetLastError() ret=03f726e5 0009:Ret KERNEL32.GetLastError() retval=00000005 ret=03f726e5 ... 0009:Call advapi32.CloseServiceHandle(001b1fc0) ret=007aa722 0009:trace:service:CloseServiceHandle 0x1b1fc0 ... 0009:trace:service:sc_handle_destroy_manager destroying SC Manager 0x1b1fc0 0009:Ret advapi32.CloseServiceHandle() retval=00000001 ret=007aa722 ... --- snip --- Releasing the same client handle again: --- snip --- 0009:Call advapi32.CloseServiceHandle(001b1fc0) ret=007aa722 0009:trace:service:CloseServiceHandle 0x1b1fc0 0009:Call rpcrt4.NdrClientInitializeNew(0032ef8c,0032f06c,60376640,00000000) ret=60366f60 0009:Ret rpcrt4.NdrClientInitializeNew() retval=0032f06c ret=60366f60 0009:Call rpcrt4.NdrGetBuffer(0032f06c,00000018,00000000) ret=60366fbe 0009:err:rpc:I_RpcGetBuffer no binding 0009:Call KERNEL32.RaiseException(000006a6,00000000,00000000,00000000) ret=60b21399 0009:trace:seh:raise_exception code=6a6 flags=0 addr=0x7b844f6c ip=0x7b844fef tid=0009 0009:trace:seh:raise_exception eax=7b82cca9 ebx=7b8c3940 ecx=00000000 edx=00000010 esi=0032ee90 edi=0032ee10 0009:trace:seh:raise_exception ebp=0032edf8 esp=0032ed94 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000246 0009:trace:seh:call_stack_handlers calling handler at 0x60366cec code=6a6 flags=0 0009:trace:seh:call_stack_handlers handler at 0x60366cec returned 1 0009:trace:seh:call_stack_handlers calling handler at 0x6036266f code=6a6 flags=0 0009:Call rpcrt4.I_RpcExceptionFilter(000006a6) ret=60360fdd 0009:Ret rpcrt4.I_RpcExceptionFilter() retval=00000001 ret=60360fdd 0009:trace:seh:__regs_RtlUnwind code=6a6 flags=2 0009:trace:seh:__regs_RtlUnwind calling handler at 0x7bc3b2ec code=6a6 flags=2 0009:trace:seh:__regs_RtlUnwind handler at 0x7bc3b2ec returned 1 0009:trace:seh:__regs_RtlUnwind calling handler at 0x60366cec code=6a6 flags=2 0009:Call rpcrt4.NdrFreeBuffer(0032f06c) ret=60366e7f 0009:Ret rpcrt4.NdrFreeBuffer() retval=00000000 ret=60366e7f 0009:trace:seh:__regs_RtlUnwind handler at 0x60366cec returned 1 0009:Ret advapi32.CloseServiceHandle() retval=00000000 ret=007aa722 --- snip --- Even if RPC code correctly detects invalid SCM handles, the latter sc_handle_free() will eventually corrupt heap which will later lead to breakage. This needs to be avoided at all costs. Second allocation returns garbage sub block due to corrupted heap lists, causing exception. --- snip --- ... 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,0000001c) ret=79e78360 0009:Ret ntdll.RtlAllocateHeap() retval=001b1fc0 ret=79e78360 0009:Call KERNEL32.GetLastError() ret=79e71862 0009:Ret KERNEL32.GetLastError() retval=000006a6 ret=79e71862 0009:Call ntdll.RtlTryEnterCriticalSection(0013cedc) ret=79e74811 0009:Ret ntdll.RtlTryEnterCriticalSection() retval=00000001 ret=79e74811 0009:Call KERNEL32.GetLastError() ret=79e783fb 0009:Ret KERNEL32.GetLastError() retval=000006a6 ret=79e783fb 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,0000003c) ret=79e78360 0009:Ret ntdll.RtlAllocateHeap() retval=03ec9988 ret=79e78360 0009:Call KERNEL32.GetLastError() ret=79e71862 0009:Ret KERNEL32.GetLastError() retval=000006a6 ret=79e71862 0009:Call KERNEL32.InitializeCriticalSection(03ec9998) ret=79e7a501 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc450bd ip=0x7bc450bd tid=0009 0009:trace:seh:raise_exception info[0]=00000000 0009:trace:seh:raise_exception info[1]=00001796 0009:trace:seh:raise_exception eax=00001796 ebx=7bc9bd90 ecx=7bc9bd90 edx=00110078 esi=00110070 edi=0032f0e4 0009:trace:seh:raise_exception ebp=0032efe8 esp=0032ef80 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 0009:trace:seh:call_stack_handlers calling handler at 0x7a322c04 code=c0000005 flags=0 --- snip --- --- snip dlls/advapi32/service.c --- BOOL WINAPI CloseServiceHandle( SC_HANDLE hSCObject ) { struct sc_handle *obj; DWORD err; TRACE("%p\n", hSCObject); if (hSCObject == NULL) { SetLastError(ERROR_INVALID_HANDLE); return FALSE; } obj = (struct sc_handle *)hSCObject; __TRY { err = svcctl_CloseServiceHandle(&obj->server_handle); } __EXCEPT(rpc_filter) { err = map_exception_code(GetExceptionCode()); } __ENDTRY sc_handle_free( obj ); // <---- will eventually corrupt heap! if (err != ERROR_SUCCESS) { SetLastError(err); return FALSE; } return TRUE; } --- snip dlls/advapi32/service.c --- Change the way how client side service handles are managed to avoid heap corruption and allow for multiple service handle close calls. 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 8