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

[Bug 53130] New: ntdll:threadpool - test_tp_instance() fails (rarely) on Windows 8+
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53130 Bug ID: 53130 Summary: ntdll:threadpool - test_tp_instance() fails (rarely) on Windows 8+ Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com ntdll:threadpool - test_tp_instance() fails (rarely) on Windows 8+: threadpool.c:1170: Test failed: WaitForSingleObject returned 0 threadpool.c:1210: Test failed: WaitForSingleObject returned 258 https://test.winehq.org/data/patterns.html#ntdll:threadpool These two failures always go together. The failure is pretty rare, about 4.1%, so it can easily be missing from a test configuration's WineTest runs which results in false positives. -- 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.

1 5

[Bug 53288] New: Application compiled with MSVC 2022 ASan does not start, needs QueryVirtualMemoryInformation
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53288 Bug ID: 53288 Summary: Application compiled with MSVC 2022 ASan does not start, needs QueryVirtualMemoryInformation Product: Wine Version: 7.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: rpisl(a)seznam.cz Distribution: --- Application compiled with MSVC 2022 ASan does not start in Wine 7.11 as it needs implementation of QueryVirtualMemoryInformation. Console output: ==808==AddressSanitizer CHECK failed: D:\a\_work\1\s\src\vctools\crt\asan\llvm\compiler-rt\lib\sanitizer_common\sanitizer_win.cpp:1108 "((QueryVirtualMemoryInformation && "ASan requires the Windows 10-only API, QueryVirtualMemoryInformation")) != (0)" (0x0, 0x0) <empty stack> -- 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.

1 8

[Bug 53741] New: Gothic 2 - Night of the Raven 2.7 - Msdbi.dll failed to initialize
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53741 Bug ID: 53741 Summary: Gothic 2 - Night of the Raven 2.7 - Msdbi.dll failed to initialize Product: Wine Version: 7.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: VladimirVSC(a)yandex.ru Distribution: --- Created attachment 73183 --> https://bugs.winehq.org/attachment.cgi?id=73183 Gothic 2 msdbi.dll error report The game doesn't start with "msdbi.dll failed to initialize" error. The same game copy starts fine in stable 7.0 version. -- 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.

1 14

[Bug 53529] New: Make possible to use wine with custom ld-linux.so.2 32-bit preloader, without hacks
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53529 Bug ID: 53529 Summary: Make possible to use wine with custom ld-linux.so.2 32-bit preloader, without hacks Product: Wine Version: 7.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ruanformigoni(a)gmail.com Distribution: --- Some references of this limitation of wine: - https://github.com/AppImage/AppImageKit/wiki/Bundling-Windows-applications - https://github.com/Hackerl/Wine_Appimage/issues/11 - https://github.com/AppImage/AppImageKit/issues/361 The issue is that, although it is possible to use another preloader, wine seems to launch instances that still use the standard ld.so.2 path instead of the modified one. More details: - https://www.winehq.org/pipermail/wine-devel/2017-November/119906.html - https://www.winehq.org/pipermail/wine-devel/2017-November/119944.html -- 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.

1 8

[Bug 53266] New: Syberia: game crashes frequently
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53266 Bug ID: 53266 Summary: Syberia: game crashes frequently Product: Wine Version: 7.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: memax(a)gmx.fr Distribution: Ubuntu Created attachment 72641 --> https://bugs.winehq.org/attachment.cgi?id=72641 terminal output Ubuntu 20.04.4 LTS 64bit NVIDIA GeForce 940MX with driver 510.73.05 Wine staging 7.11 (WineHQ binary package) with a clean Wine directory and the default Wine configuration Syberia (2002 game) GOG.com french version syberia_1.0.0_hotfix4_(53936) 39e9e778c755c081f3e4b12dc5f6ef4260cbfb14 Game.exe Level of detail: high Screen depth: 32bit Anti-aliasing: on The game crashes frequently and randomly, each time at a different point in the game. This doesn't seem to be triggered by any particular action in the game. -- 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.

1 13

