August 2008 - Wine-Bugs - list.winehq.org

[Bug 12017] New: py2exe fails because fixme:resource:get_resource_section . rsrc isn't the last section
by wine-bugs＠winehq.org Feb. 15, 2021

Feb. 15, 2021

http://bugs.winehq.org/show_bug.cgi?id=12017 Summary: py2exe fails because fixme:resource:get_resource_section .rsrc isn't the last section Product: Wine Version: 0.9.56. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ahziem1(a)mailbolt.com If you workaround bug 3591 with an imagehlp.dll override, then you run into fixme:resource:get_resource_section .rsrc isn't the last section even though bug 3897 implemented BeginUpdateResource & EndUpdateResource. py2exe is handy for building Python Windows executables from Linux. -- 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 10785] New: Wine 0.9.51 crash when launching Slingplayer v1.5
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=10785 Summary: Wine 0.9.51 crash when launching Slingplayer v1.5 Product: WineHQ Bugzilla Version: unspecified Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P1 Component: bug list AssignedTo: jnewman(a)codeweavers.com ReportedBy: giovanni(a)piccirilli.eu CC: giovanni(a)piccirilli.eu Created an attachment (id=9639) --> (http://bugs.winehq.org/attachment.cgi?id=9639) Bug report Hello, I have tried to run the slingplayer to connect to my slingbox using the methodology described in http://cyberpunkcafe.com/page.php?74. This produces a crash of Wine as per attachment. Note that I am using Ubuntu Gusty 7.10, Wine 0.9.51, Slingplayer as per URL: http://download.slingmedia.com/player/pc/SlingPlayer_PC_Setup%201.5-UK.exe Any assistance to get this working is greatly appreciated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 20

[Bug 13516] New: Dynamic HTML Editor 4.2 Demo installs, crashes on startup
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=13516 Summary: Dynamic HTML Editor 4.2 Demo installs, crashes on startup Product: Wine Version: 1.0-rc2 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dimesio(a)earthlink.net Created an attachment (id=13437) --> (http://bugs.winehq.org/attachment.cgi?id=13437) Console log from Dynamic HTML Editor crash Another user originally posted a question about this in the forum (http://forum.winehq.org/viewtopic.php?t=1078) though without any console output. I downloaded the demo from the website (http://www.dynamic-html-editor.com/en/download.asp) which actually has a warning on the download page telling Mac and Linux users that they need to use Virtual PC, VMware, or "another Windows emulator" to run the program. The demo installs fine. When I tried to run the program, I got an initial screen telling me this was just a demo, and when I clicked okay, the program crashed. I'm attaching the console log. -- 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 21

[Bug 11610] New: Microsoft Virtual Earth 3D beta fails to install
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=11610 Summary: Microsoft Virtual Earth 3D beta fails to install Product: Wine Version: 0.9.55. Platform: PC URL: http://www.microsoft.com/Downloads/details.aspx?FamilyID =e9298080-50c4-4f2e-9fc4-4009074996ba&displaylang=en OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: gdiplus AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=10817) --> (http://bugs.winehq.org/attachment.cgi?id=10817) Backtrace in current git Microsoft Virtual Earth 3D beta fails to install, because of missing gdiplus functions: gdiplus.dll.GdipDrawImageRectI gdiplus.dll.GdipDrawImageRectRectI gdiplus.dll.GdipDrawLinesI winetricks gdiplus works around this, then the installer hangs...Backtrace attached. -- 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 11517] New: Microsoft Virtual Earth 3D beta fails to install
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=11517 Summary: Microsoft Virtual Earth 3D beta fails to install Product: Wine Version: 0.9.54. Platform: PC URL: http://www.microsoft.com/Downloads/details.aspx?FamilyID =e9298080-50c4-4f2e-9fc4-4009074996ba&displaylang=en OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ead1234(a)hotmail.com Microsoft Virtual Earth 3D beta fails to install, there is an OLE error and an X11 bitmap error in the console -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

2 20

[Bug 15070] New: HxD cant find Internetupdate
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=15070 Summary: HxD cant find Internetupdate Product: Wine Version: 1.1.3 Platform: PC-x86-64 URL: http://mh-nexus.de/de/hxd OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wininet AssignedTo: wine-bugs(a)winehq.org ReportedBy: nerv(a)dawncrow.de Created an attachment (id=15741) --> (http://bugs.winehq.org/attachment.cgi?id=15741) wininet trace The Function HttpQueryInfoW returns False in Wine with lpdwIndex=1 in XP it returns True with lpdwIndex=0. Sample Delphi Code: HttpQueryInfo(hRequest, HTTP_QUERY_STATUS_CODE, @Result[1], len, dummy) [len and dummy are 0] The attachment contains a Trace with WINEDEBUG=wininet and improved TRACE-Functions by me: TRACE("(%p, 0x%08x)--> %d with lpdwIndex=%d (Adress) and value=%d\n", hHttpRequest, dwInfoLevel, dwInfoLevel, lpdwIndex, *lpdwIndex); -- 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 24

[Bug 14040] New: Microsoft Virtual Earth 3D beta inner installer aborts when reading registry
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=14040 Summary: Microsoft Virtual Earth 3D beta inner installer aborts when reading registry Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Keywords: download, Installer, patch Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com [Copied from To get past bugs 11517 and 14035, do 'winetricks gdiplus dotnet20' (though that might not download the right service pack level of .net?) Then download VirtualEarth3D.msi from http://go.microsoft.com/fwlink/?LinkId=106129 and install that instead of the outer installer. +relay,+msi shows that VirtualEarth3D.msi aborts shortly after checking for a com object Anastasius Focht wrote: the cause of the failure is due to unsupported access flags. 0037:Call advapi32.RegCreateKeyExW(80000000,100138e0 L"CLSID\\{0DB074F0-617E-4EE9-912C-2965CF2AA5A4}\\InprocServer32",00000000,00000000,00000000,000f023f,00000000,7de9685c,7de96860) ret=1000230d 0037:Ret advapi32.RegCreateKeyExW() retval=00000005 ret=1000230d 0xf023f = KEY_ALL_ACCESS (0xF003F) | KEY_WOW64_32KEY (0x0200) ... dlls/advapi32/registry.c's KEY_ACCESS_MASK check doesn't include WOW64 flags yet. Sure enough, fixing that let the installer finish. There's no .exe, but the app does create a menu entry which does wine "C:\Program Files\Internet Explorer\iexplore.exe" http://go.microsoft.com/fwlink/?LinkId=75722 (This starts the app ok. It immediately complains that the web browser isn't supported. If you continue, it complains System.Configuration.SettingsPropertyNotFoundException: The settings property 'DetailSetting' was not found. at System.Configuration.SettingsBase.GetPropertyValueByName(String propertyName) at System.Configuration.SettingsBase.get_Item(String propertyName) and lets you continue in 2D mode. But that's for a different bug report.) -- 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 14035] New: Microsoft Virtual Earth 3D beta installer fails to download .net framework
by wine-bugs＠winehq.org Feb. 14, 2021

Feb. 14, 2021

http://bugs.winehq.org/show_bug.cgi?id=14035 Summary: Microsoft Virtual Earth 3D beta installer fails to download .net framework Product: Wine Version: CVS/GIT Platform: Other URL: http://www.microsoft.com/Downloads/details.aspx?FamilyID =e9298080-50c4-4f2e-9fc4-4009074996ba&displaylang=en OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: wininet AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com To get past bug 11517, do 'winetricks gdiplus'. The next problem is it fails downloading .net 2.0 sp1. The installer offers to show you a log, but can't find the log itself when you ask; it's really at ~/.wine/dosdevices/c:/windows/temp/VirtualEarth3DInstallLog.txt and it says [2008/06/21 12:35:44.709] DownloadManager: HTTP Status String: 'OK' for 'http://go.microsoft.com/fwlink/?LinkId=87970' [2008/06/21 12:35:44.710] DownloadManager: HttpQueryInfo(HTTP_QUERY_CONTENT_LENGTH) failed for 'http://go.microsoft.com/fwlink/?LinkId=87970' (System Error Code: 12150 (unknown), WinInet Error Code: 12150 ()) +wininet shows trace:wininet:HTTP_GetResponseHeaders raw headers: L"HTTP/1.1 200 OK\r\nContent-Length: 24758792\r\nContent-Type: application/octet-stream\r\nLast-Modified: Thu, 08 Nov 2007 00:36:49 GMT\r\nAccept-Ranges: bytes\r\nETag: \"dfcf19739f21c81:8037\"\r\nServer: Microsoft-IIS/6.0\r\nX-Powered-By: ASP.NET\r\nDate: Sat, 21 Jun 2008 12:45:10 GMT\r\nConnection: k"... ... trace:wininet:HttpQueryInfoW Attribute: HTTP_QUERY_CONTENT_LENGTH Modifier: HTTP_QUERY_FLAG_NUMBER trace:wininet:HTTP_GetCustomHeaderIndex L"Content-Length" trace:wininet:HTTP_GetCustomHeaderIndex Return: -1 trace:wininet:HttpQueryInfoW 0 <-- 001a:Ret wininet.HttpQueryInfoW() retval=00000000 ret=00404710 So we can't retrieve content-length for some reason, even though we've received it? -- 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

[Bug 14697] New: wineserver: debug events can block completion of queued user APCs
by wine-bugs＠winehq.org Feb. 11, 2021

Feb. 11, 2021

http://bugs.winehq.org/show_bug.cgi?id=14697 Summary: wineserver: debug events can block completion of queued user APCs Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, consider the following scenario... A debugger is attached to a debuggee. The debuggee has two threads. The debugger processes debug events and queries virtual memory info of remote process using VirtualQueryEx in its main loop. VirtualQueryEx -> NtQueryVirtualMemory -> enqueues APC_VIRTUAL_QUERY user APC for remote process (debuggee). The calling thread is blocked until the APC is completed. Following is the "good" case: tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) --- snip --- .. 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=0x7fff0000} ) 001a: *wakeup* signaled=192 cookie=0x7ffdb7b4 0009: queue_apc() = 0 { handle=0x68, self=0 } 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=1c8f097946d2824 (-0.1787600), result={}, handles={} ) 001a: select() = USER_APC { apc_handle=0x68, timeout=1c8f097946d2824 (-0.1787600), call={APC_VIRTUAL_QUERY,addr=0x7fff0000} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=0x68, timeout=1c8f097946d2824 (-0.1792110), result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0}, handles={} ) 0009: *wakeup* signaled=0 cookie=0x32d30c 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f097946d2824 (-0.1792110), call={APC_NONE} } 0009: get_apc_result( handle=0x68 ) 0009: get_apc_result() = 0 { result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0} } --- snip --- Now the interesting one, which ultimately leads to block of calling thread ... tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) tid=001b (debuggee thread 2) --- snip --- 0009: continue_debug_event( pid=0019, tid=001a, status=65538 ) 001a: *wakeup* signaled=258 cookie=0x7ffdb7b4 001b: *wakeup* signaled=258 cookie=0x7ffd77b4 0009: continue_debug_event() = 0 .. 0009: read_process_memory( handle=0x54, addr=0x7ffd8000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data= {} } 0009: read_process_memory( handle=0x54, addr=0x7ffd4000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data={} } 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=(nil)} ) 001b: *wakeup* signaled=192 cookie=0x7ed44874 0009: queue_apc() = 0 { handle=0x68, self=0 } 001a: load_dll( handle=(nil), base=0x61090000, size=102400, dbg_offset=0, dbg_size=0, name=0x13e468, filename=L"C:\\windows\\system32\\msacm32.dll" ) 001a: *sent signal* signal=10 001b: *sent signal* signal=10 001a: load_dll() = 0 .. 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001a: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ed44874, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x4c} ) 001b: select() = USER_APC { apc_handle=0x68, timeout=infinite, call={APC_VIRTUAL_QUERY,addr=(nil)} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c8b694 (+0.0000000), call={APC_NONE} } 001b: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001b: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ffd77b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001b: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c90dc4 (+0.0000000), call={APC_NONE} } ... --- snip --- At this point, tid=0009 (debugger) is blocked forever. When the APC_VIRTUAL_QUERY user APC is queued, remote thread 001b is selected/destined to carry out the APC. After thread 001a and 001b woke up, a dynamic library is loaded from thread 001a which results in LOAD_DLL_DEBUG_EVENT dispatched. This initiates the suspension of all threads in the child process (SIGUSR1 is sent for 001a and 001b). Thread 001a is suspended first, 001b next. The suspension of 001b happens to a time when 001b is about to carry out the APC_VIRTUAL_QUERY. Meanwhile thread 0009 (calling process) is waiting for APC completion result forever because it's blocked by VirtualQueryEx in debugger loop, unable to receive and process any debug event. 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 21

[Bug 10249] New: Battlefield2/SafeDisc 4. x and Punkbuster services cause lockup: child processes debugging misconception
by wine-bugs＠winehq.org Feb. 11, 2021

Feb. 11, 2021

http://bugs.winehq.org/show_bug.cgi?id=10249 Summary: Battlefield2/SafeDisc 4.x and Punkbuster services cause lockup: child processes debugging misconception Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8876) --> (http://bugs.winehq.org/attachment.cgi?id=8876) WINEDEBUG=-all,+server,+tid,+loaddll,+seh wine ./BF2.exe +fullscreen 0 +szx 800 +szy 600 &>/tmp/debug_pipe Hello, while testing some PunkBuster stuff on popular games, I came across Battlefield 2 which employs SafeDisc 4.x It seems there is a problem with debuggers in chained child processes. Consider following scenario: --- snip process list --- pid threads parent executable (all id:s are in hex) 0000001b 1 00000008 'PnkBstrA.exe' 0000000c 2 00000008 'explorer.exe' 0000000a 2 00000008 '~e5.0001' 00000008 4 00000000 'BF2.exe' --- snip process list --- --- snip thread list --- process tid prio (all id:s are in hex) 0000001b 0000001c 0 0000000c 00000010 0 0000000d 0 0000000a 00000012 0 0000000b 0 00000008 0000001a 1 00000014 15 00000013 0 00000009 0 --- snip thread list --- "BF2.exe" = parent (game) "~e5.0001" = 1st child = SafeDisc 4.x process = "debugger" "PnkBstrA.exe" = 2nd child = PunkBuster Update Service The 1st child acts as debugger for the parent "BF2.exe" and receives all debug events (process, thread creation, dll load/unload...) There are lots of breakpoint events triggered from parent. This is part of SafeDisc 4.x and used for on-the-fly decryption of code sections (child decrypts code of father). When PunkBuster is initialized (loading of pbcl = client, pbag = agent), the following services should get started: PnkBstrA.exe, PnkBstrB.exe and finally the kmode driver PnkBstrK.exe The service process "PnkBstrA.exe" is started from main process "BF2.exe" (which is a debuggee itself). No debug flags (DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS) are specified in process creation flags. The debugger (child of parent, receives the process creation event) does not make debugger_attach() to the newly created child process. The child process seems to inherit the state of being a "debuggee": wine server -> new_process -> set_process_debugger( process, parent->debugger ); The parent got its process->debugger from debugger_attach(). This leads to a problem in child process startup code: "dlls/kernel32/process.c:start_process()" checks the PEB->BeingDebugged field and if set, a system breakpoint is encountered before the entry code is called. This breakpoint results in debug event - seen by debugger. Unfortunately this event is _not_ expected by debugger because it didn't expect another debuggee (child) to be created. Ok, long story short solution: If you debug a process by attaching to an already created process, you _must_ treat default debugging flags as if the process has been created with DEBUG_ONLY_THIS_PROCESS, meaning that all childs created by debuggee will NOT automagically become debuggees. Short and (hopefully) acceptable patch snippet: --- snip --- diff --git a/server/debugger.c b/server/debugger.c index a64a17a..c59f3a0 100644 --- a/server/debugger.c +++ b/server/debugger.c @@ -444,6 +444,7 @@ static int debugger_attach( struct process *process, struct thread *debugger ) resume_process( process ); return 0; } + process->create_flags |= DEBUG_ONLY_THIS_PROCESS; return 1; error: --- snip --- And yes, the patch (snippet) works as intended (tm) ;-) Attached for sake of completeness is relevant server trace. Search for "001c:trace:seh:raise_exception code=80000003 flags=0 addr=0x7b870ed8 " to the point where the entry system breakpoint is triggered. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 17