https://bugs.winehq.org/show_bug.cgi?id=55768
Bug ID: 55768
Summary: gdi32:driver - test_D3DKMTCheckOcclusion() sometimes
gets unexpected success on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: gdi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
gdi32:driver - test_D3DKMTCheckOcclusion() sometimes gets unexpected success on
Windows:
driver.c:770: Test failed: Got unexpected return code 0.
driver.c:784: Test failed: Got unexpected return code 0.
driver.c:789: Test failed: Got unexpected return code 0.
See https://test.winehq.org/data/patterns.html#gdi32:driver
Where 0 == STATUS_SUCCESS
The test expects success in dual screen configurations and
STATUS_GRAPHICS_PRESENT_OCCLUDED otherwise. The failures all happen when a
single-screen configuration gets success instead of the expected occlusion
error.
That's quite rare and happens irregularly though:
* 2023-02-23 win22H2_fgtb-w10pro64-rx550-64
* 2023-03-02 win1507_newtb-w1064v1507-32
* 2023-03-09 win81_newtb-w864-64
* 2023-03-29 win1507_newtb-w1064v1507-32
* 2023-04-18 win1507_newtb-w1064v1507-32
* 2023-09-08 win1507_newtb-w1064v1507-64
* 2023-10-09 win1507_newtb-w1064v1507-64
Maybe it's caused by interference from another test?
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55767
Bug ID: 55767
Summary: user32:win - test_SC_SIZE() fails with the Wayland
driver
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:win - test_SC_SIZE() fails with the Wayland driver:
win.c:12804: Test failed: rect.left = 100
win.c:12806: Test failed: rect.right = 200
See https://test.winehq.org/data/patterns.html#user32:win
These failures are systematic (see rbernon-wayland-*) and started on
2023-09-27.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55766
Bug ID: 55766
Summary: user32:win - test_SetActiveWindow_0() gets a bad
foreground Window in wine
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:win - test_SetActiveWindow_0() gets a bad foreground Window in KDE:
win.c:3817: Test failed: GetForegroundWindow returned 00180136
win.c:3819: Test failed: GetActiveWindow returned 00180136
win.c:3821: Test failed: GetFocus returned 00180136
See https://test.winehq.org/data/patterns.html#user32:win
This is systematic[1] on fg-deb64, my development desktop, maybe because it
runs KDE?
However it also happens in the GitLab CI, though only when testing MRs, not in
the nightly WineTest runs!
* 2023-10-09 MR!4055
* 2023-10-05 MR!3994
* 2022-11-14 MR!1342
* 2022-11-13 MR!1341
* 2022-11-10 MR!1326
[1] Actually for the past 8 months fg-deb64 has a total of 2 runs without these
failures, out of 635.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54870
Bug ID: 54870
Summary: Logos Bible 10 (dotnet 6) crashes trying to load image
Product: Wine
Version: 8.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: johnpgoodman(a)gmail.com
Distribution: ---
Created attachment 74363
--> https://bugs.winehq.org/attachment.cgi?id=74363
Terminal output with crash info
The app crashes when trying to display an image which is embedded at the
beginning of a specific book. It may apply to other books if they have embedded
images? If you open the book beyond the first page (by moving it there on a
windows machine and syncing position) then it will open ok. It's only as the
image comes on the screen that there is a crash. You never see the image. Some
other books work ok but this one crashes every time so it is likely to do with
image file type or possibly whether it is being fetched remotely?
Terminal output attached.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=53167
Bug ID: 53167
Summary: xaudio2_7:xaudio2 - test_simple_streaming() has a rare
failure caused by out-of-order callbacks
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: xaudio2
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
xaudio2_7:xaudio2 - test_simple_streaming() has a rare (~4.5%) failure caused
by out-of-order callbacks:
Mostly
xaudio2.c:69: Test failed: Callbacks called out of order: 1
but also sometimes (w8, w8adm, w864, w10pro64-ja, w10pro64-ko):
xaudio2.c:69: Test failed: Callbacks called out of order: 3
https://test.winehq.org/data/patterns.html#xaudio2_7:xaudio2
This failure (in the ': 1' version) also happens in Wine at about the same rate
(~5%)!
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55759
Bug ID: 55759
Summary: Cinebench 2024 needs
Windows.System.Profile.SystemIdentification
Product: Wine
Version: 8.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: etaash.mathamsetty(a)gmail.com
Distribution: ---
09d4:fixme:combase:RoGetActivationFactory
(L"Windows.System.Profile.SystemIdentification",
{5581f42a-d3df-4d93-a37d-c41a616c6d01}, 00007FFFFE1FD840): semi-stub
09d4:err:combase:RoGetActivationFactory Failed to find library for
L"Windows.System.Profile.SystemIdentification"
The app works fine in windows 7 mode for the most part, the above is preventing
it from running in windows 11 mode
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55758
Bug ID: 55758
Summary: quartz:filtergraph - test_render_run() sometimes gets
a partial render in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: quartz
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
quartz:filtergraph - test_render_run() sometimes gets a partial render in Wine:
filtergraph.c:635: Test failed: Got hr 0x40242.
filtergraph.c:645: Test marked todo: Got hr 0.
filtergraph.c:617: running L"test.mp3"
filtergraph.c:624: Tests skipped: L"test.mp3": codec not supported; skipping
test
filtergraph.c:571: Test failed: Got hr 0x80004005.
Unhandled exception: page fault on read access to 0x00000000 in wow64 32-bit
code (0x0043afbc).
[...]
See https://test.winehq.org/data/patterns.html#quartz:filtergraph
Where 0x40242 == VFW_S_PARTIAL_RENDER
0x80004005 == E_FAIL
The first known instance happened on 2023-08-08 in a merge request (there is no
known instance in the previous 6 months). Also it seems to mainly happen in the
GitLab CI:
* 2023-08-08 MR!3526
* 2023-08-17 linux_rbernon-x11-fvwm-win32
* 2023-10-05 linux_gitlab-debian-32
* 2023-10-06 linux_gitlab-debian-32
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55753
Bug ID: 55753
Summary: Fonts on dialog/modal windows are not aliased
Product: Wine
Version: 8.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fonts
Assignee: wine-bugs(a)winehq.org
Reporter: jimmyg521(a)gmail.com
Distribution: ---
Created attachment 75248
--> https://bugs.winehq.org/attachment.cgi?id=75248
Screenshot of application mp3tag with open dialog box showing unalised fonts
I'm on a brand new install of MXLinux v23/Debian Bookworm with the latest
stable/dev wine using the Debian Bookworm PPA from WineHQ (now after
significant trouble-shooting). **Previous install of MXLinux v21 with it's
version of wine-staging did not exhibit this behavior.**
Current system/wine information:
√ ~ > uname -a
Linux HOLLIN 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2 (2023-07-27)
x86_64 GNU/Linux
HOLLIN [uname -a] ~
23-10-08 4:17PM
√ ~ > wine --version
wine-8.17
MX-Linux System Report:
KDE Plasma 5.27.5; Debian 12.2
CPU: 8-Core Intel Core i7-10700 (-MT MCP-) speed/min/max: 990/800/4800 MHz
Kernel: 6.1.0-10-amd64 x86_64 Up: 8d 9h 1m Mem: 6843.1/15775.5 MiB (43.4%)
Storage: 19.11 TiB (41.5% used) Procs: 476 Client: Unknown Client: mx-welcome
inxi: 3.3.06
====
Problem is not about an application installing or running, it's about the
dialog windows that both Wine itself and applications display. For example, I
can run the notepad app from a terminal in any wine prefix (default 64-bit or a
new 32-bit)and its fonts on menubar and menus look fine. But if, for example, I
select from the menubar File > Open, the fonts on the Open dialog window are
not aliased. The dialog itself is fully functional, its only the fonts that are
unaliased. WineCfg it turns out is a dialog (modal?) window and it opens with
unaliased fonts. No change to any of the fonts listed on the WineCfg Desktop
Integration Appearance Theme modify this font behavior.
I have:
1. Completely uninstalled the MXLinux v23 default wine (using mc to track down
every folder and file to delete them); reinstalled from the MXLinux repos - no
change
2. Completely uninstalled again and reinstalled using flatpak version from
org.winehq.Wine - no change
3. Completely uninstalled again, added the Debian Bookwork PPAs to install from
WineHq - no change
4. Installed from the WineHQ PPA Wine-Dev - no change
5. Googled ad nauseam various combinations of words trying to limit search
results to this specific issue, but it's a bit hopeless; most everyone is
looking for ways to install fonts or make fonts larger, but that all works fine
for me; in fact, on the Winecfg tab for Appearance, the slider is at 144 dpi
and the font displayed below the slider is, of course, correctly aliased; just
not any of the rest of the fonts used on the Winecfg dialog window or any other
dialog window
6. I have made sure that any tahoma, etc. font in my Linux system that might
cause some kind of font conflict was deleted and reinstalled using winetricks
and rebooted my system - no change
7. I have removed nearly every font from my user /.fonts/ folder and restarted
- no change
8. I have used winetricks to set the fontsmooting registry keys - no change
9. I have used winetricks to install most of the avialable fonts - no change
10. I have created test 32-bit and 64-bit prefixes using winetricks and Q4wine
- no change; dialog/modal dialog fonts remain unaliases
10. I have added specific values to my local linux install's user .fonts.conf
file to force Linux system aliasing and hinting hoping, based on a blog post,
this might spill over into wine, and restarted - no change
Again - this is not about funcationality - it all works, it's only about the
font display of dialog windows; primary windows of apps and Wine system apps
(regedit, notepad, control, taskmgr) all load and display fonts as expected
until I use File | Open, File | Print, etc. (see attached screen of application
mp3tag running in a 32-bit prefix).
Why is this a problem? On an HDPI monitor, pencil thin unaliased fonts are very
difficult to read. It is a real usability issue.
Here is an image of what I'm talking about - the application mp3tag (which I've
been using for several years in wine on both Kubutu and MXLinx v21) with the
File | Options dialog enabled. If you increase view to 200%, you can clearly
see that the font of the dialog is not aliased while the menu font and other
fonts in the app UI are.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55757
Bug ID: 55757
Summary: The 32-bit kernel32:debugger gets a debugger inactive
failure in the new WoW mode on macOS
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The 32-bit kernel32:debugger gets a debugger inactive failure in the new WoW
mode on macOS:
debugger.c:205: child: crashing...
Unhandled exception: page fault on write access to 0x00000000 in segmented
32-bit code (0107:0044d143).
Assertion failed: curr_mode == stm_32bit, file ../wine/dlls/dbghelp/cpu_i386.c,
line 278
debugger.c:735: Test failed: exit code = c0000354
See https://test.winehq.org/data/patterns.html#kernel32:debugger
Where c0000354 == STATUS_DEBUGGER_INACTIVE
The failures are systematic but only happen when running the 32-bit test in a
Windows-on-Windows wineprefix on macOS.
Looking at the pattern one may also think they started on 2023-10-02 but in
fact that's just because before that date the WineTest report had so many other
errors that test.winehq.org rejected the report. In fact the test was already
failing all the way back to at least 2023-09-07 (there is no earlier data).
--
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.
https://bugs.winehq.org/show_bug.cgi?id=55756
Bug ID: 55756
Summary: The 32-bit ntdll:wow64 crashes in the new WoW mode on
macOS
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The 32-bit ntdll:wow64 crashes in the new WoW mode on macOS:
[... skip failures from bug 55752, bug 55754 and bug 55755...]
wow64.c:1773: got init block 000000f0
Unhandled exception: page fault on read access to 0xffffffff in segmented
32-bit code (0107:00dd000e).
Assertion failed: curr_mode == stm_32bit, file ../wine/dlls/dbghelp/cpu_i386.c,
line 278
ntdll:wow64:0e24 done (-1073740972) in 2s 665B
See https://test.winehq.org/data/patterns.html#ntdll:wow64
The failures are systematic but only happen when running the 32-bit test in a
Windows-on-Windows wineprefix on macOS.
Looking at the pattern one may also think they started on 2023-10-02 but in
fact that's just because before that date the WineTest report had so many other
errors that test.winehq.org rejected the report. In fact the test was already
failing all the way back to at least 2023-09-07 (there is no earlier data).
--
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.