[Bug 53268] New: urlmon:protocol - test_protocol_terminate() fails on Windows and Wine
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53268 Bug ID: 53268 Summary: urlmon:protocol - test_protocol_terminate() fails on Windows and Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: urlmon Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com urlmon:protocol - test_protocol_terminate() fails on Windows and Wine: protocol.c:1188: Test failed: unexpected call ReportResult protocol.c:1196: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:3334: Test failed: Read failed: 00000001 https://test.winehq.org/data/patterns.html#urlmon:protocol Where 80004004 == E_ABORT. These three failures always happen together. The last one is in test_protocol_terminate() while the first two are in ProtocolSink_ReportResult(). These failures happen on all Windows versions and in Wine too with varying frequency (frequent on Windows 7 and less on 21H1, etc.). -- 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.

1 3

[Bug 45233] New: TIDAL installer can' t launch installed program in 64bit WINEPREFIX
by wine-bugs＠winehq.org 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=45233 Bug ID: 45233 Summary: TIDAL installer can't launch installed program in 64bit WINEPREFIX Product: Wine Version: 3.8 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 61462 --> https://bugs.winehq.org/attachment.cgi?id=61462 Wine log in 64bit WINEPREFIX After installation has finished (you need to use the msi installer due to bug 45232), it offers you to start the program. This only works in a 32bit WINEPREFIX, it fails with 64bit. -- 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 53387] New: Vernier USB sensors are not usable in WINE
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53387 Bug ID: 53387 Summary: Vernier USB sensors are not usable in WINE Product: Wine Version: 7.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tuomas.nurmi(a)opinsys.fi Distribution: --- Created attachment 72775 --> https://bugs.winehq.org/attachment.cgi?id=72775 Logs from various situations described in the bug report Vernier USB student laboratory sensors ( https://www.vernier.com/products/go-direct/ ) are not usable with WINE. Tested on Debian 11 Bullseye (equivalent), kernel 5.10, wine 7.13 from https://wiki.winehq.org/Debian . (Earlier tests with previous wine versions have also been negatives, however, they haven't been as comprehensive and well-documented as this) Tested with an earlier sensor model, a Go! Temp ver 1.53 and a later Go Direct Sensor (idVendor 08f7, idProducts 0002 and 0010, respectively). They show up in Linux syslog as shown in attachment section 1. Udev rules for the devices are in place, as described by (the somewhat outdated) https://wiki.winehq.org/Hid and Vernier's native library guidelines at https://github.com/VernierST/godirect-examples/tree/main/python , as follows: KERNEL=="hidraw*", SUBSYSTEM=="hidraw", GROUP="plugdev", MODE="0666" KERNEL=="hiddev*", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="08f7", MODE="0666" SUBSYSTEM=="usb_device", ATTRS{idVendor}=="08f7", MODE="0666" resulting into following permissions with plugged devices crw-rw-rw- 1 root plugdev 242, 0 20. 7. 13:36 /dev/hidraw0 crw-rw-rw- 1 root root 180, 0 20. 7. 13:36 /dev/usb/hiddev0 Resulting in functioning sensors with the native library example software from Vernier (attachment section 2), as well as with an earlier discontinued Linux version of LoggerPro, and the Vernier Graphical Analysis Chrome app ( https://chrome.google.com/webstore/detail/vernier-graphical-analysi/dncgedb… ) The sensors were tested also Windows 10, and were visible/detected by both the Microsoft hid example application hclient.exe and Vernier LoggerPro3. However, the devices are not recognized by LoggerPro3 nor hclient.exe run through wine-7.13. Logs with WINEDEBUG=+hid,+wineusb,+plugplay of these are shown in attachment sections 3, 4, and 5. Not a specialist in any of the related fields, but the logs show seemingly correctly recognized plugging of the device, 00cc:trace:wineusb:add_usb_device Adding new device 0x7f9330001f80, vendor 08f7, product 0010. 00d0:trace:wineusb:add_unix_device Adding new device 00007F934C016ED0, vendor 08f7, product 0010. ... 00c8:trace:plugplay:enumerate_new_device Creating new device L"USB\\VID_08F7&PID_0010\\0". but the device is not recognized by LoggerPro, nor listed by hclient.exe. (I don't know if the plugplay:install_device_driver error following in the logs is related) -- 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.

