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

[Bug 11203] New: Versions 9.52 & 9. 53 throw page exception on Enterprise Architect
by wine-bugs＠winehq.org 20 Aug '21

20 Aug '21

http://bugs.winehq.org/show_bug.cgi?id=11203 Summary: Versions 9.52 & 9.53 throw page exception on Enterprise Architect Product: Wine Version: 0.9.52. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: igoddard(a)nildram.co.uk Created an attachment (id=10271) --> (http://bugs.winehq.org/attachment.cgi?id=10271) traces for errors under 9.52&3 and normal operation under 9.51 Enterprise Architect is a UML package from www.sparxsystems.com.au I'm running V6.5.806. It works fine under Wine in many versions including 9.51. In 9.52 & 9.53 it throws a page exception. See attached traces (including a trace for normal operation under 9.51) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 77

[Bug 10059] New: Windows Live Messenger 8. 5 - You can not type into login boxes
by wine-bugs＠winehq.org 10 Aug '21

10 Aug '21

http://bugs.winehq.org/show_bug.cgi?id=10059 Summary: Windows Live Messenger 8.5 - You can not type into login boxes Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: philip.kent(a)ntlworld.com When trying to run Windows Live Messenger 8.5 (install instructions in AppDB - http://appdb.winehq.org/objectManager.php?sClass=version&iId=8146) you will find you can not log in. This is because it is impossible to type into the textboxes requesting usernames and passwords. They are too small and do not accept input. A log file is attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 16

[Bug 10916] New: Latest eclipse crashes on startup in comctl32
by wine-bugs＠winehq.org 26 Jul '21

26 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=10916 Summary: Latest eclipse crashes on startup in comctl32 Product: Wine Version: CVS/GIT Platform: Other URL: http://eclipse.org OS/Version: other Status: NEW Keywords: download Severity: enhancement Priority: P2 Component: wine-comctl32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Created an attachment (id=9832) --> (http://bugs.winehq.org/attachment.cgi?id=9832) hs_err_pid8.log from java ... probably in imagelist. $ cd .wine/drive_c $ unzip ~/eclipse-java-europa-fall2-win32.zip $ cd eclipse $ wine eclipse.exe fails with # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7eb9149a, pid=8, tid=9 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing) # Problematic frame: # C [comctl32.dll+0x9149a] # # An error report file with more information is saved as hs_err_pid8.log fairly early (after grinding for only 20 seconds). I'll attach hs_err_pid8.log. I also tried running WINEDEBUG=+seh,+imagelist,+relay ~/wine-git/wine eclipse.exe but the log was really big and not obviously helpful. This was with the very latest sun jre installed, Java(TM) SE Runtime Environment (build 1.6.0_03-b05) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 16

[Bug 10547] New: .NET 3.5 Framework installation problems (msi, bits, crypt32)
by wine-bugs＠winehq.org 26 Jul '21

