https://bugs.winehq.org/show_bug.cgi?id=51983
Bug ID: 51983
Summary: foobar2000 v1.5.1+ crashes on startup with Wine v6.6+
with Windows version set to "Windows 10"
Product: Wine
Version: 6.6
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: the.derivative.of.calculus(a)gmail.com
Distribution: ---
Created attachment 70970
--> https://bugs.winehq.org/attachment.cgi?id=70970
foobar2000 1.5.1 crash with windows 10 profile
I had an old version of foobar2000 that I had never got around to upgrading, so
I only recently came across this issue. Looking online it appears that a few
people ran into it starting with v6.6, and it still exists with v6.20 (and as
far as I can tell no one bothered to report it):
https://forum.winehq.org/viewtopic.php?t=35166https://hydrogenaud.io/index.php?topic=54933.525
When you start foobar2000 with Windows version set to "Windows 8.1" or below it
runs normally. However, if you use "Windows 10" the application window briefly
appears before the whole application crashes. Testing it, this affects
foobar2000 v1.5.1+
Looking through foobar2000's changelog: https://www.foobar2000.org/changelog
The one thing mentioning Windows 10 is:
Reworked integration with Windows 10 Universal Volume Control. Enabled by
default once again.
Looking at the error messages:
0024:fixme:combase:RoGetActivationFactory
(L"Windows.Media.Playback.BackgroundMediaPlayer",
{00000035-0000-0000-c000-000000000046}, 0032F9E4): semi-stub
0024:err:combase:RoGetActivationFactory Failed to find library for
L"Windows.Media.Playback.BackgroundMediaPlayer"
I'm wondering if there's a regression with Wine's handling of media controls
for Windows 10 or equivalent.
--
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=50526
Bug ID: 50526
Summary: ConEmu wineconsole Ctrl+m has different behavior
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: inseng
Assignee: wine-bugs(a)winehq.org
Reporter: adrianekaleksander(a)gmail.com
Distribution: ---
Cmd on Windows:
Ctrl+M moves the cursor to the next line (ENTER key)
On wine:
Ctrl+M shows ^M
1.Open wineconsole
2.Press ctrl+m
--
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=52082
Bug ID: 52082
Summary: Ace Ventura the CD-ROM game, page fault on read access
Product: Wine
Version: 5.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: guillere(a)adinet.com.uy
Distribution: ---
Created attachment 71094
--> https://bugs.winehq.org/attachment.cgi?id=71094
backtrack
Ace Ventura CD-ROM game hungs in the game start after 10 seconds
confirmed in Ace Ventura CDROM (Latin America) and Ace Ventura CDROM (German)
git bissect get this bug is introducced in commit
6b4de5102734de7dd77222bdb74f8cf5181022d8
This bug is a game bug (bad memory read)... but the game works OK in win 3.11
up to win xp (if i remember correctly)
commit 6b4de5102734de7dd77222bdb74f8cf5181022d8
ntdll: Don't use a custom alignment for large heap blocks.
--
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=51968
Bug ID: 51968
Summary: Winaero WEI Tool: Crash due to
C:\windows\performance\winsat\datastore missing
Product: Wine
Version: 6.20
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fox2code(a)gmail.com
Distribution: ---
Created attachment 70953
--> https://bugs.winehq.org/attachment.cgi?id=70953
Logs of the app crash
Some apps crashes due to the assumption that
C:\windows\performance\winsat\datastore exists
It's affecting this app: https://winaero.com/winaero-wei-tool/
Creating the folder manually allow the application to launch correctly
Note: I already have a WIP patch that I will submit to wine to fix this issue
--
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=51938
Bug ID: 51938
Summary: Safe Exam Browser (SEB) won't install even with
winetricks dotnet472
Product: Wine
Version: 5.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bammgabriana(a)gmail.com
Distribution: ---
Created attachment 70908
--> https://bugs.winehq.org/attachment.cgi?id=70908
Screenshot of "Setup Failed" message explaining the possible error
Safe Exam Browser (SEB) is a kiosk-like application integrated in Moodle to let
students take an online exam in full-screen mode. It requires that the student
install the SEB browser on his computer, which requires .NET Framework 4.72 and
VC++ 2015-2019 Redistributable runtimes.
Unfortunately, the setup program won't let you install. Even if the
requirements are installed via winetricks, the installer still complains that
they are missing and setup fails.
To install, download the file "SEB_3.3.1.388_SetupBundle.exe" from here:
https://sourceforge.net/projects/seb/files/seb/SEB_3.3.1/
To reproduce:
$ rm -rf ~/.wine
$ wineboot
$ winetricks -q dotnet472 vcrun2019
$ wine SEB_3.3.1.388_SetupBundle.exe
--
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=42030
Bug ID: 42030
Summary: winedbg: Internal crash at 0x9f58fd40
Product: Wine
Version: 1.8.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: kenorb(a)gmail.com
Distribution: ---
The following command crashes:
$ winedbg --command < <(echo help)
winedbg: Internal crash at 0x9f58fd40
Probably syntax isn't right, but still shouldn't internally crash.
--
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=51821
Bug ID: 51821
Summary: EVE Online Sisi Client Crashes Due to differences in
how Wine and Windows handle LoadLibraryExW Undefined
Behavior
Product: Wine
Version: 6.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: algebro(a)tuta.io
Distribution: ---
I've been chasing this for the last few days and think I may finally have
enough information to finally open a bug report. As of a few days ago, the Sisi
testing client for EVE stopped working in recent versions of Wine, and the logs
showed an unhandled Python error in a module called launchdarkly_client.pyd:
```ImportError: Failed to load DLL: Success```
I chased this down in a debugger and noticed they're passing a relative path to
LoadLibraryExW for this library only (full/absolute paths for every other
module), and 8 for dwFlags:
```hLibModule = LoadLibraryExW((LPCWSTR)plVar4[3],(HANDLE)0x0,8)```
Per the Microsoft documentation, 8 for dwFlags is undefined when the first
argument is a relative path:
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloade…
Weirdly enough, the library loads fine on Windows (I've confirmed in windbg),
but it fails with error code 0x7e (Module not found) when trying to load it in
wine. Other users running Wine 4.4 say Sisi launches fine and doesn't run into
the error, although I havent been able to get older versions to build to try
and test it, but it sounds like there is a difference between how recent Wine
versions implement LoadLibraryExW() and how Windows does, at least with regards
to the undefined behavior.
Let me know if I can provide any other information that would be helpful for
tracking this down.
Thanks!
--
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=52224
Bug ID: 52224
Summary: inetmib1:main test times out in linux
Product: Wine
Version: 7.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bernhardu(a)mailbox.org
Distribution: ---
inetmib1 times out regularly in testbot.
https://test.winehq.org/data/patterns.html#inetmib1:main
--
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=52200
Bug ID: 52200
Summary: Yamizome Liberator (demo): In game video isn't played.
Product: Wine
Version: 6.23
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
Assignee: wine-bugs(a)winehq.org
Reporter: sagawa.aki+winebugs(a)gmail.com
Distribution: Ubuntu
Yamizome Liberator -Yamiochi Yuusha to Ochiru Senki- Trial Edition[1] is a demo
version of NSFW visual novel released in 2020 by Escu:de in Japan.
After playing through the demo, I noticed in-game video isn't played when it
should be.
In detail, opening video, opening.wmv, should be played when the title screen
is idle for 60 seconds. Please note that the playback only happens after
playing through the demo due to some reason.
[1] https://vndb.org/r75003
--
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=52076
Bug ID: 52076
Summary: Wrong icons placement when using a theme
Product: Wine
Version: 6.22
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: uxtheme
Assignee: wine-bugs(a)winehq.org
Reporter: aros(a)gmx.com
Distribution: ---
Application: WinSCP
Just compare the screenshots. One is without using themes, the other one with
the default Light theme.
--
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=51220
Bug ID: 51220
Summary: version:info - The GetFileVersionInfoEx() checks fail
in non-English locales
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: version
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The GetFileVersionInfoEx() checks fail in non-English locales because the
returned information seems to be localized even when they shouldn't be, i.e.
for flags=0 and flags=FILE_VER_GET_NEUTRAL:
https://test.winehq.org/data/patterns.html#version:info
fr_FR:
info.c:709: Test failed: [0] got 1036, expected lang is 1033
ja_JP:
info.c:709: Test failed: [0] got 1041, expected lang is 1033
I suspect this is because this code block in GetFileVersionInfoSizeExW()
systematically fails to find the English resource:
LANGID english = MAKELANGID( LANG_ENGLISH, SUBLANG_DEFAULT );
hRsrc = FindResourceExW( hModule,
MAKEINTRESOURCEW(VS_VERSION_INFO),
(LPWSTR)VS_FILE_INFO, english );
I tried some alternative combinations for MAKELANGID() (though maybe not the
right one) to no avail. So it's unclear to me if the issue is a bug in
FindResourceExW() or an issue in the set up of the file version information in
kernel32.dll.
Note:
* The fg-deb64-* tests are run in the fr_FR.UTF-8 locale.
--
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=32183
Bug #: 32183
Summary: Cannot open console device read only, then read from
it to get input
Product: Wine
Version: 1.5.17
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: kernel32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: us(a)edmeades.me.uk
Classification: Unclassified
Created attachment 42462
--> http://bugs.winehq.org/attachment.cgi?id=42462
CON test program (source and exe)
(Email sent to wine-devel for assistance, but logging bug to track issue in
case I do not get anywhere)
CreateFile("\\.\CON", GENERIC_READ...) followed by ReadFile(...) works on
windows and fails on wine. I need this particular sequence of events to work in
order for a patch I have for cmd.exe to support CON input 'nicely' (read
'without hacks').
For simplicity sake I've cut this down to a tiny test program, which works on
windows and fails on wine which does the following:
Opens the device ("\\.\CON") with CreateFile with GENERIC_READ rights (which
internally opens a CONIN$ device with the same access rights)
Reads from the device with ReadFile
- Because its a console device, this drops through to ReadConsoleW, which
creates a CONOUT$ and then waits on a keystroke
- Once the key is pressed (WCEL_Get) the key is 'inserted' into the input
buffer by calling WriteConsoleInputW
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the CON
device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try to open
it with GENERIC_WRITE). CreateFile("CONIN$"...) will let me open in
GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and wine,
but if you open CONIN$ GENERIC_READ only then it fails on wine and works on
windows, with the same issue.
Now on windows, this works... the question is how to make it work on wine...
My gut feeling, with nothing backing this at all, is that WCEL_Get should not
use WriteConsoleInputW to inject the values into the input buffer, instead
making the server call directly, but passing through to the server call
something to indicate that it is ok to add the data to the buffer, but I'm fast
getting out of my depth!
How to reproduce: Compile sample source (exe provided in zip)...
Run as:
"test 1" - this is the one I need to work... \\.\CON GENERIC_READ case
"test 2" - this is a similar problem but opens CONIN$ GENERIC_READ
"test 3" - this works on both windows and wine, opening CONIN$
GENERIC_READ|GENERIC_WRITE
"test 4" - this fails on both windows and wine as you cannot open CON device
with WRITE access
Except for case 4, When its 'failing' - when you press a key in wine, it exits.
When its 'working' it reads from keyboard, echos to screen until ctrl+Z (crtl+D
on wine) is pressed and ends
--
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=51911
Bug ID: 51911
Summary: vbscript does not handle strings in if clauses
Product: Wine
Version: 6.19
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: sloper42(a)yahoo.com
Distribution: ---
This is followup from https://bugs.winehq.org/show_bug.cgi?id=50758
Test with postgresql-9.3 installer from [1]. It runs a script during
installation
similar to
https://github.com/three-plus-three/tpt_env_amd64/blob/master/postgresql/in…
that reports non-critical error to main install, script itself terminates.
Reduced test case for this looks like this:
---
if "0" then
end if
---
That leads to the following fixme, exactly that happens with the installer:
---
00f8:fixme:vbscript:stack_pop_bool unsupported for 000000000003C740 {VT_BSTR:
L"0"}
---
[1] https://www.enterprisedb.com/postgresql-tutorial-resources-training?cid=340
--
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=51396
Bug ID: 51396
Summary: cl.exe sometimes fails with internal compiler error
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rpisl(a)seznam.cz
Distribution: ---
Cl.exe from MSVC 2019 Build Tools sometimes fails with: "fatal error C1001:
Internal compiler error." A workaround is setting vcruntime140_1 to native.
This is possibly caused by unsupported flag in __CxxFrameHandler4:
0b24:fixme:seh:__CxxFrameHandler4 unsupported flags: 7a
which is unsupported FUNC_DESCR_IS_SEPARATED in
dlls/vcruntime140_1/except_x86_64.c
Not critical since the workaround exists. I'm ready to test this when the flag
is implemented.
--
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=51195
Bug ID: 51195
Summary: Lara Croft and the Temple of Osiris doesn't launch
Product: Wine
Version: 6.9
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Created attachment 70069
--> https://bugs.winehq.org/attachment.cgi?id=70069
log
d3dcompiler_43 - native,builtin
d3dx11_43 - native,builtin
(Otherwise the game fails after hitting 'Play' with "Failed to initialize
Direct3D with current settings")
msvcr110 - native,builtin (for launcher) Bug 49541
Assertion failed: iface->lpVtbl == &d3d11_rendertarget_view_vtbl, file
../wine/dlls/d3d11/view.c, line 1794
04d4:warn:d3d11:d3d_rendertarget_view_init Failed to create a wined3d
rendertarget view, hr 0x80070057.
04d4:warn:d3d11:d3d_rendertarget_view_create Failed to initialize rendertarget
view, hr 0x80070057.
wine-6.9-148-gce151dd681f
--
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=50714
Bug ID: 50714
Summary: CMS client stopped working after latest wine update
Product: Wine
Version: 6.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: denis.salmanovich(a)gmail.com
Distribution: ---
Created attachment 69460
--> https://bugs.winehq.org/attachment.cgi?id=69460
errors backtrace
Hello,
I am using version 5.9 of wine and CMS client
(https://camerayoosee.com/yoosee-cap-nhat-phien-ban-phan-mem-cms-client-moi-…)
version 1.0.0.53 and it works fine.
But if I want to update wine version to latest/newer (5.12 or 6.1) - I get
error after login screen. Tried on two different machines with different
kernels (both stack traces 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=48631
Bug ID: 48631
Summary: Death to Spies: Moment of Truth demo renders text as a
black squares
Product: Wine
Version: 5.2
Hardware: x86-64
URL: http://files.aspyr.com/support/DTS_Demo_Installer.zip
OS: Linux
Status: NEW
Keywords: download
Severity: minor
Priority: P2
Component: directx-d3dx9
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Created attachment 66482
--> https://bugs.winehq.org/attachment.cgi?id=66482
screenshot
Setting d3dx9_32 to 'native,builtin' helps.
--
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=51978
Bug ID: 51978
Summary: Autodesk fusion360 crashes at start: wine: Call from
000000007B01231E to unimplemented function
msvcp140.dll.?table@?$ctype@D@std@@QEBAPEBFXZ,
aborting
Product: Wine
Version: 6.19
Hardware: x86-64
URL: "https://dl.appstreaming.autodesk.com/production/insta
llers/Fusion%20360%20Admin%20Install.exe"
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: msvcp
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: Debian
Hi, as the title says
--
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=51860
Bug ID: 51860
Summary: Missing include for uid_t on musl-based systems
Product: Wine
Version: 6.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineserver
Assignee: wine-bugs(a)winehq.org
Reporter: ismael(a)iodev.co.uk
Distribution: ---
Build log:
gcc -m64 -c -o server/event.o server/event.c -Iserver -Iinclude -D__WINESRC__
-Wall -pipe -fcf-protection=none \
-fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement
-Wempty-body \
-Wignored-qualifiers -Winit-self -Wno-packed-not-aligned -Wshift-overflow=2
-Wstrict-prototypes \
-Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings
-Wpointer-arith -Wlogical-op \
-march=native -mtune=native -m64 -pipe -fPIC -ffast-math -funroll-loops -Os
In file included from server/object.h:25,
from server/thread.h:24,
from server/event.c:34:
/usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include
<sys/poll.h> to <poll.h> [-Wcpp]
1 | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^~~~~~~
In file included from server/event.c:36:
server/security.h:89:45: error: unknown type name 'uid_t'; did you mean
'luid_t'?
89 | extern const SID *security_unix_uid_to_sid( uid_t uid );
| ^~~~~
| luid_t
--
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=48950
Bug ID: 48950
Summary: NVDA requires AccessibleObjectFromPoint for mouse
tracking
Product: Wine
Version: 5.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: oleacc
Assignee: wine-bugs(a)winehq.org
Reporter: contact(a)jookia.org
Distribution: ArchLinux
In order to track the mouse pointer and read what's under the mouse NVDA tries
to get an IAccessible object using AccessibleObjectFromPoint. This fails with a
stub and mouse tracking doesn't work.
--
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=51598
Bug ID: 51598
Summary: cmd.exe crashes on "if exist" without arguments
Product: Wine
Version: 6.14
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: programs
Assignee: wine-bugs(a)winehq.org
Reporter: alexhenrie24(a)gmail.com
Distribution: ---
Created attachment 70448
--> https://bugs.winehq.org/attachment.cgi?id=70448
Example batch file
Run `wine if-exist.bat` and a crash dialog will appear.
`wine cmd /k if exist` and `wine if-exist.bat | tee /dev/null` do not open a
crash dialog, but they do print "stack overflow" and exit.
Strangely, `wine cmd /k if-exist.bat` does NOT crash.
--
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=41098
Bug ID: 41098
Summary: Descent 3 (GOG version) has problem when running with
OpenGL renderer (Nvidia proprietary drivers)
Product: Wine
Version: 1.7.55
Hardware: x86
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: hverbeet(a)gmail.com
Regression SHA1: c92451f295242110bf016facf0e80564f3643d94
Distribution: ---
The bug reported here occurs with Nvidia binary drivers 367.35, but can't
reproduce it with nouveau/mesa.
I tried the official demo version, but it just hangs with a black screen with
the OpenGL renderer (unrelated to this regression, occurs with nouveau as well
and with older Wine versions).
When OpenGL renderer is selected in the launcher, the game starts and plays the
intro video, then the game quits after displaying this error message: 'Error:
Generic renderer error."
The OpenGL renderer in Descent 3 used to work until
commit c92451f295242110bf016facf0e80564f3643d94
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Wed Nov 4 00:02:48 2015 +0100
wined3d: Always use the same formats in context_create() when
"always_offscreen" is enabled.
Disabling "AlwaysOffScreen" in the registry works around the problem.
Terminal output shows only
fixme:win:EnumDisplayDevicesW ((null),0,0x33f0d8,0x00000000), stub!
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to
16
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to
16
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to
16
Wine 1.9.16
Fedora 24
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 730/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 367.35
OpenGL core profile shading language version string: 4.50 NVIDIA
--
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=51959
Bug ID: 51959
Summary: Missing procedure GetDayLightFlag
Product: Wine
Version: 6.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ucrtbase
Assignee: wine-bugs(a)winehq.org
Reporter: deridiot(a)gmail.com
Distribution: ---
Created attachment 70942
--> https://bugs.winehq.org/attachment.cgi?id=70942
german Error Message about the missing procedure
In the build process of a python project we employ a docker image that uses
pyinstaller via wine (https://github.com/cdrx/docker-pyinstaller).
When executing the frozen exe it will raise an error noting that ucrtbase.dll
misses the procedure GetDayLightFlag
If i explicitly tell the build process to ignore ucrtbase.dll from being
included in the package it will use the dll of the system it runs on. Meaning
it doesn't employ the file supplied by wine.
I poked around the code a bit and probably we are just lacking
stdcall GetDaylightFlag()
in
https://github.com/wine-mirror/wine/blob/master/dlls/ucrtbase/ucrtbase.spec
But C isn't my language of choice so i will gladly admit that's just guessing.
I've managed to work around my problem by just excluding the dll, but i feel
this might help someone else in the future.
--
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=51864
Bug ID: 51864
Summary: VeraCrypt Installer for 1.24-Update7 (Win8+) fails
with HRESULT 0x800288BD
Product: Wine
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: oleaut32
Assignee: wine-bugs(a)winehq.org
Reporter: besentv(a)gmail.com
Distribution: ---
Created attachment 70779
--> https://bugs.winehq.org/attachment.cgi?id=70779
Veracrypt installer Winedump
Seems like the installer, a 32bit App, tries to register a 64bit TypeLib, but
it fails:
...
0100:Call oleaut32.RegisterTypeLib(00f2d118,051dd278 L"C:\\Program
Files\\VeraCrypt\\VeraCrypt.exe",00000000) ret=00403782
0100:Ret oleaut32.RegisterTypeLib() retval=800288bd ret=00403782
...
0100:Call oleaut32.RegisterTypeLib(00f2d118,051dd278 L"C:\\Program
Files\\VeraCrypt\\VeraCrypt.exe",00000000) ret=00403782
0100:Ret oleaut32.RegisterTypeLib() retval=800288bd ret=00403782
...
A quick check of the source code shows us, that wine does this on purpose:
oleaut32.typelib.c:
HRESULT WINAPI RegisterTypeLib(ITypeLib *ptlib, const WCHAR *szFullPath, const
WCHAR *szHelpDir)
{
...
#ifndef _WIN64
if (attr->syskind == SYS_WIN64) return TYPE_E_BADMODULEKIND;
#endif
...
}
Windows allows this behavior, as the installer works perfectly fine there.
--
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=52220
Bug ID: 52220
Summary: TMIDI Player, Cherry: Playback with multiple MIDI
ports is broken
Product: Wine
Version: 7.0-rc1
Hardware: x86-64
URL: https://www.vector.co.jp/soft/dl/win95/art/se038910.ht
ml
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winealsa.drv
Assignee: wine-bugs(a)winehq.org
Reporter: kakurasan(a)gmail.com
Regression SHA1: 3d57cc2863f2f9a5ace40d29317b3ff4357fd119
Distribution: ---
Created attachment 71297
--> https://bugs.winehq.org/attachment.cgi?id=71297
Sample MIDI file that uses 2 MIDI ports
When the apps are configured to use multiple MIDI ports, playback is broken if
the song (MIDI file) uses multiple MIDI ports.
Downloads:
* TMIDI Player: https://www.vector.co.jp/soft/dl/win95/art/se038910.html
* Cherry: https://www.vector.co.jp/soft/dl/win95/art/se071842.html
Steps to reproduce:
1. Install ja_JP.UTF-8 locale
2. Execute "winetricks fakejapanese_ipamona" for Japanese fonts
3. Download TMIDI Player
4. Install/run TMIDI Player on ja_JP.UTF-8 locale
5. Open menu item "オプション(O) - MIDI設定(M)" (or press Alt-o and Enter) and set
MIDI Port A and B to valid and different MIDI ports
6. Open/play the attached MIDI file
This is a regression introduced by:
commit 3d57cc2863f2f9a5ace40d29317b3ff4357fd119
Author: Jacek Konieczny <jajcus(a)jajcus.net>
Date: Wed Feb 12 12:53:54 2020 -0600
winealsa.drv: Send MIDI events to port subscribers.
This way changes to the port connections made by other applications will be
honoured.
Signed-off-by: Jacek Konieczny <jajcus(a)jajcus.net>
Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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=52173
Bug ID: 52173
Summary: kodi crashes at start: Call to unimplemented function
wsdapi.dll.WSDCreateDiscoveryProvider, aborting
Product: Wine
Version: 6.22
Hardware: x86-64
URL: https://mirrors.kodi.tv/releases/windows/win64/kodi-19
.3-Matrix-x64.exe
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: ---
Created attachment 71223
--> https://bugs.winehq.org/attachment.cgi?id=71223
patch with stub stub
As the title says. Attached stub implementation gets it around this crash.
Will send later to list
Note: Starts further fine if I do 'winetricks dxvk141' but maybe my graphics
card is too "simple', and this is not needed for other cards?
--
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=26350
Summary: Dungeons demo doesn't run
Product: Wine
Version: 1.3.15
Platform: x86
URL: http://www.bigdownload.com/games/dungeons/pc/dungeons-
demo/
OS/Version: Linux
Status: NEW
Keywords: dotnet, download
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
If I use mono-2.10-1, it fails with an error that mono can't handle it:
Method '<Module>:<CrtImplementationDetails>.DoDllLanguageSupportValidation ()'
in assembly 'C:\Program Files\Kalypso Media\Dungeons Demo\Mogre.dll' contains
native code that cannot be executed by Mono in modules loaded from byte arrays.
The assembly was probably created using C++/CLI.
Method '<Module>:<CrtImplementationDetails>.ThrowModuleLoadException
(string,System.Exception)' in assembly 'C:\Program Files\Kalypso Media\Dungeons
Demo\Mogre.dll' contains native code that cannot be executed by Mono in modules
loaded from byte arrays. The assembly was probably created using C++/CLI.
System.NullReferenceException: Object reference not set to an instance of an
object
With dotnet35, fails with:
Unhandled Exception: System.MissingMethodException: Method not found: 'Void
System.Runtime.GCSettings.set_LatencyMode(System.Runtime.GCLatencyMode)'.
at Realmforge.MogreUtil.Application.MainApplication`3.Run()
at Realmforge.Dungeons.DungeonsMain.Main(String[] args)
--
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=39699
Bug ID: 39699
Summary: WINE Crashed during setup of 'EDT for Windows'
Product: Wine
Version: 1.6-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: D.Kurtz(a)web.de
Distribution: ---
Created attachment 52941
--> https://bugs.winehq.org/attachment.cgi?id=52941
Saved Crashfile
During running the Setup-Programm WINE crashed.
I have Linux-Mint 17.2 and Wine !:1.6.2 You can get the Programm 'EDTW = EDT
für Windows' at this Link: http://opg.de/download/edtw/setupedt.exe
If possible please answer in German language because my english is very bad.
Thanks
Dietmar
--
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=52037
Bug ID: 52037
Summary: MaiDenSnow Eve trial crashes upon entering load menu
Product: Wine
Version: 6.19
Hardware: x86-64
URL: https://trial.dlsite.com/doujin/RJ116000/RJ115762_tria
l.zip
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
Distribution: ---
I'm reporting against 6.19, but IIRC this predates 6.0.
I have no proof that the problem stems from the code in win32u/gdiobj.c, as gdb
backtraces report stack being corrupted. Yet after changing the warning in
handle_entry to print handle value, I can see the handle (font) being accessed
after being freed by free_gdi_handle. Also, 'all,-heap' somehow sidesteps the
crash, for a price of a major slowdown. The crash is 'illegal instruction', so
once again, stack corruption.
To reproduce:
- run the trial
- pick the last option (fourth) in the menu
- pick 'New Game'
- go with the first option in the next menu
- as the game starts, access menu (press X) and save (first option)
- press F12 to quickly restart the game
- back at the title screen pick 'Load Game'
- ...get the crash
(if at any point you get a splash screen with some text and a clock image, you
need to press 'up,left,up,down,right' on the keyboard)
--
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=19841
Summary: Wolfenstein (2009): mouse cursor remains onscreen
during FPS gameplay even after all menus are closed.
Product: Wine
Version: 1.1.28
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ben.r.xiao(a)gmail.com
In Wolfenstein (2009), browsing the intelligence reports or upgrading weapons
sometimes causes the mouse cursor to remain on screen even when the in-game
menus are closed. In other words, during FPS gameplay, the cursor sits right
where the crosshairs should be and does not disappear. Needless to say this is
quite distracting. This cursor bug seems to appear randomly, but always after
browsing an intelligence report or upgrading weapons. The only way to get rid
of the cursor is to restart the game. I'll post an attachment showing this bug
the next time I see it.
--
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=46936
Bug ID: 46936
Summary: cannot upgrade to wine-devel 4.5~bionic (libfaudio0
dependency missing)
Product: Packaging
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: a34ypool3voiz(a)t-online.de
CC: michael(a)fds-team.de, sebastian(a)fds-team.de
Distribution: ---
Created attachment 64049
--> https://bugs.winehq.org/attachment.cgi?id=64049
log showing missing libfaudio0 deps
I have installed winehq-devel 4.4 on Ubuntu 18.04 amd64.
Currently version 4.5 is available, but installation fails.
Trying the usual "apt-get update && apt-get upgrade && apt-get dist-upgrade"
lists winehq-devel as package that has been kept back.
Then I tried the following:
sudo apt-get install winehq-devel wine-devel wine-devel-amd64 wine-devel-i386
-f
Now two unmet dependencies are listed, which cause the failure: libfaudio0 and
libfaudio0:i386.
Those packages do not exist in the repository.
--
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=50251
Bug ID: 50251
Summary: Wrong public key from the repo prevents installation.
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: kristijan.zic(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ---
Distro: Ubuntu 20.04
Followed instructions for Focal Fossa here:
https://wiki.winehq.org/Ubuntu
Got this error:
Err:10 https://dl.winehq.org/wine-builds/ubuntu focal InRelease
The following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 76F1A20FF987672F
Reading package lists... Done
W: GPG error: https://dl.winehq.org/wine-builds/ubuntu focal InRelease: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 76F1A20FF987672F
E: The repository 'https://dl.winehq.org/wine-builds/ubuntu focal InRelease' is
not signed.
N: Updating from such a repository can't be done securely, and is therefore
disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration
details.
--
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=51920
Bug ID: 51920
Summary: Official package for Arch Linux
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: joseskvolpe(a)gmail.com
CC: dimesio(a)earthlink.net
Distribution: ArchLinux
Wine has packages on the Arch Linux multilib and community repository, they're
currently maintained by Felix Yan (Wine) and Daniel Bermond (Wine-gecko &
Wine-mono)
Problem is... Sometimes there's a huge delay on these packages when they get an
update. This is not a issue only with Wine, it occurs with many other packages
that are maintained in these repositories.
Wine has just released version 6.20, but these repositories are still in
6.16... If we had a official WineHQ repository for Arch Linux distributions
like we got in Ubuntu and Debian, we could get updates for Wine much quicker.
Additionally, having git versions on the official repository would also be neat
to get nightly builds of Wine. ^w^
--
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=51849
Bug ID: 51849
Summary: Debian packaging: When building debian packages,
HARDENING flags will be passed to cross-compiler
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: cybermax(a)dexter.no
CC: dimesio(a)earthlink.net
Distribution: ---
When packages are built on debian, the default "hardening" flags will be passed
to wine/configure. The result from this is that wine/configure tries to do
checks for cross-compiler (mingw-w64) with flags meant to be used for ELF
binaries.
The flags are -Wl,-z,relro
This causes configure to fail several checks for cross-compiler.
The logs from WineHQ official OBS builds here for Debian 11:
https://build.opensuse.org/public/build/Emulators:Wine:Debian/Debian_11/x86…
Failing these checks will cause mingw-w64 to create loads of warnings like:
[ 1042s] In file included from dlls/cabinet/fdi.c:72:
[ 1042s] dlls/cabinet/fdi.c: In function 'FDI_read_string':
[ 1042s] dlls/cabinet/fdi.c:485:9: warning: format '%ld' expects argument of
type 'long int', but argument 6 has type 'INT_PTR' {aka 'long long int'}
[-Wformat=]
[ 1042s] 485 | TRACE("(fdi == %p, hf == %ld, cabsize == %ld)\n", fdi, hf,
cabsize);
[ 1042s] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~
[ 1042s] | |
[ 1042s] |
INT_PTR {aka long long int}
If you however build without passing -Wl,-z,relro to mingw-w64, configure will
pass a lot more tests, and the compile is quite a lot less noisy:
https://build.opensuse.org/build/home:SveSop/Debian_11/x86_64/wine-devel/_l…
Is there a possibility to avoid passing this flag to the cross-compiler in
wine/configure? From what i gather, the -Wl,-z,relro flag is meant for ELF
binaries, but afaik wine mostly (if not only) uses mingw-w64 to build PE libs,
and thus these flags fail.
You can add export DEB_LDFLAGS_MAINT_STRIP = -Wl,-z,relro to debian/rules, but
that ofc means the ELF binaries built by gcc will not get these hardening
flags.
--
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=50891
Bug ID: 50891
Summary: Fedora 33 repository missing wine-*-common x86_64
packages
Product: Packaging
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-packages
Assignee: wine-bugs(a)winehq.org
Reporter: blacknova(a)tut.by
CC: dimesio(a)earthlink.net
Distribution: ---
After recent update of Fedora repository, all x64_64 versions of wine-*-common
packages are missing.
DNF upgrade command complain on broken dependencies:
Problem 1: cannot install the best update candidate for package
wine-staging64-1:6.4-1.1.x86_64
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_64
Problem 2: package winehq-staging-1:6.5-1.2.x86_64 requires wine-staging64 =
1:6.5-1.2, but none of the providers can be installed
- cannot install the best update candidate for package
winehq-staging-1:6.4-1.1.x86_64
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_64
Problem 3: problem with installed package wine-staging64-1:6.4-1.1.x86_64
- package wine-staging64-1:6.4-1.1.x86_64 requires wine-staging-common =
1:6.4-1.1, but none of the providers can be installed
- cannot install both wine-staging-common-1:6.5-2.1.i686 and
wine-staging-common-1:6.4-1.1.i686
- cannot install the best update candidate for package
wine-staging-common-1:6.4-1.1.i686
- nothing provides wine-staging-common = 1:6.5-1.2 needed by
wine-staging64-1:6.5-1.2.x86_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=51354
Bug ID: 51354
Summary: WRC 7 needs ID3DUserDefinedAnnotation interface
Product: Wine
Version: 6.11
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
Shows WRC 7 window and immediately closes.
0110:trace:d3d11:d3d11_device_context_QueryInterface iface 00000000001E31E8,
iid {b2daad8b-03d4-4dbf-95eb-32ab4b63d0ab}, out 00000000026DA770.
0110:warn:d3d11:d3d11_device_context_QueryInterface
{b2daad8b-03d4-4dbf-95eb-32ab4b63d0ab} not implemented, returning
E_NOINTERFACE.
wine-6.11-158-g542175ab104
--
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=46615
Bug ID: 46615
Summary: PC Building Simulator doesn't render fonts
Product: Wine
Version: 4.1
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: luca.finizio.mgbx(a)hotmail.it
Distribution: Mint
I tried to play PC Building Simulator v9.3.4 but it's impossible to play the
game because fonts are not rendered. I attached my console output (there are
also errors).
--
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=44950
Bug ID: 44950
Summary: err:ntdll:RtlpWaitForCriticalSection. Supreme
Commander FA
Product: Wine
Version: 3.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: james.ytedmonds(a)gmail.com
Distribution: ---
This bug has affected Supreme Commander: Forged Alliance since pre-2.21. I have
found this bug to affect multiple machines with clean wine prefixes.
At some point during gameplay, the game will either stop entirely or the window
for it will close. The terminal reads:
"
007f:fixme:faultrep:ReportFault 0x153ece4 0x0 stub
0110:err:ntdll:RtlpWaitForCriticalSection section 0xfeec00 "?" wait timed out
in thread 0110, blocked by 007f, retrying (60 sec)
"
The only option after this point is to kill the applications.
I have found several things that seem to make the bug more likely:
*Playing on large maps (definite correlation)
*Using 6+ players (less certain)
*High graphics settings (might affect timing of bug, but AFAIK cannot cause it)
I have tried to override the "ntdll.dll" with one from real windows, but I
believe wine at this time does not support overriding this DLL.
The bug is easy to reproduce, on a large map (i.e. "Betrayal Ocean") it can
occur within 5-10 minutes.
I can get any details and logs needed, but I will need to be told how to get
them (I am not experienced with debugging)
--
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=48847
Bug ID: 48847
Summary: dotnet471: often gets a critical section timeout
Product: Wine
Version: 5.5
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: ---
Created attachment 66764
--> https://bugs.winehq.org/attachment.cgi?id=66764
bt all
I've been seeing this when running winetricks-test, for dotnet46* and
dotnet471. This info is for dotnet471.
austin@laptop ~ $ grep 'wait timed out' /tmp/out.txt | sort -u
0048:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 0048, blocked by 006e, retrying (60
sec)
006e:err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main
process heap section" wait timed out in thread 006e, blocked by 0174, retrying
(60 sec)
00ad:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 00ad, blocked by 006e, retrying (60
sec)
00bb:err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main
process heap section" wait timed out in thread 00bb, blocked by 0174, retrying
(60 sec)
00e2:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 00e2, blocked by 006e, retrying (60
sec)
0114:err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main
process heap section" wait timed out in thread 0114, blocked by 0174, retrying
(60 sec)
0166:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 0166, blocked by 006e, retrying (60
sec)
0169:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 0169, blocked by 006e, retrying (60
sec)
016c:err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main
process heap section" wait timed out in thread 016c, blocked by 0174, retrying
(60 sec)
0193:err:ntdll:RtlpWaitForCriticalSection section 0x7bd2c220 "loader.c:
loader_section" wait timed out in thread 0193, blocked by 006e, retrying (60
sec)
winedbg bt all is 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=50629
Bug ID: 50629
Summary: Old links on https://www.winehq.org/forums
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jkfloris(a)dds.nl
Distribution: ---
Two old links on https://www.winehq.org/forums
1.
"Users might also want to visit the Wine area at Linux Forums"
has a link to http://www.linuxforums.org/forum/wine/linuxforums.org is offline since May 2020
2.
The wine-tests-results(a)winehq.org mailing list isn't used.
--
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=39379
Bug ID: 39379
Summary: test.winehq.org: Show a specific test history for a
machine or platform
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Currently it's possible to see at a glance how specific test fared across Wine
commits and *all platforms*. For instance:
https://test.winehq.org/data/tests/advapi32:service.html
But if a platform has multiple test machines, one where the test has always
failed and another where it has just started failing, one cannot see when the
failures started on the above page.
So it would be nice to have a similar page on a per-platform basis; or one with
all the reports where that test failed regardless of platform.
--
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=48164
Bug ID: 48164
Summary: test.winehq.org should provide an efficient way to
detect new failures
Product: WineHQ.org
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Problem
-------
test.winehq.org does not allow performing the following tasks efficiently:
1. Detecting when a new failure slips past the TestBot.
One can detect new failures on the per test unit page when specific columns
turn red. But quite often the test unit already has failures so one has to look
at the specific number of failures. Furthermore many test units currently have
failures so this requires checking 80+ pages individually.
2. Detecting when the results on a VM degrade.
After upgrading a machine it's useful to compare it to its previous results.
But the results for each date are on separate pages. So again it's necessary
to check the per-test-unit result pages.
3. Comparing the results of two machines of different platforms.
For instance comparing the results of running Windows 8 to those of
Windows 10 on the same hardware.
Other things that got asked:
4. Sometimes it would be nice to have only the failures, and not all the lines
with skipped tests and todos.
5. In some cases it would also be nice to have pages with only the failures
that happen on TesBot VMs since these are usually easier to reproduce.
Jeremy's page
-------------
Jeremy's test summary page can help with some of that:
https://www.winehq.org/~jwhite/latest.html
But:
* It's not integrated with test.winehq.org which makes it hard to find.
* There are only two states: Success and Failed: So it does not help when a
test goes from having 2 failures to 4, or when it has a set of systematic
failures and a set of intermittent ones.
* The failed / success pattern is not per VM which masks some patterns and does
not help with point 2.
Proposal
--------
A modified version of Jeremy's page could be integrated with test.wnehq.org:
* It would actually be a pair of 'Failures' pages, one for TestBot VMs and one
for all test results. Both would be linked to from the top of the main index
page, for instance using the same type of 'prev | next' text links used on the
other pages.
* Jeremy's result matrix would be extended from three to four dimensions; test
units, test results, time, and number/type of failures.
* As before the results would be grouped per test unit in alphabetical order.
Only the test units having at least one error, recent or not, would be shown.
This could again be in the form of an array ('full report' pages on
test.winehq.org) or simply test unit titles (TestBot jobDetails page style)
with the information about each test unit inside. Clicking on the test unit
name would link to its 'test runs' page on test.winehq.org.
* For each test unit there would be one line per test result having errors. The
first part of the line would have one character per commit for the whole
history available on test.winehq.org. That character would indicate if the test
failed and more.
The second part of the line would be the test result platform and tag. They
would be sorted per platform and alphabetically.
* Each test result would get a one character code:
. Success
F Failure
C Crash
T Timeout
m Missing dll (foo=missing or other error code)
e Other dll error (foo=load error 1359 and equivalent)
_ No test (the test did not exist)
' ' No result (the machine did not run the tests that day)
* These codes would be shown using a monospace font so they would form a
pattern across time and test results:
.....F..F...F..F.mmm Win8 vm1
.....FFFFeFFFFFFeFFF Win8 vm1-ja
...TTCC Win8 vm2-new
......eF...F...F..F. Win10 vm3
* Each character would have a tooltip containing details like the meaning of
the letter, the number of failures, or the dll error message.
They would also link to the corresponding section of the test report.
* In addition to the character the background would be color coded to make
patterns more visible.
. Green
F Green to yellow to red gradient
C Dark red
T Purple/pink
m Cyan
e Dark blue
_ Light gray
' ' White
* The green-yellow-red gradient would be what allows detecting changes in the
number of test failures. That gradient must be consistent for all lines of a
given test unit's pattern.
Furthermore the gradient must not be computed based on the test result's
number of failures. That is, if a test unit has either 100 or 101 failures,
those must not have nearly indistinguishable colors. Instead the set of all
different failure counts for the test unit should be collected. Zero should be
added to that set. Then these values should be sorted and a color attributed
for each *index*. Then the background color is selected based on the index of
that result's failures count.
It is expected that each set will be relatively small so that the colors will
be reasonably far apart, making it easy to distinguish a shift from 4 to 6
failures even if there are 100 failures from time to time.
Also note hat adding zero to the set essentially reserves green for
successful results.
Implementation feasibility
--------------------------
* No changes in dissect.
* In gather, generate a new testunits.txt file containing one line per test
unit:
- The data source would be the per-report summary.txt files.
-> These don't indicate when a timeout has occurred so timeouts will appear
as F instead which is acceptable for a first implementation.
- The first line would contain a star followed by the tags of all the test
runs used to build the file:
- The other lines would contain the name of the test unit followed by
space-separated pairs of result code/failure count and result tag (including
the platform).
- A line would be put out even if the test unit had no failure.
For instance, the commit1 testunit.txt file could contain:
* win8_vm1 win8_vm1-ja win8_vm2-new win10_vm3
foo:bar 43 win8_vm1-ja C win8_vm2-new e win10_vm3
foo:bar2
- In the example above win8_vm1 only appears on the first line. This means
WineTest was run on that machine but had no failure at all.
- If the results for commit2 refer to a win8_vm4 machine, we will know that
the reason win8_vm4 does not appear in commit1 file is not because all the
tests succeeded, but because WineTest was not run on win8_vm4 for commit1. This
means that the result code for win8_vm4 for commit1 should be ' '. not '.' for
all test units.
- If commit2 has results for the foo:bar3 test unit, then we will know the
reason it is not present in the commit1 file is not because all the test runs
were successful, but because foo:bar3 did not exist yet. So its result code
would be '_', not '.'.
* Add a new build-failures script to generate both failures pages.
- This script will need to read the testunits.txt file for all the commits.
The simplest implementation will be to read all the data into memory before
generating the page. This will avoid having to deal with keeping the current
test unit synchronized between all of the testunits.txt files when a new test
unit has been added.
- The combined size of the testunits.txt files is expected to be reasonable,
within a factor of 3 of the summary.txt files. For reference, here is some data
about the sizes involved:
$ du -sh data
21G data
$ ls data/*/*/report | wc -l
2299
$ cat data/*/*/report | wc
34,087,987 231,694,407 2,104,860,095
$ cat data/*/*/report | egrep '(: Test failed:|: Test succeeded inside todo
block:|done [(]258)|Unhandled exception:)' | wc
567,158 6,275,504 53,202,999
$ cat data/*/summary.txt | wc
186,219 3,046,363 30,596,901
- Having a function to generate the page will allow calling it twice in a row
to generate both pages without having to load and parse the testunits.txt files
twice.
--
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=51352
Bug ID: 51352
Summary: test.winehq.org should distinguish "too much data"
errors from others
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The new patterns page treats the "test printed too much data" failures like any
other. It would be better to use another symbol and color when there is no
other 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=52088
Bug ID: 52088
Summary: Update favicon to 32X32
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: 2ndforwine(a)inmano.com
Distribution: ---
The 16x16 looks very blurry when compared to other web-sites.
--
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=50630
Bug ID: 50630
Summary: Old link on https://www.winehq.org/news
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jkfloris(a)dds.nl
Distribution: ---
At the bottom of the page there is a link to
World Wine News Archive - https://www.winehq.org/wwn
The last "news" item is from 2017.
Maybe it is an idea to remove this link.
--
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=50516
Bug ID: 50516
Summary: Broken link
'https://wiki.winehq.org/Useful_Registry_Keys'
Product: WineHQ.org
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: www-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jose.relland(a)free.fr
Distribution: ---
Hi, thank you for your time.
I noted that the linnk:
"Wine Man Page" (at the bottom of the page) is broken.
Send to 404 page error.
Best 2021 year :)
José from France
--
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.