1 15

[Bug 11531] New: Richard Burns Rally - Trees/buildings/ fences disappear after a while
by wine-bugs＠winehq.org 25 Nov '22

25 Nov '22

http://bugs.winehq.org/show_bug.cgi?id=11531 Summary: Richard Burns Rally - Trees/buildings/fences disappear after a while Product: Wine Version: CVS/GIT Platform: PC URL: http://appdb.winehq.org/objectManager.php?sClass=version &iId=5934 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: tuomo.kohvakka(a)iki.fi While playing Richard Burns Rally, trees/buildings/other stuff disappear after a couple of minutes. This still happens with latest wine, 0.9.55 that is. It would be nice if this wouldn't happen :) I pretty sure this is regression, however I can't verify this right now. Judging from appdb comments, problems have continued at least from 0.9.49. AppDB: http://appdb.winehq.org/objectManager.php?sClass=version&iId=5934 -- 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 63

[Bug 53017] New: user32:monitor killed by X Error on Debian 11 + Intel GPU
by WineHQ Bugzilla 25 Nov '22

25 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53017 Bug ID: 53017 Summary: user32:monitor killed by X Error on Debian 11 + Intel GPU Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:monitor gets killed by an X Error while running test_ChangeDisplaySettingsEx() on my Debian 11 + Intel GPU machine (see fg-deb64-*). This results in this type of failure: monitor.c:61: GetProcAddress(user32, DisplayConfigSetDeviceInfo) failed. user32:monitor:0834 done (0) in 0s The main process has no test summary line The lack of a summary line is what indicates that the process was summarily killed, typically by a Unix library call. Looking into some more details it is this call which causes the X Error: res = ChangeDisplaySettingsExA(devices[device].name, &dm3, NULL, CDS_RESET, NULL); And adding traces in winex11.drv shows more precisely that the crash happens because bad physical size values are passed to XRRSetScreenSize(): dmFields=BITSPERPEL,PELSWIDTH,PELSHEIGHT,DISPLAYFLAGS,DISPLAYFREQUENCY,DISPLAYORIENTATION dmBitsPerPel=8 dmPelsWidth=720 dmPelsHeight=400 dmDisplayFrequency=70 dmDisplayFlags=0 dmDisplayOrientation=0 0024:trace:x11settings:apply_display_settings handler:XRandR 1.4 changing L"\\\\.\\DISPLAY1" to position:(0,0) resolution:720x400 frequency:70Hz depth:8bits orientation:0. 0024:warn:xrandr:xrandr14_set_current_mode Cannot change screen color depth from 32bits to 8bits! 0024:trace:xrandr:set_screen_size mm_width=0 = 720 * 1 / 3840 0024:trace:xrandr:set_screen_size mm_height=0 = 400 * 2 / 2160 0024:trace:xrandr:xrandr14_set_current_mode 1638 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Value in failed request: 0x0 Serial number of failed request: 209 Current serial number in output stream: 210 So there are two questions: * Should set_screen_size() have defensive code that prevents using 0 as the physical sizes? Using 1 instead seems to avoid the crashes. * Why do DisplayWidthMM() and DisplayHeightMM() return bad values? Weirder, I just got a bunch of runs with correct Display*MM() values and now that I removed traces it's bad again. Memory corruption? Note that xrandr knows the right physical dimensions for my screen: $ xrandr Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 VGA-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 698mm x 393mm 3840x2160 60.00*+ 30.00 25.00 24.00 29.97 23.98 29.98 2560x1600 59.94 2560x1440 59.95 1920x1080 60.00 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1920x1080i 60.00 50.00 59.94 1680x1050 59.95 1600x900 60.00 1280x1024 75.02 60.02 1280x800 59.81 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 60.00 832x624 74.55 800x600 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 HDMI-2 disconnected (normal left inverted right x axis y axis) HDMI-3 disconnected (normal left inverted right x axis y axis) -- 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.

1 8