26 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=10547 Summary: .NET 3.5 Framework installation problems (msi, bits, crypt32) Product: Wine Version: CVS/GIT Platform: PC URL: http://download.microsoft.com/download/6/0/f/60fc5854- 3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-dotnet AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9300) --> (http://bugs.winehq.org/attachment.cgi?id=9300) patch which adds msi.MsiSetExternalUIRecord and msi.MsiDetermineApplicablePatchesW Hello, this (showcase) bug id exists to show/track .NET Framework 3.5 install issues, e.g. what wine needs to implement/work around. With VS.NET 2008 and .NET Framework 3.5 released, the Framework 3.5 needs to be installed first. Used GIT: wine --version wine-0.9.49-331-g7a8eb4c Prerequisites: 1) set OS config to at least "Windows XP" 2) one volume name (dosdevices/<driveletter>:) must contain "harddisk" or "ramdisk" and write accessible cd ~/.wine mv drive_c harddiskvolume1 cd dosdevices ln -sf ../harddiskvolume1 c: The installer then stops at unimplemented msi.MsiSetExternalUIRecord, attached patch adds simple stub which fixes this. ---- If you downloaded the "small" .NET Framework installer, you now run into a major showstopper: BITS required The partial installer depends on: http://bugs.winehq.org/show_bug.cgi?id=5713 What is the consensus regarding native BITS and builtin BITS? Builtin bits might take some time until it gets into usable state. Native BITS is described here: http://bugs.winehq.org/show_bug.cgi?id=6194 though I haven't looked at it for some time. Will native BITS considered abandoned then (needs some nasty workarounds)? ---- If you downloaded the full installer some messages seem to indicate BITS is used in full installer too, but it doesn't seem to harm now. --- snip --- 0012:err:ole:create_server class {4991d34b-80a1-4291-83b6-3328366b9097} not registered 0012:fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported 0012:err:ole:CoGetClassObject no class object {4991d34b-80a1-4291-83b6-3328366b9097} could be created for context 0x17 0012:Ret ole32.CoCreateInstance() retval=80004002 ret=3aea41ed .. 0012:Call advapi32.RegCreateKeyExW(80000001,00563758 L"SOFTWARE\\Microsoft\\VisualStudio\\9.0\\DownloadManager",00000000,00000000,00000000,0002001f,00000000,0034e284,00000000) ret=3aea8785 0012:Ret advapi32.RegCreateKeyExW() retval=00000000 ret=3aea8785 0012:Call advapi32.RegQueryValueExW(00000290,00563d30 L"BitsOverride",00000000,0034e1c8,0034e1f4,0034e1cc) ret=3aea899a 0012:Ret advapi32.RegQueryValueExW() retval=00000002 ret=3aea899a --- snip --- Interestingly there is some undocumented "BitsOverride" which might indicate a possibility to revert their interal download manager to standard download procedures. The showstopper for full installer seem to be various hotfix installers which are spawned by main installer. As example I start with hotfix "Windows Imaging Component update" which gets extracted by installer into "c:\<guid>\wcu\dotNetFramework\dotNetFX30\WIC_x86_enu.exe" and tries to run it. This fails and lets overall installer fail too. It seems to make various specific checks for operating system version/build. I only quote checks which seem to fail: --- snip --- 0040:Call KERNEL32.CreateFileA(01104940 "c:\\windows\\system32\\ntoskrnl.exe",80000000,00000001,00000000,00000003,00000000,00000000) ret=01070767 0040:Ret KERNEL32.CreateFileA() retval=ffffffff ret=01070767 0040:Call KERNEL32.CloseHandle(ffffffff) ret=010708a6 0040:Ret KERNEL32.CloseHandle() retval=00000000 ret=010708a6 --- snip --- "GetKernelType: GetInternalFilename failed" --- snip --- 0040:Call KERNEL32.LoadLibraryA(01023c38 "setupapi.dll") ret=0106f709 0040:Ret KERNEL32.LoadLibraryA() retval=615d0000 ret=0106f709 0040:Call KERNEL32.GetProcAddress(615d0000,01023c24 "pSetupIsUserAdmin") ret=0106f71b 0040:Ret KERNEL32.GetProcAddress() retval=00000000 ret=0106f71b 0040:Call KERNEL32.FreeLibrary(615d0000) ret=0106f72a 0040:Ret KERNEL32.FreeLibrary() retval=00000001 ret=0106f72a --- snip --- --- snip --- 0040:Call advapi32.RegOpenKeyExA(80000002,0101e608 "SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\WindowsFeatures",00000000,00020019,0033b774) ret=0109191a 0040:Ret advapi32.RegOpenKeyExA() retval=00000002 ret=0109191a 0040:Call KERNEL32.GetLastError() ret=010701ae 0040:Ret KERNEL32.GetLastError() retval=00000078 ret=010701ae --- snip --- "GetBuildType, line 1170, RegOpenKeyEx failed with error 0x2" --- snip --- 0030:Call KERNEL32.LoadLibraryExA(0033b9c4 "c:\\windows\\system32\\pidgen.dll",00000000,00000002) ret=0105d03f 0030:Ret KERNEL32.LoadLibraryExA() retval=00000000 ret=0105d03f 0030:Call KERNEL32.GetLastError() ret=010701ae 0030:Ret KERNEL32.GetLastError() retval=0000007e ret=010701ae --- snip --- This is from the log of installer itself to get the idea: --- snip --- 0.101: Hotfix started with following command line: 0.101: GetKernelType: GetInternalFilename failed 0.102: In Function GetBuildType, line 1170, RegOpenKeyEx failed with error 0x2 0.102: GetGroupIdFromPidGenDll:LoadLibrary failed for c:\windows\system32\pidgen.dll dll 0.102: CheckSystem_1203: Failed to get product build type. 0.102: DoInstallation: CheckSystem Failed: 0xf117 0.103: WIC installation did not complete. 1.469: Message displayed to the user: WIC installation did not complete. 1.469: User Input: OK 1.469: Update.exe extended error code = 0xf117 1.469: Update.exe return code was masked to 0x643 for MSI custom action compliance. --- snip --- I copied "pigen.dll" from my windows xp installation and it seems to help a bit, showing that previous checks might be optional? --- snip --- 0040:Call KERNEL32.LoadLibraryExA(0033b9c4 "c:\\windows\\system32\\pidgen.dll",00000000,00000002) ret=0105d03f 0040:Ret KERNEL32.LoadLibraryExA() retval=003b0001 ret=0105d03f 0040:Call KERNEL32.FindResourceA(003b0001,00000001,0101e2ac "BINK") ret=0105d059 0040:Ret KERNEL32.FindResourceA() retval=003b54a0 ret=0105d059 0040:Call KERNEL32.LoadResource(003b0001,003b54a0) ret=0105d070 0040:Ret KERNEL32.LoadResource() retval=003b54e0 ret=0105d070 0040:Call KERNEL32.LockResource(003b54e0) ret=0105d07d 0040:Ret KERNEL32.LockResource() retval=003b54e0 ret=0105d07d 0040:Call KERNEL32.FreeResource(003b54e0) ret=0105d0aa 0040:Ret KERNEL32.FreeResource() retval=00000000 ret=0105d0aa 0040:Call KERNEL32.FreeLibrary(003b0001) ret=0105d0b1 0040:Ret KERNEL32.FreeLibrary() retval=00000001 ret=0105d0b1 --- snip --- Seems "only" the "BINK" resource is read (2 sub chunks) >From researching a bit this resource seems to be related to the public key(s) for the product id stuff (elliptic curve cryptography). No API exports are used (GetProcAddress/...). And the installer log: --- snip --- 0.028: 2007/11/23 12:49:19.973 (local) 0.028: C:\036ac5753759f7b22a9a8e26\update\update.exe (version 6.3.4.0) 0.030: Hotfix started with following command line: 0.030: GetKernelType: GetInternalFilename failed 0.031: In Function GetBuildType, line 1170, RegOpenKeyEx failed with error 0x2 0.162: c:\windows\system32\WindowsCodecs.dll is Not Present 0.162: First Condition in Test.WindowsCodecsVer.Section Succeeded 0.162: Condition succeeded for section Test.WindowsCodecsVer.Section in Line 1 of PreRequisite 0.162: c:\windows\system32\WindowsCodecsExt.dll is Not Present 0.162: First Condition in Test.WindowsCodecsExtVer.Section Succeeded 0.162: Condition succeeded for section Test.WindowsCodecsExtVer.Section in Line 2 of PreRequisite 0.163: c:\windows\system32\WMPhoto.dll is Not Present 0.163: First Condition in Test.WMPhotoVer.Section Succeeded 0.163: Condition succeeded for section Test.WMPhotoVer.Section in Line 3 of PreRequisite 0.164: c:\windows\system32\PhotoMetadataHandler.dll is Not Present 0.164: First Condition in Test.PhotoMetadataHandlerVer.Section Succeeded 0.164: Condition succeeded for section Test.PhotoMetadataHandlerVer.Section in Line 4 of PreRequisite 0.198: InstallInfCatalogFile: Installing c:\4cbc8383318bb456e1d38cacd0\update\WIC.cat as _000000_.cat... 0.199: VerifyTargetFileSize: Unable to verify size as Source = NULL for file c:\windows\_000000_.cat 0.200: InstallCatalogFile: VerifyCatalogFile failed for c:\windows\_000000_.cat; error=0x00000001. 0.201: InstallInfCatalogFile: Installation failed; error=0x00000002. 0.201: UdpStopService: OpenService failed :0x424 0.201: IsInfFileTrusted: ValidateSingleFileSignature Failed: STR_FAILED_INF_INTEGRITY 0.201: WIC Setup encountered an error: Setup could not verify the integrity of the file Update.inf. Make sure the Cryptographic service is running on this computer. 0.202: DeleteCatalogFile _000000_.cat failed with ERROR 2 0.202: CleanupTrustedInfFile: GetFileAttributes for c:\windows\system32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\update_WinXP.cat failed: 0x3 0.205: Setup could not verify the integrity of the file Update.inf. Make sure the Cryptographic service is running on this computer. 10.573: Message displayed to the user: Setup could not verify the integrity of the file Update.inf. Make sure the Cryptographic service is running on this computer. 10.573: User Input: OK 10.573: Update.exe extended error code = 0xf0da 10.573: Update.exe return code was masked to 0x643 for MSI custom action compliance. --- snip --- The inf/old catalog file problem... Anyway one can get around by manually copying these 4 files (WindowsCodecs.dll, WindowsCodecsExt.dll, WMPhoto.dll, PhotoMetadataHandler.dll) before installtion into system32. Extract them from the hotfix installer to have version match. This seems to work around the hotfix issues/catalog problem. With the files in place before .NET installation this hotfix is skipped and the installer runs into: --- snip --- wine: Call from 0x7b841450 to unimplemented function msi.dll.MsiDetermineApplicablePatchesW, aborting --- snip --- Attached patch fixes this. After that it gets further only to stop at another hotfix installer "XPSEPSC" - the catalog install problem. So I stop for now because it sucks to work around each single hotfix installer. Should be good enough to give an idea ... Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 28

