https://bugs.winehq.org/show_bug.cgi?id=54557
Bug ID: 54557
Summary: winmm:midi gets unexpected messages on w10pro64 (21H1)
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: winmm&mci
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
winmm:midi gets unexpected messages on w10pro64 (21H1):
* 2023-02-13 on w10pro64-fr (64-bit)
midi.c:988: Message 3c7, wParam=2f1e410, lParam=0 from midiStreamOpen
midi.c:1039: Message 320, wParam=e3006fc7, lParam=1 from midiStreamOut
midi.c:1039: Test failed: bad message 320/1 from midiStreamOut, expect
3c9/65f820
midi.c:1048: Message 320, wParam=e3006fc7, lParam=1 from midiStreamClose
midi.c:1048: Test failed: bad message 320/1 from midiStreamClose, expect 3c8/0
* 2023-02-20 on w10pro64-he (64-bit)
midi.c:662: Message 320, wParam=e3006fc7, lParam=1 from midiStream still paused
midi.c:662: Test failed: bad message 320/1 from midiStream still paused, expect
0/feedf00d
midi.c:685: Message 320, wParam=e3006fc7, lParam=1 from midiStream callback
midi.c:685: Test failed: bad message 320/1 from midiStream callback, expect
3ca/65f820
midi.c:686: Message 3ca, wParam=2eeb120, lParam=65f820 from midiStreamOut
midi.c:686: Test failed: bad message 3ca/65f820 from midiStreamOut, expect
3c9/65f820
...
midi.c:746: Message 3c9, wParam=2eeb120, lParam=65f820 from 0 bytes recorded
midi.c:746: Test failed: bad message 3c9/65f820 from 0 bytes recorded, expect
0/feedf00d
* 2023-02-21 on w10pro64-hi (64-bit)
midi.c:366: Message 320, wParam=e3006fc7, lParam=1 from midiOutLong unprepared
midi.c:366: Test failed: bad message 320/1 from midiOutLong unprepared, expect
0/feedf00d
midi.c:378: MIDIHDR flags=2 when unsent
midi.c:415: Message 320, wParam=e3006fc7, lParam=1 from midiOutClose
midi.c:415: Test failed: bad message 320/1 from midiOutClose, expect 3c8/0
midi.c:423: Message 3c8, wParam=2ea4810, lParam=0 from midiOutOpen WINDOW
midi.c:423: Test failed: bad message 3c8/0 from midiOutOpen WINDOW, expect
0/feedf00d
See https://test.winehq.org/data/patterns.html#winmm:midi
These are the only known instances so far so it looks like this is caused by a
change that happened in February.
Where 0x320 == WM_DWMCOLORIZATIONCOLORCHANGED ???
0x3c8 == MM_MOM_CLOSE
0x3c9 == MM_MOM_DONE
0x3ca == MM_MOM_POSITIONCB
It's possible that 0x320 is the cause for all failures. If it really is
WM_DWMCOLORIZATIONCOLORCHANGED then it is probably caused by some other test
and thus really not related to midi. So it may make sense to add it to the
spurious_message() filter.
--
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=54556
Bug ID: 54556
Summary: winmm:midi fails on w11pro64_amd and w11pro64_nv
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: winmm&mci
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
winmm:midi fails on w11pro64_amd and w11pro64_nv:
midi.c:1147: Found 1 MIDI OUT devices
midi.c:252: Found 1 MCI sequencer devices
midi.c:1155: ** Testing device 0
midi.c:285: * Microsoft GS Wavetable Synth: manufacturer=1, product=27, tech=7,
support=1: 32 voices, 32 notes
midi.c:304: Test failed: midiOutOpen(dev=0) rc=MMSYSERR_ERROR
midi.c:620: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR
midi.c:1164: ** Testing MIDI mapper
midi.c:285: * Microsoft MIDI Mapper: manufacturer=1, product=1, tech=5,
support=9: 0 voices, 0 notes
midi.c:304: Test failed: midiOutOpen(dev=-1) rc=MMSYSERR_ERROR
midi.c:620: Test failed: midiStreamOpen(dev=-2) rc=MMSYSERR_ERROR
See https://test.winehq.org/data/patterns.html#winmm:midi
Where -1 == MIDIMAPPER
-2 is probably udev after being modified by midiStreamOpen()
This is probably because these two test configurations use the graphics card's
HDMI out audio device but the 'screen' has no speaker. See bug 54523 for more
details. Bug 54538 is probably the same issue too.
It's still strange that midiOutGetNumDevs() returns 1 device when trying to use
it does not actually work. Maybe that's a bug in the GPU drivers?
--
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=54555
Bug ID: 54555
Summary: winmm:mci sometimes crashes on exit on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: winmm&mci
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
winmm:mci sometimes crashes on exit on Windows:
0fec:mci: 675 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0
skipped.
mci.c:1796: this is the last test seen before the exception
0fec:mci: unhandled exception c0000005 at 75B37660
winmm:mci:0fec done (-1073741819) in 15s 453B
See https://test.winehq.org/data/patterns.html#winmm:mci
The "tests executed" line indicates that the crash happened either in the test
framework's main function or on process exit. The usual suspects are memory /
stack corruption, threads running code from unloaded dlls, etc. There is a
comment indicating that "Win9X hangs when exiting with something still open".
Maybe the "close all" command it not always completely effective.
The oldest known instance was on 2022-08-31 and this happened 8 times until
2022-12-07, and then twice in February 2023. It's not clear if the December and
January hiatus was just pure luck or if this is caused by external interference
that went away during that period.
This also seems to be specific to Windows 10 2004+.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=32235
Bug #: 32235
Summary: Soldiers heroes of World War II crashes on startup
Product: Wine
Version: 1.5.16
Platform: x86
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: paulthetall(a)gmail.com
Classification: Unclassified
Created attachment 42522
--> http://bugs.winehq.org/attachment.cgi?id=42522
Crash log
Soldiers Heroes of World War 2 crash on startup see crash log. It says a out of
memory notification, so maybe a memory leak or something? I use the GOG.com
version in this test. Hope you guys can ind out what is going on. If you need
andy extra debug extensions let me know so I can provide it. Many thanks in
advance!
--
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.
https://bugs.winehq.org/show_bug.cgi?id=54548
Bug ID: 54548
Summary: eMule 0.51d: everything seems to work fine, but after
a while (minutes, hours) the program crashes with Wine
8.0 (stable).
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: lupuseh(a)hotmail.es
Distribution: ---
Created attachment 74088
--> https://bugs.winehq.org/attachment.cgi?id=74088
A recent backtrace
I have been using eMule 0.51d correctly for years with Wine versions lower than
8.0, but with the upgrade to Wine 8.0 in Ubuntu 22.04.1 it stopped working
correctly.
With Wine 8.0, eMule seems to work correctly until it crashes, leaving the
screen with black areas (without refreshing) and the only solution I find is to
kill the process with "kill -9 [PID_of_eMule]".
I have been testing also the latest version of eMule (0.60d) in a new
WINEPREFIX, but with the same results.
My system info:
Ubuntu 22.04.2 LTS
Linux 5.19.0-32-generic
Wine 8.0 (stable)
eMule 0.51d
(https://github.com/irwir/eMule/releases/tag/eMule_v0.51d-community)
inxi -Gxz
Graphics:
Device-1: Intel IvyBridge GT2 [HD Graphics 4000] vendor: ASUSTeK P8 series
driver: i915 v: kernel bus-ID: 00:02.0
Display: x11 server: X.Org v: 1.21.1.3 driver: X: loaded: modesetting
unloaded: fbdev,vesa gpu: i915 resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 4000 (IVB GT2)
v: 4.2 Mesa 22.2.5 direct render: Yes
--
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=54547
Bug ID: 54547
Summary: Hyperplanning software (index education) crashes all
the time for now
Product: Wine
Version: 8.2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: olivier.corrio(a)gmail.com
Distribution: ---
Created attachment 74087
--> https://bugs.winehq.org/attachment.cgi?id=74087
It is the backtrace
The software works several minutes but often it crashes in less than 1mn. I can
use it but suddenly it crashes
--
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=54169
Bug ID: 54169
Summary: ntoskrnl.exe:ntoskrnl - test_pnp_devices() sometimes
fails on Windows and Linux
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ntoskrnl
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ntoskrnl.exe:ntoskrnl - test_pnp_devices() fails on Windows 10 with test
signing turned on:
ntoskrnl.c:1801: Test failed: failed to create device, error 0xe0000207
ntoskrnl.c:1805: Test failed: failed to create set hardware ID, error 0x57
ntoskrnl.c:1808: Test failed: failed to register device, error 0x57
ntoskrnl.c:1813: Test failed: got error 0x57
ntoskrnl.c:1817: Test failed: failed to install device, error 0xe000020b
ntoskrnl.c:1822: Test failed: got error 0x57
ntoskrnl.c:1823: Test failed: got flags 0x10
ntoskrnl.c:1824: Test failed: got type 0
ntoskrnl.c:1546: Test failed: failed to get interface, error 0x103
ntoskrnl.c:1547: Test failed: wrong class
{deadbeef-29ef-4538-a5fd-b69573a362c0}
ntoskrnl.c:1549: Test failed: got flags 0x1
ntoskrnl.c:1563: Test failed: got 0 bus arrival messages
ntoskrnl.c:1569: Test failed: failed to get interface, error 0x103
ntoskrnl.c:1570: Test failed: wrong class
{deadbeef-29ef-4538-a5fd-b69573a362c0}
ntoskrnl.c:1579: Test failed: got 0 bus arrival messages
ntoskrnl.c:1580: Test failed: got 0 bus removal messages
ntoskrnl.c:1585: Test failed: failed to get interface, error 0x103
ntoskrnl.c:1586: Test failed: wrong class
{deadbeef-29ef-4538-a5fd-b69573a362c0}
ntoskrnl.c:1588: Test failed: got flags 0x1
ntoskrnl.c:1605: Test failed: got 0 child arrival messages
ntoskrnl.c:1612: Test failed: failed to get device, error 0x103
ntoskrnl.c:1613: Test failed: wrong class
{4d36e97d-e325-11ce-bfc1-08002be10318}
ntoskrnl.c:1616: Test failed: failed to get device ID, error 0x57
ntoskrnl.c:1617: Test failed: got ID "\x08"
ntoskrnl.c:1621: Test failed: got error 0x57
ntoskrnl.c:1637: Test failed: got error 0x57
ntoskrnl.c:1639: Test failed: got flags 0x69f1b90b
ntoskrnl.c:1640: Test failed: got type 0
ntoskrnl.c:1645: Test failed: got error 0x57
ntoskrnl.c:1650: Test failed: got error 0x57
ntoskrnl.c:1654: Test failed: got error 0x57
ntoskrnl.c:1655: Test failed: got type 0
ntoskrnl.c:1656: Test failed: got size 0
ntoskrnl.c:1662: Test failed: got error 0x57
ntoskrnl.c:1663: Test failed: got type 0
ntoskrnl.c:1664: Test failed: got size 0
ntoskrnl.c:1669: Test failed: got error 0x57
ntoskrnl.c:1670: Test failed: got type 0
ntoskrnl.c:1671: Test failed: got size 0
ntoskrnl.c:1676: Test failed: got error 0x57
ntoskrnl.c:1688: Test failed: failed to open child: 0xc0000034
ntoskrnl.c:1692: Test failed: got error 6
ntoskrnl.c:1693: Test failed: got id -559038737
ntoskrnl.c:1694: Test failed: got size 0
ntoskrnl.c:1699: Test failed: failed to open child: 0xc0000034
ntoskrnl.c:1703: Test failed: got error 6
ntoskrnl.c:1711: Test failed: got 0 child arrival messages
ntoskrnl.c:1712: Test failed: got 0 child removal messages
ntoskrnl.c:1715: Test failed: got error 6
ntoskrnl.c:1718: Test failed: got 0xc0000034
ntoskrnl.c:1722: Test failed: got error 6
ntoskrnl.c:1728: Test failed: got 0 child arrival messages
ntoskrnl.c:1729: Test failed: got 0 child removal messages
ntoskrnl.c:1833: Test failed: failed to remove device, error 0x57
ntoskrnl.c:1836: Test failed: expected failure
ntoskrnl.c:1837: Test failed: got error 0
ntoskrnl.c:1857: Test failed: failed to open service, error 1060
ntoskrnl.c:291: Test failed: expected SERVICE_STOPPED, got 0
See https://test.winehq.org/data/patterns.html#ntoskrnl.exe:ntoskrnl
This happens a couple of times per month, mostly in the 64-bit w1064-tsign
tests.
However this also happened on:
* 2022-07-04 w7u-pt-PT despite it not having test signing turned on.
* 2022-10-24 master: this is the first known instance of these failures in
Wine.
* 2022-12-01 lastestmaster: these failures seem to have been systematic on this
Wine test configuration.
Unlike on Windows, none of the official Wine test configurations seem to be
having this failure.
--
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=54543
Bug ID: 54543
Summary: Avantree Leaf USB audio device does not play sound in
applications run via wine
Product: Wine
Version: 8.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: linux(a)bernd-steinhauser.de
Distribution: ---
I'm using an USB audio device called "Avantree Leaf" to pass audio via
Bluetooth to a receiver.
After this change in the kernel
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
applications run by wine via the pulseaudio output cannot initiate a stream on
the audio device and there is no sound. To test, I've used the audio player
foobar2000, but it's the same for other Windows applications. Native Linux
applications work without problems so far.
The latest Wine version that I tested is 8.1, but I haven't found any between
Wine versions in this regard.
It also does not work, if I select the usb device specifically in winecfg or in
foobar2000 itself. I do however get sound if I select another device, e.g. my
onboard sound card or the HDMI output, thus I know it is a problem with the usb
device only.
I usually use pipewire/wireplumber as an audio server with pipewire-pulse as a
Pulseaudio replacement, but the problem also exists if I'm using standard
Pulseaudio instead.
There are two possible workarounds that I can use to get sound from the device
when running Wine application:
1. Disable the usb audio latency management by loading the module with the
parameter lowlatency=0
2. Set clock.min-quantum 512 in pipewire/wireplumber, which I think also
increases the latency a bit
The maintainer of the kernel usb audio driver thinks that this an application
problem and that the kernel driver is working correctly. Therefore, I'm now
opening this bug report.
The corresponding bug report on the kernel side is, there I also have some
additional information available, not sure if I should replicate all of that
here:
https://bugzilla.kernel.org/show_bug.cgi?id=216909
Also, see this discussion on a pipewire issue, which was the first report I did
about this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2739#note_1713023
--
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=53144
Bug ID: 53144
Summary: kernel32:debugger - test_kill_on_exit() sometimes
fails on Windows 7
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
kernel32:debugger - test_kill_on_exit() sometimes fails on Windows 7:
debugger.c:2122: Test failed: NtSetInformationDebugObject failed c0000008
debugger.c:2144: Test failed: NtSetInformationDebugObject failed c0000008
https://test.winehq.org/data/patterns.html#kernel32:debugger
0xc0000008 == STATUS_INVALID_HANDLE
Sometimes only the second failure happens.
--
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=54541
Bug ID: 54541
Summary: d3dx10_34:d3dx10 - test_get_image_info() gets
unexpected hr on Windows 21H1+
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: d3d-util
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
d3dx10_34:d3dx10 - test_get_image_info() gets unexpected hr on Windows 21H1+:
d3dx10.c:2677: Test failed: Test 0: Got unexpected hr2 0xdeadbeef.
d3dx10.c:2686: Test failed: Test 0: Got unexpected hr2 0xdeadbeef.
See https://test.winehq.org/data/patterns.html#d3dx10_34:d3dx10
For d3dx10_34 it's always the same two checks that fail (the other d3dx10_*
tests get similar failures in other places) and it always happens in the 32-bit
tests.
These failures are pretty rare too, only 5 instances in the past 6 months:
2022-09-07 on w1064 32-bit
2022-09-20 on w1064-tsign 32-bit
2022-11-29 on w10pro64 32-bit
2023-01-27 on fgtb-w10pro64 32-bit
2023-02-17 on w1064 32-bit
--
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.