https://bugs.winehq.org/show_bug.cgi?id=55462
Bug ID: 55462
Summary: mfplay:mfplay sometimes times out on Windows 7
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mfplat
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
mfplay:mfplay sometimes times out on Windows 7:
mfplay:mfplay:0a24 done (258) in 120s 0B
See https://test.winehq.org/data/patterns.html#mfplay:mfplay
The test normally runs in under 1 second which means the time out is caused by
a deadlock. However this is pretty rare and has only happened in 1.6% of the
WineTest runs and only on Windows 7:
* 2023-02-22 win7_newtb-w7pro64-64
* 2023-03-02 win7_newtb-w7pro64-64
* 2023-05-10 win7_newtb-w7u-adm
* 2023-07-13 win7_newtb-w7pro64-64_1
* 2023-08-17 win7_newtb-w7pro64-64
--
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=52569
Bug ID: 52569
Summary: Zothero Error Launch XUL
Product: Wine
Version: 7.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: blbenyamin9(a)gmail.com
Distribution: ---
Created attachment 71889
--> https://bugs.winehq.org/attachment.cgi?id=71889
Zothero Error
Launch Zothero, and imidietly got this error
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code
(0x0258904c).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0258904c ESP:0051cb84 EBP:0051dcec EFLAGS:00010206( R- -- I - -P- )
EAX:00000000 EBX:00000000 ECX:0051cb44 EDX:00990094
ESI:009d13e8 EDI:0bc9d478
--
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=55344
Bug ID: 55344
Summary: Yuzu fails to start (needs MSVCP140_CODECVT_IDS.dll)
Product: Wine
Version: 8.12
Hardware: x86-64
URL: https://web.archive.org/web/20230727051938/https://github.com/yuzu-emu/yuzu-mainline/releases/download/mainl
ine-0-1503/yuzu-windows-msvc-20230722-3dfaf1ff2.tar.xz
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: lingm+winebz(a)posteo.org
Distribution: ---
1. Download and extract the Windows version of Yuzu 1503.
https://github.com/yuzu-emu/yuzu-mainline/releases/tag/mainline-0-1503 (see
the URL field for a direct archived link)
2. Run `wine yuzu.exe`
3. No window even shows up. The full output is:
```
$ wine yuzu.exe
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
00d8:err:module:import_dll Library MSVCP140_CODECVT_IDS.dll (which is needed
by L"$snip_path$\\yuzu.exe") not found
00d8:err:module:LdrInitializeThunk Importing dlls for
L"$snip_path$\\yuzu.exe" failed, status c0000135
```
`winetricks vcrun2019` works around this problem and allows Yuzu to start
properly.
--
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=55331
Bug ID: 55331
Summary: ntdll:file - The 64-bit
test_file_disposition_information() gets unsupported
error on Windows 10 1607 and 1709
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:file - The 64-bit test_file_disposition_information() gets unsupported
error on Windows 10 1607 and 1709:
file.c:3141: Test failed: unexpected FileDispositionInformationEx result
(expected STATUS_SUCCESS or SSTATUS_INVALID_INFO_CLASS, got c00000bb)
See https://test.winehq.org/data/patterns.html#ntdll:file
Where c00000bb == STATUS_NOT_SUPPORTED
c0000003 == STATUS_INVALID_INFO_CLASS
This is a case where early Windows 10 versions don't fully support
FileDispositionInformationEx(). Further tests show that:
* On Windows 10 1507 we get STATUS_INVALID_INFO_CLASS as expected by the test.
* On Windows 10 1607 the 32-bit case gets STATUS_INVALID_INFO_CLASS too but the
64-bit one gets STATUS_NOT_SUPPORTED.
* On Windows 10 1709 gets STATUS_NOT_SUPPORTED in both 32 and 64-bit.
* And Windows 10 1809 gets STATUS_SUCCESS in both cases.
The failures started on 2023-06-27 and a quick test confirms they are caused by
the commit that added the test:
commit cbc1e4423e6d40221734544d081c718cb2a2a778
Author: Joel Holdsworth <joel(a)airwebreathe.org.uk>
AuthorDate: Mon May 1 15:27:57 2023 +0100
ntdll/tests: Add tests for FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE.
Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk>
--
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=54676
Bug ID: 54676
Summary: winetricks --verify dotnet20 (AutoHotKey) fails in a
wow64 build
Product: Wine
Version: 8.3
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: dotnet, download, wow64
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
Created attachment 74190
--> https://bugs.winehq.org/attachment.cgi?id=74190
terminal output
The install itself seems to go okay (at least, it exits successfully in quiet
mode).
Running --verify (which should run the .Net verifier tool) instead just hangs
on:
/opt/oldwownew/wine-8.3/bin/wine y:\ahk\AutoHotkeyU32.exe
C:\windows\Temp\dotnet20.ahk
--
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=55127
Bug ID: 55127
Summary: httpapi:httpapi - test_v2_bound_port() sometimes
succeeds in connecting on Windows 10
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: httpapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
httpapi:httpapi - test_v2_bound_port() sometimes succeeds in connecting on
Windows 10:
httpapi.c:1426: Test failed: Connecting to socket succeeded, 0.
httpapi.c:1427: Test failed: Unexpected error connecting to socket, 0.
See https://test.winehq.org/data/patterns.html#httpapi:httpapi
This failure first happened on 2023-02-09 and has happened 4 times since then:
* 2023-02-09 win22H2_fgtb-w10pro64-32
* 2023-03-30 win22H2_fgtb-w10pro64-32
* 2023-05-30 win2009_newtb-w1064v2009-64
* 2023-06-15 win2009_newtb-w1064v2009-64
--
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=54866
Bug ID: 54866
Summary: ieframe:webbrowser - test_SetQueryNetSessionCount()
sometimes gets an unexpected session count on Windows
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ieframe
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ieframe:webbrowser - test_SetQueryNetSessionCount() sometimes gets an
unexpected session count on Windows:
webbrowser.c:4440: init_count 1
webbrowser.c:4443: Test failed: count = 3
webbrowser.c:4446: Test failed: count = 3
webbrowser.c:4449: Test failed: count = 2
webbrowser.c:4452: Test failed: count = 2
See https://test.winehq.org/data/patterns.html#ieframe:webbrowser
These failures only happen on Windows 10 21H1 to 22H2.
On Windows 10 init_count is either 1 or 2 (on w8adm is can be 0 too), but all
the failures so far happened with an init_count of 1. That said there are also
a lot of successful runs with init_count == 1.
This looks a lot like the browser creates a net session for its own purposes:
* Either init_count is 1 and the extra net session is never created or gets
created after test_SetQueryNetSessionCount() is done so all is fine.
* Or the extra net session is created it before test_SetQueryNetSessionCount()
starts and outlives it so our tests pass.
* Or the extra net session gets created after we get init_count but before the
next test so that all our tests are off by one.
* But it seems the extra net session never gets created after the first
SESSION_INCREMENT test.
Note that on my Windows 10 VM when I start iexplorer.exe by hand and then run
the test I always get init_count == 2. But if IE is not already running I get
init_count == 0.
In any case if it's a race condition I could send a patch to retry a couple of
times.
--
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=54073
Bug ID: 54073
Summary: ws2_32:sock - test_close_events() sometimes fails in
Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ws2_32:sock - test_close_events() sometimes fails in Wine:
sock.c:6775: Test succeeded inside todo block: event series matches
sock.c:6785: Test failed: got unexpected event 0x20
sock.c:6785: Test failed: event series matches
See https://test.winehq.org/data/patterns.html#ws2_32:sock
This happens in the nightly WineTest runs about twice per month but also
impacts merge requests (for instance MR!1524 and MR!1525 where it happened on
the GitLab CI).
--
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.