[Bug 9723] New: Fileplanet Comrade installer fails to download a file
by wine-bugs＠winehq.org 26 Jul '21

26 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=9723 Summary: Fileplanet Comrade installer fails to download a file Product: Wine Version: 0.9.45. Platform: PC URL: http://www.fileplanet.com/164906/160000/fileinfo/GameSpy -Comrade-Instant-Messenger OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: wine-net AssignedTo: wine-bugs(a)winehq.org ReportedBy: l_bratch(a)yahoo.co.uk The installer tries to download this file but fails: http://download.microsoft.com/download/a/a/c/aac39226-8825-44ce-90e3-bf8203… Based on the terminal output I thought it was a dupe of bug 2781: http://bugs.winehq.org/show_bug.cgi?id=2781 However in that bug the wininet trace shows the download as going okay, but in this case it gives 404, even though attempting to download that file manually shows that it does exist. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 15

[Bug 10515] New: Muvee autoproducer fails to install
by wine-bugs＠winehq.org 26 Jul '21

26 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=10515 Summary: Muvee autoproducer fails to install Product: Wine Version: CVS/GIT Platform: PC URL: http://www.muvee.com/en/products/ap/ap6_free_trial OS/Version: Linux Status: UNCONFIRMED Keywords: download, Installer Severity: enhancement Priority: P2 Component: wine-msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: xerox_xerox2000(a)yahoo.co.uk Hi, another "garbage app" sent into the appdb: the installer fails with a messagebox : Error Number: 0x80020006 Quote from the person who sent it in: Installshield warns about missing Quicktime and Media player components (it does that on Windows too unless they're installed but will install and run without them),then runs through the initial license confirmation and destination directory selection. It then aborts with MessageBox: Error Number: 0x80020006 There was one msi-related fixme message in the console, that appeared when the messagebox appeared: fixme:msi:AutomationObject_GetIDsOfNames Unknown member L"version", clsid {000c1090-0000-0000-c000-000000000046} -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 6

