October 2022 - Wine-Bugs - list.winehq.org

[Bug 53818] foobar2000 crashes shortly after startup

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53818 --- Comment #1 from matthias.grobarek(a)posteo.de --- Created attachment 73345 --> https://bugs.winehq.org/attachment.cgi?id=73345 foobar2000 crash log -- 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.

Oct. 21, 2022

[Bug 53818] New: foobar2000 crashes shortly after startup

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53818 Bug ID: 53818 Summary: foobar2000 crashes shortly after startup Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: matthias.grobarek(a)posteo.de Distribution: --- Created attachment 73344 --> https://bugs.winehq.org/attachment.cgi?id=73344 winedbg output After starting foobar2000, it quickly crashes after a few seconds, no matter what you do. Wine 7.18 and 7.17 are not affected. I’m using wine-staging (no matter the version) on Gentoo Linux (kernel 6.0.2), compiled for both 32bit and 64bit, with the following flags activated: x, alsa, fontconfig, mshtml, gstreamer, mingw, mscoree, gettext, openal, opengl, sdl, gnutls, freetype, udev, dbus, unwind, usb, vulkan, xcomposite. I attached the output of winedbg and also the crash log and dump that foobar2000 itself produces. If you need any more information, please tell me what exactly I should do. -- 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.

Oct. 21, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #10 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- Argh, sorry for the typos. 1. So we can see that syscall_frame is not at the bottom of the stack in KeUserModeCallback. 2. KiUserCallbackDispatcher is called back on the user stack, but the func it's invoking is a syscall, so we go back through _wine_syscall_dispatcher. 3. By the time the syscall machinery gets to win32u!NtUserCallOneParam, we are back on the original (syscall) stack, with exactly the same sp==syscall_frame. NtUserCallOneParam's prologue pushes its callee-save stuff, (same amount as KeUserModeCallback), and we enter the C function body with the same sp as KeUserModeCallback body, having trashed its values with our own. *with* these traces executing, basically the same thing happens, but earlier - ntdll!__wine_dbg_write is *also* a -syscall, so now the first corruption now happens during the TRACE() call added to KiUserCallbackDispatcher, as the prologue of __wine_dbg_write now does the smashing. But it uses fewer registers and so it only smashes 0x21f530...0x21f53f, rather than the whole thing. Its call to __GI___libc_write smashes the rest. -- 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.

Oct. 21, 2022

[Bug 53682] wineboot shows "user_check_not_lock BUG: holding USER lock" on aarch64 since wine-7.14

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53682 --- Comment #9 from Kevin Puetz <PuetzKevinA(a)JohnDeere.com> --- Created attachment 73343 --> https://bugs.winehq.org/attachment.cgi?id=73343 patch adding TRACE(...) of the stack pointer Here's a patch adding some additional TRACE() calls as you requested, but beware this changes the scenario (same bug, but manifests at a different stack): WINEDEBUG=trace+seh wineboot now shows 0040:trace:seh:KeUserModeCallback sp=0x21f500, syscall_frame=0x21f540 0040:trace:seh:KiUserCallbackDispatcher sp=000000000011F660 0040:trace:seh:NtUserCallOneParam sp=0x21f500 1. So we can see that syscall_frame is not at the bottom of the stack in KeUserModeCallback 2. KiUserCallbackDispatcher is called back on the user stack, but the func it's invoking is a syscall, so we go back through _wine_syscall_dispatcher and a 3. By the time the syscall machinery gets to win32u!NtUserCallOneParam, we are back on the original (syscall) stack, with exactly the same sp==syscall_frame. NtUserCallOneParam's prologue pushes its callee-save stuff, (same amount as KeUserModeCallback), and we enter the C body with the same sp as KeUserModeCallback's body, having trashed the values it saved with those of . *with* these traces executing, basically the same thing happens, but earlier - ntdll!__wine_dbg_write is *also* a -syscall, so now the first corruption now happens during the TRACE() call added to KiUserCallbackDispatcher, as the prologue of __wine_dbg_write now does the smashing. But it uses fewer registers and so it only smashes 0x21f530...0x21f53f, rather than the whole thing. its call to __GI___libc_write smashes the rest. -- 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.

Oct. 21, 2022

[Bug 53777] Batman: Arkham City Dotnet6 Community Launcher Fails to Run

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53777 --- Comment #13 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to Neko-san from comment #12) > Created attachment 73314 [details] > Wine Staging 7-19 Logs > > It doesn't stack-overflow with Staging but it doesn't offer a backtrace when > I try to run the executable now either. > I attached the new logs from this So I guess you did also do the: ' wine reg.exe COPY "HKLM\SYSTEM\CurrentControlSet" "HKLM\SYSTEM\ControlSet001" /s /f ' If so , I don`t know why the program starts here fine, and crashes at your side :( -- 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.

Oct. 18, 2022

[Bug 53777] Batman: Arkham City Dotnet6 Community Launcher Fails to Run

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53777 --- Comment #12 from Neko-san <nekoNexus(a)protonmail.ch> --- Created attachment 73314 --> https://bugs.winehq.org/attachment.cgi?id=73314 Wine Staging 7-19 Logs It doesn't stack-overflow with Staging but it doesn't offer a backtrace when I try to run the executable now either. I attached the new logs from this -- 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.

Oct. 18, 2022

[Bug 53800] CRYPT_GetBuiltinDecoder Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53800 --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- SPC_INDIRECT_DATA_OBJID is actually handled in wintrust. The fixme in this case is badly placed. -- 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.

Oct. 18, 2022

[Bug 49394] CED1401 USB function driver needs ntoskrnl.exe.KeInsertQueueDpc()

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=49394 --- Comment #7 from Alois Schlögl <alois.schloegl(a)gmail.com> --- Created attachment 73313 --> https://bugs.winehq.org/attachment.cgi?id=73313 log file when running the ced1401 installer The log file when running the installer of ced1401 suggests that some driver components (like c:\1401\windrv\ced_1401.inf) are not or not correctly installed. -- 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.

Oct. 18, 2022

[Bug 53711] Final Fantasy XI crashes randomly at multiple points

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53711 --- Comment #26 from pandora.xero(a)gmail.com --- after 48 hours, I have had no luck replicating the issue I was having. I'm going to go about this a slightly different way. I'm going to replicate EVERY factor I can think of from the install which was having issues. I'll report back by Thursday. -- 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.

Oct. 18, 2022

[Bug 53777] Batman: Arkham City Dotnet6 Community Launcher Fails to Run

by WineHQ Bugzilla

https://bugs.winehq.org/show_bug.cgi?id=53777 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #11 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to Neko-san from comment #10) > Doing that didn't fix it either > Also, I attempted to install dotnet48 like you did for the sake of > reproducibility (even though that shouldn't be necessary at all) I don't think that's true, as the program is looking for wmi_netutils.dll that only is present after I install dotnet48: ./.wine/drive_c/windows/Microsoft.NET/Framework64/v4.0.30319/WMINet_Utils.dll ./.wine/drive_c/windows/Microsoft.NET/Framework/v4.0.30319/WMINet_Utils.dll In my opinion this is still a Mono-bug really >and what I > got as a result was a stack overflow error when I attempted to run the > program again: > > 0124:err:virtual:virtual_setup_exception stack overflow 2640 bytes in thread > 0124 addr 0x170056b33 stack 0x205b0 (0x20000-0x21000-0x1a0000) Maybe you run into https://bugs.winehq.org/show_bug.cgi?id=52396, though I didn`t see it running regular wine-7.19). Does running with wine-staging (that has a fix for this bug) change anything? -- 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.

Oct. 18, 2022