http://bugs.winehq.org/show_bug.cgi?id=34178
Bug #: 34178
Summary: MiKTeX 2.9 (32-bit) fails to install
Product: Wine
Version: 1.6
Platform: x86-64
URL: http://miktex.org/download
OS/Version: Linux
Status: NEW
Keywords: download, Installer, source
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: austinenglish(a)gmail.com
Blocks: 34172
Classification: Unclassified
Noticed this while looking at bug 34172. I tried the 32-bit version, and get a
separate, but potentially related issue.
Download the installer from http://miktex.org/download
Install as normal. Eventually it gives an error during install:
==========
The operation could not be completed for the following reason:
The operation failed for some reason.
Details: C:\Program Files\MiKTeX 2.90\miktex/bin\initexmf.exe
==========
austin@aw25 ~ $ sha1sum basic-miktex-2.9.4813.exe
e8647f57fe866c00119ca8938785cacfaa5ca826 basic-miktex-2.9.4813.exe
austin@aw25 ~ $ du -h basic-miktex-2.9.4813.exe
155M basic-miktex-2.9.4813.exe
wine-1.6-178-g7944ca4
--
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=41647
Bug ID: 41647
Summary: TFM Music Maker controls are not usable
Product: Wine
Version: 1.9.22
Hardware: x86
URL: http://sega4ever.power-heberg.com/Download/tfmmaker152
.rar
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: notasas(a)gmail.com
Distribution: ---
After starting the program, click "Instruments" tab and try to adjust any of
the knobs. Nothing useful noticed in the terminal output. Just a guess it's an
issue message handling, so selected user32 component.
Tested to be broken on vanilla wine-1.9.22, wine-1.9.22 (Staging) and
wine-1.6.2. Works correctly on real Windows 7 and 8.1.
--
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=33326
Bug #: 33326
Summary: Sound problem with Game Maker 8.0 games
Product: Wine
Version: 1.5.27
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: georgiev_1994(a)abv.bg
Classification: Unclassified
When Im starting a game created from Game Maker 8.0 Po it's sound does not
start. This is happening with every game Im trying to run. This is caused maybe
because of the sound system of Game Maker built games. Here I will give a link
just to one game which runs just perfect with Windows OS but not perfect at all
with Wine.
http://sandbox.yoyogames.com/games/205913/download
--
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=55133
Bug ID: 55133
Summary: Shoujo-tachi wa Kouya o Mezasu: crashes on new game
Product: Wine
Version: 8.10
Hardware: x86-64
URL: http://minatosoft.com/koya/download/
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: pernegger(a)gmail.com
Distribution: ---
Created attachment 74688
--> https://bugs.winehq.org/attachment.cgi?id=74688
wine 8.10 terminal output
Note: The trial version is free to download, see URL. Any of the mirrors /
DOWNLOAD links will do. No need t install, just run from the low-level
directory.
The game will crash at a black screen immediately after selecting new game from
the main menu. Even if I ctrl-c the process on the terminal, getting rid of the
game window requires wineserver -k.
Different WINE versions and/or using DXVK may result in different log output
and symptoms (i.e. hang instead of crash).
Since I've no idea where to start I was hoping someone who does could have a
quick look at this, narrow it down a bit at least.
--
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=40119
Bug ID: 40119
Summary: Irfanview 4.x: selection cursor is not correctly
aligned
Product: Wine
Version: 1.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: Ulf.Zibis(a)gmx.de
Distribution: ---
- select an area in an image
- correct the selection by dragging the left selection border to another
position
--> the double-ended arrow cursor ofen is not correctly aligned with the
selection border
I guess this happens, when the image is zoomed.
--
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=55129
Bug ID: 55129
Summary: Boost throws c++ exception when creating shared memory
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: dlehman25(a)gmail.com
Distribution: ---
Created attachment 74681
--> https://bugs.winehq.org/attachment.cgi?id=74681
simple c++ repro case
boost uses 2 methods to fetch the boot time to build a path for shared memory.
code path is chosen with a #define
the 2 methods are:
- registry key (default):
- BootId and optionally additionally HybridBootAnimationTime
-
https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in…
- creates a path like: C:/ProgramData/boost_interprocess/01000000/crash
- Eventlog
- fetches record for event log start
-
https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in…
- creates a path like: C:/ProgramData/boost_interprocess/1687093260/crash
- the event log timestamp is always moments after boot on physical and
virtual machines i have access to, although many testbot vms seem to have boot
records after the event log start
- not sure what the 24 bytes at DataOffset are
- seems like overkill to fully implement the event log feature, which
generally doesn't seem useful on wine, just for this case
it throws a c++ exception if either method fails
https://github.com/boostorg/interprocess/blob/boost-1.82.0/include/boost/in…
pull request to follow
--
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=55038
Bug ID: 55038
Summary: Please add trixie Debian release to Wine repos
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: shtetldik(a)gmail.com
Distribution: ---
Please add trixie distro to the Debian repos for Wine, since Debian trixie was
just released.
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=55125
Bug ID: 55125
Summary: The 64-bit dinput:hotplug sometimes gets timeouts on
Windows 10
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: dinput
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
The 64-bit dinput:hotplug sometimes gets timeouts on Windows 10 :
hid.c:725: Test failed: 0x800: WaitForSingleObject returned 0x102
or
hid.c:725: Test failed: WaitForSingleObject returned 0x102
and/or
hotplug.c:400: Test failed: MsgWaitForMultipleObjects returned 0x102
See https://test.winehq.org/data/patterns.html#dinput:hotplug
Where 0x102 == WAIT_TIMEOUT
These failures only happen on w1064-tsign which is a test configuration with
test signing enabled. Furthermore only the 64-bit version has these issues.
The oldest instance goes back to 2022-12-20 and these failures have happened
almost 3 times per month since.
--
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=53682
Bug ID: 53682
Summary: wineboot shows "user_check_not_lock BUG: holding USER
lock" on aarch64 since wine-7.14
Product: Wine
Version: 7.14
Hardware: aarch64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: PuetzKevinA(a)JohnDeere.com
Distribution: ---
I recently updated our builds to past wine-7.0, and began encountering a
wineboot failure on aarch64
> 0040:err:system:user_check_not_lock BUG: holding USER lock(64)
> s\system32\rundll32.exe: /home/yukondev/workspace/wine/dlls/win32u/sysparams.c:400: user_check_not_lock: Assertion `0' failed.
> 0040:err:seh:call_function_handlers invalid frame 21f410 (0000000000022000-0000000000120000)
> 0040:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
After some bisecting, I narrowed this down to being a regression between 7.13
and 7.14, and then further narrowed it to
https://source.winehq.org/git/wine.git/commit/d50112b4b6e82782d3924a8dbd443…
Somehow the call to KeUserModeCallback( NtUserLoadSysMenu,... ) at
https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…
does not properly return.
I think that commit is mostly a false lead though, the translation of syscall
NtUserCreateWindowEx to a syscall just exposed a latent bug in
KeUserModeCallback/__wine_syscall_dispatcher on aarch64, since having
NtUserCreateWindowEx be a syscall means KeUserModeCallback can no longer use
its "if we have no syscall frame, call the callback directly" simple path
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar…
What seems to be actually at fault is that, inside of User32LoadSysMenu (the
actual function invoked by KeUserModeCallback), is a call to NtUserCreateMenu -
which is *also* a syscall. This call doesn't crash, and in fact all of
User32LoadSysMenu runs to completion. But when it goes through
__wine_syscall_dispatcher, the stack pointer is restored to be `$sp =
arm64_thread_data()->syscall_frame`
https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/unix/signal_ar…
- i.e. it points to &callback_frame, back on the stack of KeUserModeCallback.
And this is *not* the bottom of the stack; there's compiler-generated
prologue/epilogue to restore various non-volatile registers.
0x0000ffffaa0247b4 <KeUserModeCallback+0>: sub sp, sp, #0x450
0x0000ffffaa0247b8 <KeUserModeCallback+4>: stp x29, x30, [sp]
0x0000ffffaa0247bc <KeUserModeCallback+8>: mov x29, sp
0x0000ffffaa0247c0 <KeUserModeCallback+12>: stp x19, x20, [sp, #16]
0x0000ffffaa0247c4 <KeUserModeCallback+16>: stp x21, x22, [sp, #32]
0x0000ffffaa0247c8 <KeUserModeCallback+20>: str w0, [sp, #56]
0x0000ffffaa0247cc <KeUserModeCallback+24>: str x1, [sp, #48]
0x0000ffffaa0247d0 <KeUserModeCallback+28>: str w2, [sp, #60]
0x0000ffffaa0247d4 <KeUserModeCallback+32>: mov x21, x3
0x0000ffffaa0247d8 <KeUserModeCallback+36>: mov x20, x4
0x0000ffffaa0247dc <KeUserModeCallback+40>: add x19, sp, #0x40 //
x19=&callback_frame
So any code that runs inside this syscall that uses the first 0x40 bytes of
stack is trampling these variables in the frame of KeUserModeCallback.
Eventually User32LoadSysMenu returns back into KiUserCallbackDispatcher, which
passes it into NtCallbackReturn, which does a __wine_longjmp back into the
KeUserModeCallback,and we exit from the __wine_setjmp for the second time
(returning 0) and get to `return callback_frame.status`
https://gitlab.winehq.org/wine/wine/-/blob/wine-7.17/dlls/ntdll/unix/signal….
But then the epilogue starts peeling off the stack
=> 0x0000ffffaa024864 <+176>: ldr w0, [sp, #1088]
0x0000ffffaa024868 <+180>: ldp x19, x20, [sp, #16]
0x0000ffffaa02486c <+184>: ldp x21, x22, [sp, #32]
0x0000ffffaa024870 <+188>: ldp x29, x30, [sp]
0x0000ffffaa024874 <+192>: add sp, sp, #0x450
0x0000ffffaa024878 <+196>: ret
and the link register $x30 = (void *) 0xffffaa024984 <NtCallbackReturn+104>,
rather than 0xffffa8f0ccdc <copy_sys_popup+44> as it was when it was pushed in
the prologue.
It's overwritten several times along the way, but I don't think any of these
call sites are at fault; they are just writing to what they think is their own
stack frame, unaware that __wine_syscall_dispatcher adjusted $sp to too-high a
value and they are overwriting space that belongs to KeUserModeCallback.
The specific places that overwrote this entry on the stack were
#0 0x0000ffffa8f37a48 in NtUserCallOneParam (arg=0, code=2) at
/home/yukondev/workspace/wine/dlls/win32u/sysparams.c:5357
#1 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to 0xffffaa022cf0 <__wine_syscall_dispatcher+272>
#0 insert_menu_item (ret_pos=0x21f538, flags=1024, id=4294967295,
handle=0x10042) at /home/yukondev/workspace/wine/dlls/win32u/menu.c:438
#1 NtUserThunkedMenuItemInfo (handle=0x10042, pos=4294967295, flags=1024,
method=1, info=0x11f528 <opengl_func_names+680>, str=<optimized out>) at
/home/yukondev/workspace/wine/dlls/win32u/menu.c:1297
#2 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to NULL
and
0x0000ffffaa023a0c in NtCurrentTeb () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449
1449 {
(gdb) bt
#0 0x0000ffffaa023a0c in NtCurrentTeb () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:1449
#1 0x0000ffffaa02493c in ntdll_get_thread_data () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/unix_private.h:70
#2 arm64_thread_data () at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:163
#3 NtCallbackReturn (ret_ptr=0x0, ret_len=0, status=65602) at
/home/yukondev/workspace/wine/dlls/ntdll/unix/signal_arm64.c:784
#4 0x0000ffffaa022cf0 in __wine_syscall_dispatcher () from
/opt/wine/bin/../lib/wine/aarch64-unix/ntdll.so
which set it to 0xffffaa02493c <NtCallbackReturn+32>, and then 0xffffaa024978
<NtCallbackReturn+92>
, then 0xffffaa024984 <NtCallbackReturn+104>
The same sort of thing happens in the x86_64 dispatcher, but there it turns out
to be pretty harmless. The key difference is that the function prologue on
x86_64 used `push` instructions, and did so prior to the `sub` where it
allocated space for locals, so the things popped by the epilogue ended up above
callback_frame, rather than below it, and so are not smashed.
0x00007fd17b6dc1d2 <+0>: push %rbp
0x00007fd17b6dc1d3 <+1>: mov %rsp,%rbp
0x00007fd17b6dc1d6 <+4>: push %r14
0x00007fd17b6dc1d8 <+6>: push %r13
0x00007fd17b6dc1da <+8>: push %r12
0x00007fd17b6dc1dc <+10>: push %rdi
0x00007fd17b6dc1dd <+11>: push %rsi
0x00007fd17b6dc1de <+12>: push %rbx
0x00007fd17b6dc1df <+13>: sub $0xa0,%rsp
0x00007fd17b6dc1e6 <+20>: and $0xffffffffffffffc0,%rsp
0x00007fd17b6dc1ea <+24>: sub $0x560,%rsp
There is still a 32-byte gap between the $rsp of KeUserModeCallback and
¤t_frame that is briefly at risk, but
1. This seems to be the register parameter area of the Windows x64 ABI, which
is actually volatile space that belongs to the callee even though it's
allocated by the caller, so the compiler is not expecting it to survive across
function calls (in this case __wine_syscall_dispatcher_return).
https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170 discusses
how this "contains at least 4 entries", i.e. 32 bytes:
https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64
2. It doesn't actually get smashed, because __wine_syscall_dispatcher subtracts
0x20 from the restored $rsp before actually making the syscall
(https://gitlab.winehq.org/wine/wine/-/blob/d50112b4b6e82782d3924a8dbd443f82…).
Which is presumably since the SysV ABI does *not* make any such reservation,
and so __wine_syscall_dispatcher needs to do so to be following the ms_abi.
So together, these mean that on x86_64, it would be OK if
__wine_syscall_dispatcher used these 32 bytes between the correct $rsp of
KeUserModeCallback and frame->syscall_table (though it doesn't seem to). And
the eventual callee gets a $rsp that does *not* overlap with KeUserModeCallback
(even though it would be legal for it to do so). I don't know that we have any
actual guarantee that callback_frame will be at the bottom, but in practice it
seems to be.
But on aarch64, there's important stuff below callback_frame, so this doesn't
work out.
--
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=55016
Bug ID: 55016
Summary: xaudio2_8:xaudio2 - test_simple_streaming() crashes on
Windows 8+
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_8:xaudio2 - test_simple_streaming() crashes on Windows 8+:
xaudio2.c:339: Test failed: Got hr 0x80004002.
xaudio2.c:339: this is the last test seen before the exception
13dc:xaudio2: unhandled exception c0000005 at 00402D6A
See https://test.winehq.org/data/patterns.html#xaudio2_8:xaudio2
A bisect shows that the failures started with this commit:
commit 14c44d0b0a2fc0ead5bc75615864ff850a44c4d5
Author: Zebediah Figura <zfigura(a)codeweavers.com>
Date: Mon Apr 24 16:59:08 2023 -0500
xaudio2: Use the preprocessor to modify definitions in xaudio2.idl and
xaudio2fx.idl.
Instead of including the IDLs directly, define a local IDL that #includes
them,
with XAUDIO2_VER defined, and include that generated header.
Get rid of compat.c, and use XAUDIO2_VER to modify the code in the other
source
files.
Build the tests for both xaudio2_7 and xaudio2_8 using PARENTSRC, and use
XAUDIO2_VER to select between them. This mirrors the approach taken for
d3dcompiler, and makes it easier to test more xaudio2 versions 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=55013
Bug ID: 55013
Summary: user32:monitor - test_EnumDisplayMonitors() sometimes
fails on Linux
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
user32:monitor - test_EnumDisplayMonitors() sometimes fails on Linux:
monitor.c:1613: Test failed: SetThreadDesktop failed, error 0xaa.
monitor.c:1614: Test failed: Expected 00000014, got 00000140.
See https://test.winehq.org/data/patterns.html#user32:monitor
A bisect shows that the failures started with the commit below:
commit 5bdbbee6f4a874159f2e527f39f071547c513ee4
Author: Rémi Bernon <rbernon(a)codeweavers.com>
AuthorDate: Fri May 26 19:50:57 2023 +0200
winex11: Rely on win32u to reset clipping on display mode change.
--
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=54980
Bug ID: 54980
Summary: Times font missing in font list (several programs)
Product: Wine
Version: 8.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineps.drv
Assignee: wine-bugs(a)winehq.org
Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de
Distribution: ---
After this commit, the font "Times" (one of the Postscript base fonts) is
missing:
a6cb10bba2d05ceca6ba5b1411c450d38defdbb4 is the first bad commit
commit a6cb10bba2d05ceca6ba5b1411c450d38defdbb4
Author: Piotr Caban <piotr(a)codeweavers.com>
Date: Mon May 15 17:34:23 2023 +0200
wineps: Don't pass PRINTERINFO structure to unixlib.
dlls/wineps.drv/init.c | 5 +-
dlls/wineps.drv/unixlib.c | 310 +++++-----------------------------------------
dlls/wineps.drv/unixlib.h | 5 +-
3 files changed, 35 insertions(+), 285 deletions(-)
This happens in several programs (Framemaker 8, Office 2007).
The result is, that in documents which use this font it is replaced (in most
cases by "Times New Roman") but this does not work always and not good for font
variants like "Times Bold".
--
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=54442
Bug ID: 54442
Summary: experimental wow64 mode: doesn't show some graphical
windows
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: idarktemplar(a)mail.ru
Distribution: ---
Created attachment 73990
--> https://bugs.winehq.org/attachment.cgi?id=73990
SteamSetup.png
When I'm building wine with new experimental wow64 mode, it is unable to
properly show or render application windows for some applications.
I've tried it both on clean prefix and on existing prefix.
I've tried Steam setup and Battle.net setup, both failed. With Battle.net setup
I see no window, with Steam setup I see black window with some artifacts.
When using multilib wine built old way, everything works as usual.
Happens both with wine 8.0 and 8.1.
OS: Gentoo Linux amd64 (64bit)
Graphics: X11
Videocard information:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro K1000M/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 470.161.03
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
Wine build options: ./configure --with-mingw --enable-archs='i386,x86_64'
--prefix=/tmp/wineinstall
Default wine output:
$ WINEPREFIX=/tmp/wineprefix/prefix1 /tmp/wineinstall/bin/wine
/tmp/SteamSetup.exe
0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0080:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0090:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back
to RandR 1.0. Please consider using the Nouveau driver instead.
0034:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back
to RandR 1.0. Please consider using the Nouveau driver instead.
010c:err:environ:init_peb starting L"Z:\\tmp\\SteamSetup.exe" in experimental
wow64 mode
010c:err:winediag:is_broken_driver Broken NVIDIA RandR detected, falling back
to RandR 1.0. Please consider using the Nouveau driver instead.
010c:fixme:imm:ImeSetActiveContext (00020046, 1): stub
010c:fixme:imm:ImmReleaseContext (00010052, 00020046): stub
0090:fixme:imm:ImeSetActiveContext (0000000000010026, 0): stub
0090:fixme:imm:ImmReleaseContext (0000000000010020, 0000000000010026): stub
--
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=54848
Bug ID: 54848
Summary: dnsapi:query - test_DnsQuery() fails on Rémi's Wine
test machines
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: dnsapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
dnsapi:query - test_DnsQuery() fails on Rémi's Wine test machines:
query.c:66: Test failed: expected record name L"winehq.org", got L"."
query.c:67: Test failed: expected record type 1, got 41
query.c:96: Test failed: unexpected CNAME chain
See https://test.winehq.org/data/patterns.html#dnsapi:query
test_DnsQuery() also has failures on the TestBot's VMs (see bug 54847) but the
failures on Rémi's machines are different and not easily explained by the CDN
used by winehq.org. They may instead be caused by the cloud environment these
machines are running on.
These failures happen in new tests that were introduced by this commit:
commit 6e2efe54f17e72415b790edf6c9c1f9de5acb9f7
Author: François Gouget <fgouget(a)codeweavers.com>
Date: Thu Apr 13 05:51:20 2023 +0200
dnsapi/tests: Test how DnsQuery() handles CNAMEs.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54819
--
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=54797
Bug ID: 54797
Summary: Lunar Magic 3.33: Crashes with BadWindow unless
WINEDEBUG=+all
Product: Wine
Version: 8.5
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xhsdf.misc(a)googlemail.com
Distribution: ---
Created attachment 74294
--> https://bugs.winehq.org/attachment.cgi?id=74294
warn+all output
Starting with Wine 8.4 Lunar Magic crashes on startup with
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 12 (X_ConfigureWindow)
Resource id in failed request: 0x60001e8
Serial number of failed request: 600
Current serial number in output stream: 601
It works when WINEDEBUG=+all or trace+all is used, but then it runs very, very
slowly.
Lunar Magic can be found here:
https://fusoya.eludevisibility.org/lm/program.html
I'm using up-to-date Archlinux on a Ryzen 7 5700X and Radeon RX 6650 XT running
Openbox.
--
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=54751
Bug ID: 54751
Summary: The 64-bit advapi32:registry breaks
test_CoGetPSClsid() in ole32:compobj in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ole32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The 64-bit advapi32:registry breaks test_CoGetPSClsid() in ole32:compobj in
Wine:
compobj.c:1449: Test failed: CoGetPSClsid failed with error 0x80040155
compobj.c:1450: Test failed: got clsid {52222222-1234-1234-1234-56789abcdef0}
See https://test.winehq.org/data/patterns.html#ole32:compobj
A bisect shows that this started with the commit below:
commit 3f82f6ff59f4024f67e2d646883cbea223fba84a
Author: Sven Baars <sbaars(a)codeweavers.com>
Date: Fri Mar 17 16:52:51 2023 +0100
kernelbase: Use open_key() to obtain any existing Wow6432node in
create_key().
--
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=54738
Bug ID: 54738
Summary: msi:action - The 64-bit test_register_class_info()
fails in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
msi:action - The 64-bit test_register_class_info() fails in Wine:
action.c:6025: Test failed: key not created
action.c:6147: Test failed: key not created
See https://test.winehq.org/data/patterns.html#msi:action
--
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=48811
Bug ID: 48811
Summary: StarCraft II fails to load in staging, crashes after
trying to start a game in stable
Product: Wine
Version: 5.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dbghelp
Assignee: wine-bugs(a)winehq.org
Reporter: wschmrdr(a)gmail.com
Distribution: ---
Created attachment 66725
--> https://bugs.winehq.org/attachment.cgi?id=66725
Output occurring when the application crashes.
Ever since upgrading from 5.3 to 5.4, StarCraft II has ceased working. On
staging, this occurs during the loading screen. I am able to get through the
Battle.net app OK, but cannot get to my login authenticating. I have tried
switching to stable, but when trying to load up a game, I see the same output
issue. Selected the dbghelp component because that's the line that comes up in
the output at the time of the 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=55088
Bug ID: 55088
Summary: Program crashes when Common Dialog File open function
is called
Product: Wine
Version: 6.0.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: schicktmireurescheisse(a)gmail.com
Distribution: ---
Created attachment 74644
--> https://bugs.winehq.org/attachment.cgi?id=74644
This is the contents of the error message when the program crashes.
When the open file button (the blue button with the folder icon in the upper
left corner) of "Entgenderer" is clicked, the software instantly crashes. The
program does not get as far to display the open file common dialog. Actually,
the program is expected to show the file open dialog in order to enable the
user to select a text file.
The program was written by me. It is a 16 Bit NE binary (therefore, it actually
does not use the comdlg32 DLL, but probably its predecessor - but this category
fitted best). The sample program can be retrieved via the link
https://github.com/Waldwatz/Wine-reveals-the-truth/releases/ and then the
Entgenderer2.zip file has to be downloaded.
The terminal output after the program has crashed is:
wine: Unhandled page fault on read access to FFFFFFFF at address 00003FD6
(thread 0104), starting debugger...
--
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=55055
Bug ID: 55055
Summary: Japanese IME fails to clear composition string when
deleting the only remaining character
Product: Wine
Version: 8.10
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: imm32
Assignee: wine-bugs(a)winehq.org
Reporter: achurch+wine(a)achurch.org
Distribution: ---
Created attachment 74617
--> https://bugs.winehq.org/attachment.cgi?id=74617
PoC patch
Environment: Linux, LANG=ja_JP.UTF-8, ATOK X3 (XIM)
Since Wine 8.9 (and possibly 8.8, but not in 8.7), if XIM input results in a
composition string being reduced to zero length, the previous composition
string remains displayed until further input. For example, using Japanese:
1) Press 'A' -> composition string "あ" -> program displays "あ"
2) Press backspace -> composition string empty -> program still displays "あ"
3) Press 'I' -> composition string "I" -> program displays "い"
In step 2, the program should no longer display a composition string, but the
"あ" from step 1 remains displayed until further input in step 3 (at which point
the displayed composition string is correct again).
I first observed this in Final Fantasy XIV, but it reproduces in Notepad as
well.
Changing dlls/imm32/ime.c:ImeToAsciiEx() to send WM_IME_ENDCOMPOSITION when
compstr->dwCompStrLen is zero (see attached patch) seems to fix the bug without
any side effects in FFXIV and Notepad, but I have no idea what other effects
this might have, or if there needs to be some sort of deeper state tracking for
a proper fix.
--
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=55050
Bug ID: 55050
Summary: Wine stucks when creating prefix
Product: Wine
Version: 8.10
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: loader
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: cc2cfb9b792bee681b96c5859084fd6d4d0bbed7
Distribution: ---
wine: created the configuration directory '/home/andrey/.wine'
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly
L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:err:wineboot:start_services_process Couldn't start services.exe: error 998
--
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=54993
Bug ID: 54993
Summary: Framemaker 8 crashes in internal search operation
Product: Wine
Version: 8.9
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineps.drv
Assignee: wine-bugs(a)winehq.org
Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de
Distribution: ---
Framemaker 8 crashes in an search operation (which seems to be not
related to printing) with an internal error which in the past was
a sign of memory corruption.
A Bisect shows this commit:
a6cb10bba2d05ceca6ba5b1411c450d38defdbb4 is the first bad commit
commit a6cb10bba2d05ceca6ba5b1411c450d38defdbb4
Author: Piotr Caban <piotr(a)codeweavers.com>
Date: Mon May 15 17:34:23 2023 +0200
wineps: Don't pass PRINTERINFO structure to unixlib.
dlls/wineps.drv/init.c | 5 +-
dlls/wineps.drv/unixlib.c | 310 +++++-----------------------------------------
dlls/wineps.drv/unixlib.h | 5 +-
3 files changed, 35 insertions(+), 285 deletions(-)
Please tell me when you need more info (log file for which component?).
I understand thats its not easy to narrow this bug from the given information.
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=54742
Bug ID: 54742
Summary: The 64-bit advapi32:registry breaks the 32-bit
test_redirection() in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
The 64-bit advapi32:registry breaks the 32-bit test_redirection() in Wine.
To reproduce run the following commands:
$ rm -rf ~/.wine # start from a fresh wineprefix
$ ./wow64/wine64 wow64/dlls/advapi32/tests/x86_64-windows/advapi32_test.exe
registry 2>&1 | grep -E '(Test failed|tests executed)'
0020:registry: 6309 tests executed (156 marked as todo, 0 as flaky, 0
failures), 2 skipped.
$ ./wow32/wine wow32/dlls/advapi32/tests/i386-windows/advapi32_test.exe
registry 2>&1 | grep -E '(Test failed|tests executed)'
registry.c:2837: Test failed: RegOpenKeyExA failed: 2
registry.c:2842: Test failed: RegOpenKeyExA failed: 2
registry.c:2861: Test failed: 00000000: wrong value 32/64
registry.c:2863: Test failed: 00000200: wrong value 32/64
registry.c:2868: Test failed: 00000000: wrong value 64/0
registry.c:2869: Test failed: 00000100: wrong value 64/0
registry.c:2870: Test failed: 00000200: wrong value 64/0
registry.c:3168: Test failed: RegOpenKeyExA failed: 2
registry.c:3174: Test failed: RegOpenKeyExA failed: 2
registry.c:3180: Test failed: RegOpenKeyExA failed: 2
registry.c:3206: Test failed: found equals 0
registry.c:3208: Test failed: found equals 0
registry.c:3210: Test failed: found equals 0
registry.c:3212: Test failed: found equals 1
registry.c:3214: Test failed: wrong number of subkeys: 10
registry.c:3216: Test failed: found equals 1
registry.c:3218: Test failed: found equals 0
registry.c:3220: Test failed: wrong number of subkeys: 10
registry.c:3222: Test failed: found equals 0
0128:registry: 7658 tests executed (74 marked as todo, 0 as flaky, 19
failures), 2 skipped.
See https://test.winehq.org/data/patterns.html#advapi32:registry
The reason why this failure is only visible with the fg-deb64-wow32 is because
this is the only test configuration that runs the 32-bit tests in the same
wineprefix as the 64-bit tests.
What this shows is that advapi32:registry does not correctly cleans up after
itself which has the potential for breaking any test that follows (not just
32-bit ones).
--
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.