[Bug 9628] New: msiexec command line parsing incorrect
by wine-bugs＠winehq.org 26 Jul '21

26 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=9628 Summary: msiexec command line parsing incorrect Product: Wine Version: CVS/GIT Platform: PC URL: http://www.enterbrain.co.jp/tkool/RPG_XP/eng/download.ht ml OS/Version: Linux Status: NEW Keywords: download, regression Severity: minor Priority: P2 Component: wine-msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: thestig(a)google.com In bug 9615, the reporter mentioned running the setup program to install the game does not work. When running SetupMenu.exe, press the "Install RPG Maker XP" button should launch the installer. In Wine 0.9.33, pressing that button runs: msiexec /i c:\path\to\RPG Maker XP\Setup2\RPGXP_102a.msi In Wine 0.9.34, pressing that button runs: msiexec c:\path\to\RPG Maker XP\Setup2\RPGXP_102a.msi The regression is caused by: commit 54c7b7e81b5542f015dc6e71fc6030ba3919f5d3 Author: Aric Stewart <aric(a)codeweavers.com> Date: Thu Mar 22 08:20:16 2007 -0500 Revert 7c35db07c35db0... msiexec: Use CommandLineToArgvW instead of process_args to reduce code duplication. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 31

[Bug 10686] New: Marangatu fails with "Object doesn't support this action"
by wine-bugs＠winehq.org 25 Jul '21

