https://bugs.winehq.org/show_bug.cgi?id=57196
Bug ID: 57196
Summary: Cryostasis: Sleep of Reason demo needs node type for
object-typed field support
Product: vkd3d
Version: 1.13
Hardware: x86-64
URL: https://www.guru3d.com/files-details/cryostasis-sleep-
of-reason-game-demo.html
OS: Linux
Status: NEW
Keywords: download
Severity: minor
Priority: P2
Component: hlsl
Assignee: wine-bugs(a)winehq.org
Reporter: andrey.goosev(a)gmail.com
Distribution: ---
0124:err:d3dcompiler:D3DCompile2 signature.fx:9:1: E5017: Aborting due to
not yet implemented feature: Unhandled node type for object-typed field.
1.13-128-g4c03cda3
--
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=51139
Bug ID: 51139
Summary: Application T@X 2021 freezes when trying to transmit
data to Elster (German Tax Application)
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dieter.jurzitza(a)harman.com
Distribution: ---
T@X20XX can be used with wine since years. This year it apparently worked as
usual, with one frustrating exception: when trying to transfer the entire
documetation to the finance office at the end the application freezes and does
noting any more.
Unfortunately no error shows in the logs when starting wine with a
corresponding debug option (WINEDEBUG=+relay, I hope this is ok ...). I have 32
GByte of logging code what is meaningless to upload - but no "real" error
message inside.
"top" shows 100% CPU - load by the wine process stman.exe. Messages show like:
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6
01b8:Ret ntdll.RtlAllocateHeap() retval=3ec3bbe0 ret=089a10d6
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000024) ret=089a10d6
01b8:Ret ntdll.RtlAllocateHeap() retval=2f24da98 ret=089a10d6
01b8:Call KERNEL32.HeapFree(00220000,00000000,2f24da98) ret=0899e7eb
01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb
01b8:Call KERNEL32.HeapFree(00220000,00000000,3ec3bbe0) ret=0899e7eb
01b8:Ret KERNEL32.HeapFree() retval=00000001 ret=0899e7eb
in fast sequence and this:
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000014) ret=6be509ba
01b8:Ret ntdll.RtlAllocateHeap() retval=31991020 ret=6be509ba
0238:Call ntdll._strnicmp(17f9c7cc "Inter-| Receive
| Transmit\n",17f9ca0c "eth1",00000004) ret=7eceaa21
01b8:Call ntdll.RtlAllocateHeap(00220000,00000008,00000014) ret=6be7960b
0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21
01b8:Ret ntdll.RtlAllocateHeap() retval=31983590 ret=6be7960b
0238:Call ntdll._strnicmp(17f9c7cd "face |bytes packets errs drop fifo frame
compressed multicast|bytes packets errs drop fifo colls carrier
compressed\n",17f9ca0c "eth1",00000004) ret=7eceaa21
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,00000020) ret=6be798c1
0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21
01b8:Ret ntdll.RtlAllocateHeap() retval=31992478 ret=6be798c1
0238:Call ntdll._strnicmp(17f9c7d0 "lo: 376975 3786 0 0 0 0
0 0 376975 3786 0 0 0 0 0
0\n",17f9ca0c "eth1",00000004) ret=7eceaa21
0238:Ret ntdll._strnicmp() retval=00000001 ret=7eceaa21
01b8:Call ntdll.RtlAllocateHeap(00220000,00000000,0000000c) ret=6be7974e
0238:Call ntdll._strnicmp(17f9c7ce "eth1: 727671935 574392 0 0 0
0 0 2870 31275660 279019 0 0 0 0 0
0\n",17f9ca0c "eth1",00000004) ret=7eceaa21
01b8:Ret ntdll.RtlAllocateHeap() retval=31991978 ret=6be7974e
0238:Ret ntdll._strnicmp() retval=00000000 ret=7eceaa21
cycling through eth0, eth1, wlan0 etc ...
Finally I see once this at the begin (when the trouble starts ...):
01b8:Ret ntdll.RtlAllocateHeap() retval=3ecc7cc8 ret=089a10d6
01b8:Call KERNEL32.OutputDebugStringW(3ecc7cd8 L"void __thiscall
BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=67020427
01b8:Call ntdll.RtlInitUnicodeString(0021d000,3ecc7cd8 L"void __thiscall
BTS::FormViewerPage::enablePrevNext(void) -1 21\n") ret=7b0125fa
01b8:Ret ntdll.RtlInitUnicodeString() retval=00000082 ret=7b0125fa
with the "void __thiscall entries - but no clue on my behalf. Any support is
very much appreciated, most specifically what could I do and how could I better
debug the process without flooding my harddisk with trillions (ok, maybe less
:-)) of messages.
Thank you very much,
take care
Dieter Jurzitza
--
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=57157
Bug ID: 57157
Summary: winedbg: can't attach to windows process
Product: Wine
Version: 9.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)jmbreuer.net
Distribution: ---
I'm trying to debug a hang/freeze concerning Fallout 1 (it's still available on
Epic for free for a couple of hours, if someone should want to replicate
specifically).
Got myself to a point to run winedbg against the game, provoke the hang (in my
case, I just need to press Escape to open the in-game save/options/... menu).
Now, I want to have a look where all threads of the game are.
Wine-dbg>info process
pid threads executable (all id:s are in hex)
00000168 6 'falloutwHR.exe'
0000008c 3 'explorer.exe'
00000038 8 'services.exe'
000000e0 6 \_ 'rpcss.exe'
000000c0 3 \_ 'svchost.exe'
000000a8 4 \_ 'plugplay.exe'
00000068 8 \_ 'winedevice.exe'
00000044 8 \_ 'winedevice.exe'
00000020 1 'start.exe'
0000010c 1 \_ 'winedbg.exe'
=0000011c 1 \_ 'winedbg.exe'
>00000124 9 \_ 'Launcher.exe'
00000114 1 \_ 'Launcher.exe'
00000104 2 \_ 'conhost.exe'
OK, so, switch to falloutwHR.exe first, I guess:
Wine-dbg>attach 00000168
syntax error
Wine-dbg>attach 168
syntax error
Um. What am I doing wrong? Or is there something really weird broken? - I see
that there's a testing package of wine 9.16 for my distro (gentoo), I'll try
that next.
--
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=57185
Bug ID: 57185
Summary: Virtual DJ 2024: Unable to show drives on explorer
panel
Product: Wine
Version: 9.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rizalmart98(a)gmail.com
Distribution: ---
When expanding the DRIVES folder on explorer panel (panel at the lower left
corner) when clicking the "+" button, it does not show the drives detected
instead of showing C: and Z: drives after expanding the DRIVES folder
--
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=51732
Bug ID: 51732
Summary: TradeStation Installer: Unable to register servers.
Setup will now abort.
Product: Wine
Version: 6.0.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: christopher.m.penalver(a)gmail.com
Distribution: Ubuntu
Created attachment 70617
--> https://bugs.winehq.org/attachment.cgi?id=70617
WINEDEBUG=+relay wine 'TradeStation Setup.exe' 2>&1
Hello, attempting to install TradeStation from
https://update.tradestation.com/Installs/TradeStation/10.00.02.925/TradeSta…
with wine 6.0.1 causes a window to pop up noting precisely:
Unable to register servers. Setup will now abort.
In other words, the install fails and the user is left scratching their head
about why it 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=57179
Bug ID: 57179
Summary: Since Wine 7.5, file uploads in Hotline Client 1.2.3
hang after about 200 KB
Product: Wine
Version: 9.17
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineserver
Assignee: wine-bugs(a)winehq.org
Reporter: winehq(a)jordan.yelloz.me
Distribution: ---
I was uploading a file to a Hotline server from the Hotline client (1990s BBS
software used mostly on Macs) using recent versions of Wine, all the way up to
9.17 and noticed that uploads greater than about 200KB will not complete
successfully.
I found that this is working properly in wine 7.4 and earlier and I think I've
narrowed the cause down to the commit
https://gitlab.winehq.org/wine/wine/-/commit/1c6c90c7e1f1cd011e0ddb1dba4771…
. Though I'm not knowledgeable enough about wine's implementation to fix the
problem, I tested with the latest code in 64-bit mode, and if I just set
reply->nonblocking = FALSE at
https://gitlab.winehq.org/wine/wine/-/blob/6dfb84f5cbdf30c1dc0775fd4dae821e…
the upload will succeed but obviously the client application UI will be
unresponsive while that happens.
The windows versions of the Hotline client and server are downloadable from
https://preterhuman.net/gethotlinekdx.php
--
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=57192
Bug ID: 57192
Summary: X11DRV_SetCursorPos breaks when xinput "Coordinate
Transformation Matrix" is customized
Product: Wine
Version: 9.1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: mk939(a)ymail.com
Distribution: ---
Created attachment 77083
--> https://bugs.winehq.org/attachment.cgi?id=77083
WINEDEBUG=+cursor,+win wine minetest.exe | trimmed to one repetition of the
bugged SetCursorPos call
Discovered by testing Minetest 5.9.0 [1] in Wine. In-game, the cursor is always
moved to the center. However, when the xinput "Coordinate Transformation
Matrix" parameter, the cursor moves to unpredictable positions (bottom right
corner, for example). The game becomes unplayable.
I think it's caused by "X11DRV_SetCursorPos" because skipping
"NtUserSetCursorPos" entirely does avoid this issue. The cursor position is no
longer centred, but the game does not look as glitchy any more.
System specifications:
* Ubuntu 22.04, X11, xfce4
* amdgpu driver
Reproduced in Wine 9.1, Wine 9.17 and Proton 9.0-2.
Reproduced with
* Wine's virtual desktop on and off
* Window manager decorations on and off (winecfg)
* Window manager control on and off (winecfg)
Steps to reproduce:
1. xinput list
2. Remember the xinput <ID> of the mouse (Virtual core pointer -> HID)
3. xinput --set-prop <ID> 'Coordinate Transformation Matrix' 1.1 0 0 0 1.1 0 0
0 1
4. Join a world in Minetest and try to play
This problem does not occur when the Transformation Matrix is set to "1.0 0 0 0
1.0 0 0 0 1". It also does not occur on Windows due to lack of xinput and X11
in the first place.
[1]
https://github.com/minetest/minetest/releases/download/5.9.0/minetest-5.9.0…
--
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=57121
Bug ID: 57121
Summary: wine make keys sticky
Product: Wine
Version: 9.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: xinput
Assignee: wine-bugs(a)winehq.org
Reporter: axet(a)me.com
Distribution: ---
Hello!
Playing wine games I notices key become sticky sometimes. Pressing keys makes
no effect in the game for some delay and then all keys get burst into game
making character cast / jump like you pressed it at once.
This is only affecting keyboard input, mouse input is not affected. When keys
are sticky you still can use mouse do move, left / right clicks and character
responds to it.
I found out that it is easy to reproduce by using slow USB flash drive (4MB/s
write 20MB/s read) when you put all data into it: wine binaries, cache folder
(with mesa_shader_cache using XDG_CACHE_HOME variable), game it self. When you
start a game using this setup allays keys get sticky, but mouse is never
affected.
It is happening also when game and wine and cache on the HDD but much more
rarely. I guess when USB flash got accessed by linux kernel.
I'm using:
debian trixie
wine 9.16
i3-12100F // RX 6600 (amdgpu)
--
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=56030
Bug ID: 56030
Summary: Left 4 Dead 2 Version 2.2.0.0 Keyboard / Mouse inputs
not properly recognized.
Product: Wine
Version: 9.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: hibbsncc1701(a)gmail.com
Distribution: ---
With Wine-9.0-rc1 Left 4 Dead 2 Version 2.2.0.0 does not properly recognize
keyboard / mouse inputs.
It seems that in some cases key state changes are ignored. I.e. The key "gets
stuck" in the last read state. Causing behaviors like the player not moving
despite any of the WSAD keys being held down, continuing to move in a single
direction, or the player constantly firing / reloading / switching a weapon
(similar to a turbo controller) despite the mouse having only been clicked /
scrolled once (and the mouse not having a turbo mode). This seems to happen
about once every ~15-20 seconds. Making the game unplayable.
It also seems that the only way for the key to be "unstuck" is to change it's
state while the game is getting input. For example, If the player is stuck
firing a weapon, the player needs to manually fire the weapon again (Mouse1 by
default) and release the key before the game ignores input again to make the
weapon stop firing. Simply doing nothing will *not* fix the key state as far as
the game is concerned.
It should be noted that mouse movement does not seem to be affected by this. As
the player can still use mouse look normally despite the above behaviors.
--
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=37263
Bug ID: 37263
Summary: World Of Warcraft: stuck keys
Product: Wine
Version: 1.7.25
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: brian(a)infinityplusb.com
I'm running WoW 5.4.8.
At random intervals keys appear "stuck", even though they are not physically
stuck. I can really only notice the ones where the "stuck key" is for moving
(e,d,s,f) cause the character keeps strafing or running. Sometimes repressing
these keys causes the key to unstick, but that's maybe a 20-25% success rate.
Maybe less.
I'm new to this bug-filing thing so I'll try replicate the issue.
I'm not sure this issue is specific to Warcraft, but it's the only game I play.
There are other google tracks related to this, but they seem quite old
(pre-2008).
--
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.