25 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=10686 Summary: Marangatu fails with "Object doesn't support this action" Product: Wine Version: 0.9.50. Platform: PC-x86-64 URL: http://www.set.gov.py/set_htm/softwares/descargas/marang atui/instalador.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: ben(a)atomnet.co.uk Created an attachment (id=9523) --> (http://bugs.winehq.org/attachment.cgi?id=9523) Full terminal log The eset.exe fails to start, bringing up a message box saying that Runtime Error 445, Object doesn't support this action and then Wine pagefaults. Full terminal output and error message attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 28

[Bug 10376] New: recent winsock SO_REUSEADDR patch reveals parameter handling problem in WS_setsockopt
by wine-bugs＠winehq.org 24 Jul '21

24 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=10376 Summary: recent winsock SO_REUSEADDR patch reveals parameter handling problem in WS_setsockopt Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-net AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, seems recent winsock SO_REUSEADDR patch --- snip --- URL: http://source.winehq.org/git/wine.git/?a=commit;h=58b030c270e68c4e130a7decb… Author: Kai Blin <kai.blin <at> gmail.com> Date: Sat Nov 3 08:45:12 2007 +0100 ws2_32: Map SO_REUSEADDR. BSD socket SO_REUSEADDR is not a complete match, but features like "allow binding to a port immediately after closing it" seem to be compatible. --- snip --- triggers a code path in WS_setsockopt() which leads to crash. The cause is an application bug. EvenBalance PunkBuster "PnkBstrA" service which creates local communication sockets accidentally passes the value instead of value address to WS_setsockopt(). The services can be installed and tested with their "pbsvc.exe" tool from http://www.evenbalance.com/downloads/pbsvc/pbsvc.exe --- snip --- .. 0015:trace:winsock:WS_setsockopt socket: 005c, level 0xffff, name 0x4, ptr 0x1, len 1 0015:trace:seh:raise_exception code=c0000005 flags=0 addr=0x76587df5 0015:trace:seh:raise_exception info[0]=00000000 0015:trace:seh:raise_exception info[1]=00000001 0015:trace:seh:raise_exception eax=00000001 ebx=7658e11c ecx=00000002 edx=00000004 esi=0000ffff edi=00000001 0015:trace:seh:raise_exception ebp=617c57a4 esp=617c574c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00210293 0015:trace:seh:call_stack_handlers calling handler at 0x7bc38810 code=c0000005 flags=0 --- snip --- Their source code snippet probably looks like this: --- snip --- if (setsockopt( sock, .., ..., (char*)value, value_len) != SOCKET_ERROR) --- snip --- Instead of this: --- snip --- if (setsockopt( sock, .., ..., (char*)&value, value_len) != SOCKET_ERROR) --- snip --- Micro$oft "fixes" such crappy^H^H^H^H^H^Hbuggy applications by using SEH to catch invalid pointer dereferencing. If you execute a hand-crafted WS_setsockopt() test case with invalid pointer value in Windows you will see something like this: --- snip --- First-chance exception at 0x719b5280 (mswsock.dll) in test.exe: 0xC0000005: Access violation reading location 0x00000001. --- snip --- Returned last error is WSAEFAULT (bad pointer value/address supplied). Solution: either wrap the whole function within structured exception handler (SEH) or use IsBadReadPtr() on passed pointer and return WSAEFAULT if fishy. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 9

[Bug 11420] New: service control manager API problem: name of named objects might differ (client vs. service process)
by wine-bugs＠winehq.org 24 Jul '21

24 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=11420 Summary: service control manager API problem: name of named objects might differ (client vs. service process) Product: Wine Version: 0.9.54. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=10552) --> (http://bugs.winehq.org/attachment.cgi?id=10552) patch which fixes client vs. service SCM API when using named objects Hello, there seems to be a misconception in usage of names for named objects in service control manager API. Some people might have experienced such situation: wine hangs for several seconds on startup (when starting services). I usually disabled autostart type services (except for builtin ones) and the problems went away. Lately while fixing Microsoft Visual Studio .NET installers (2002/2003/2005) this problem became more and more annoying because the installers and VS.NET depend on some services, namely "debug manager" (service has to be running). Consider the following snippet with "service_get_event_handle" trace message added by me to highlight the problem: 0x9: client (net.exe) 0x11: service process (mdm.exe) 0x12: dispatcher thread --- snip trace --- .. 0009:trace:advapi:OpenSCManagerW ((null),(null),0x000f003f) 0009:trace:advapi:sc_handle_alloc sc_handle type=0 -> 0x121450 0009:trace:advapi:OpenSCManagerW returning 0x121450 (access : 0x000f003f) 0009:trace:advapi:OpenServiceA 0x121450 "mdm" 983103 0009:trace:advapi:OpenServiceW 0x121450 L"mdm" 983103 0009:trace:advapi:sc_handle_alloc sc_handle type=1 -> 0x121488 0009:trace:advapi:OpenServiceW returning 0x121488 0009:trace:advapi:GetServiceDisplayNameA 0x121450 "mdm" 0x34ee48 0x34fe48 0009:trace:advapi:GetServiceDisplayNameW 0x121450 L"mdm" 0x1214b8 0x34ee08 The Machine Debug Manager service is starting. 0009:trace:advapi:StartServiceA (0x121488,0,(nil)) 0009:trace:advapi:StartServiceW 0x121488 0 (nil) 0009:trace:advapi:LockServiceDatabase 0x121450 0009:trace:advapi:LockServiceDatabase returning 0x3c 0009:trace:advapi:service_start_process service_get_event_handle(L"mdm"): 0x40 0011:trace:advapi:LookupPrivilegeValueW L"",L"SeDebugPrivilege",0x34fc80 0011:trace:advapi:LookupPrivilegeValueW L"" -> 00000000-00000014 0011:trace:advapi:AdjustTokenPrivileges 0011:trace:advapi:StartServiceCtrlDispatcherA 0x34fc9c 0011:trace:advapi:service_run_threads Starting 1 pipe listener threads. Services running as process 16 0012:trace:advapi:service_control_dispatcher 0x121ea8 L"Machine Debug Manager" 0012:trace:advapi:service_control_dispatcher service_get_event_handle(L"Machine Debug Manager"): 0x48 0009:trace:advapi:UnlockServiceDatabase 0x3c 0009:trace:advapi:StartServiceW returning 0 The Machine Debug Manager service failed to start. 0009:trace:advapi:CloseServiceHandle 0x121488 0009:trace:advapi:sc_handle_destroy_service destroying service 0x121488 0009:trace:advapi:CloseServiceHandle 0x121450 0009:trace:advapi:sc_handle_destroy_manager destroying SC Manager 0x121450 000d:trace:advapi:service_run_threads last user process exited, shutting down 0011:trace:advapi:service_run_threads last user process exited, shutting down --- snip trace --- When a service is started, named objects are created to internally communicate data/events from the service process (dispatcher) to client side SCM API and vice versa. Unfortunately there exist service proccesses which pass service names to dispatcher table (StartServiceCtrlDispatcher) not matching the service name on the client side (registry "Services" key). --- snip dlls/advapi32/service.c --- static DWORD WINAPI service_control_dispatcher(LPVOID arg) { service_data *service = arg; LPWSTR name; HANDLE pipe, event; TRACE("%p %s\n", service, debugstr_w(service->name)); /* create a pipe to talk to the rest of the world with */ name = service_get_pipe_name(service->name); <--------- *problem*! pipe = CreateNamedPipeW(name, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, 1, 256, 256, 10000, NULL ); if (pipe==INVALID_HANDLE_VALUE) ERR("failed to create pipe for %s, error = %d\n", debugstr_w(service->name), GetLastError()); HeapFree(GetProcessHeap(), 0, name); /* let the process who started us know we've tried to create a pipe */ event = service_get_event_handle(service->name); <--------- *problem*! SetEvent(event); CloseHandle(event); .. --- snip dlls/advapi32/service.c --- As result, different named objects are created and signaled so the client side can't communicate with the service side using named pipe and events. This leads to infamous timeout problem (30 sec) and service startup failing. In case of Microsoft Debug Manager the service is called "mdm" (registry). The service process itself passes "Microsoft Debug Manager" as name to dispatch table (see first trace). Problem: how can both sides communicate a "common" name for named objects? The service dispatcher part on the service side has only dispatch table data available which doesn't help much. I thought about this problem and found a feasible solution ... well call it "hack" whatever. If the client side API passes the service name in one of the process startup parameter members before process creation, the service process' dispatcher routine is able to access this data and create the named objects used for communication. I (ab)used startupinfo "title" member because only wine itself make exclusive use of most service process startup parameters. If not considered safe, use reserved/undoc fields... With that patch applied the services in question start fine and can be controlled using "net" commands. No more hangs ;-) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 22