https://bugs.winehq.org/show_bug.cgi?id=57797
Bug ID: 57797 Summary: GeForce NOW: Crash on start-up Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: coki@hotmail.com Distribution: ---
Created attachment 78001 --> https://bugs.winehq.org/attachment.cgi?id=78001 Output of Terminal and WineDBG
After successfully installing GeForce NOW, the application crashes on start-up
Application can be freely downloaded here: https://download.nvidia.com/gfnpc/GeForceNOW-release.exe
System Details: Arch Linux x86_64, Fresh default wine Prefix
https://bugs.winehq.org/show_bug.cgi?id=57797
Jorge Leguiza coki@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #78001|0 |1 is obsolete| |
--- Comment #1 from Jorge Leguiza coki@hotmail.com --- Created attachment 78002 --> https://bugs.winehq.org/attachment.cgi?id=78002 Output of Terminal and WineDBG
Re-upload since first upload seems to have corrupted
https://bugs.winehq.org/show_bug.cgi?id=57797
Jorge Leguiza coki@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #78002|0 |1 is obsolete| |
--- Comment #2 from Jorge Leguiza coki@hotmail.com --- Created attachment 78003 --> https://bugs.winehq.org/attachment.cgi?id=78003 WineDBG Backtrace
WineDBG backtrace of the application crash, re-upload as plain text to avoid corruption
https://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #3 from Jorge Leguiza coki@hotmail.com --- Created attachment 78004 --> https://bugs.winehq.org/attachment.cgi?id=78004 Wine Terminal Output
Wine terminal output, reuploading as plain text to avoid corruption (I'm sorry for the spam)
https://bugs.winehq.org/show_bug.cgi?id=57797
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://download.nvidia.com | |/gfnpc/GeForceNOW-release.e | |xe
http://bugs.winehq.org/show_bug.cgi?id=57797
Richard Yao richard@ryao.dev changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |richard@ryao.dev
--- Comment #4 from Richard Yao richard@ryao.dev --- The crash is in an APC that the process queues. The APC appears to be related to watching the filesystem. I reproduced it on my machine and the following patch from 2020 appears to fix this crash:
https://github.com/aabgrall/wine-base-geforcenow/commit/f27b5e30fb8e5da7d41b...
This allows it to progress somewhat further in its initialization. Unfortunately, there is another problem in Wine that causes a stack overflow when this issue is fixed.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #5 from Richard Yao richard@ryao.dev --- Created attachment 79479 --> http://bugs.winehq.org/attachment.cgi?id=79479 Program for changing the stack size of the main stack of an .exe
I tried patching wine to increase the stack size with no success until I decided to binary patch `.wine/drive_c/users/steamuser/AppData/Local/NVIDIA Corporation/GeForceNOW/CEF/GeForceNOW.exe`. Sometimes, it will self update, which undoes the change, but other times it does not and it is able to get a little further. The failures vary, but at an increase from a 16MB stack size, I saw the virtual_setup_exception() function report that the stack size had increased in one failure. With a 160MB stack size, I saw the following:
0024:fixme:ui:uisettings2_get_TextScaleFactor iface 000000007C0A7EB8, value 000000000898DC60 stub! 0024:fixme:ui:uisettings2_get_TextScaleFactor iface 000000007C0A7EB8, value 000000000898D550 stub! 0024:fixme:ui:uisettings2_get_TextScaleFactor iface 000000007C0A7EB8, value 000000000898CE40 stub! 0024:fixme:ui:uisettings2_get_TextScaleFactor iface 000000007C0A7EB8, value 000000000898C730 stub! 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:fixme:ui:uisettings2_get_TextScaleFactor iface 000000007C0A7EB8, value 000000000898C020 stub! 0024:err:gdi:alloc_gdi_handle out of GDI object handles, expect a crash 0024:fixme:resource:GetGuiResources (FFFFFFFFFFFFFFFF,1): stub wine: Unhandled exception 0x80000003 in thread 24 at address 00006FFFEF3BDC92 (thread 0024), starting debugger... 051c:fixme:dbghelp:elf_search_auxv can't find symbol in module 051c:fixme:dbghelp:elf_search_auxv can't find symbol in module 0x006fffef3bdc92 libcef+0x7b0dc92: int3
Note that there is a very long list of warnings about uisettings2_get_TextScaleFactor, but what is interesting is that it ran out of GDI object handles when given sufficient stack space. There is probably some sort of leak on the stack because of some way in which we are different than Windows.
My C program for modifying the stack size is attached. Compile it with `cc pe_modify_stack.c -o pe_modify_stack`.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #6 from Richard Yao richard@ryao.dev --- Using the patch from above applied to wine-staging 10.16, the application actually starts, but it fails to login. When you try, you get this message from CEF printed, which hints at the problem:
[23636:23636:1018/190442.569891:ERROR:third_party/crashpad/crashpad/util/linux/socket.cc:120] recvmsg: Connection reset by peer (104)
There are also a bunch of messages about `03bc:fixme:winsock:setsockopt Ignoring SO_RANDOMIZE_PORT`, which might or might not be related.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #7 from Richard Yao richard@ryao.dev --- Also, after the initial start of GeForce Now, it will restart with a black screen due to some deficiency in D3D11 support. Installing DXVK will resolve that.
If the connection issue is fixed, there is at least one more issue that needs to be resolved, which is to get AV1/HEVC decoding support working, as it is very unhappy without it:
[2025-10-18 23:20:18,170]=19:20:18= INFO [Platform] {00000588} - Requested streaming settings: 1920x1200@60, codec = unknown, colorSpace = 0, bitDepth = 0, chroma = 0, HDR: TRUE, forTelemetry = FALSE, ignoreTranscodeSupport = FALSE [2025-10-18 23:20:18,171]=19:20:18= INFO [DXVADecoder] {00000588} - Using getMaxDecoderCapability_DX11 [2025-10-18 23:20:18,171]=19:20:18= ERROR [DXUtils] {00000588} - DX Error: 80004001 [2025-10-18 23:20:18,171]=19:20:18= INFO [DXVADecoder] {00000588} - Using getMaxDecoderCapability_DX11 [2025-10-18 23:20:18,171]=19:20:18= ERROR [DXUtils] {00000588} - DX Error: 80004001 [2025-10-18 23:20:18,171]=19:20:18= INFO [Platform] {00000588} - AV1 decoder not supported! [2025-10-18 23:20:18,171]=19:20:18= INFO [DXVADecoder] {00000588} - Using getMaxDecoderCapability_DX11 [2025-10-18 23:20:18,171]=19:20:18= ERROR [DXUtils] {00000588} - DX Error: 80004001 [2025-10-18 23:20:18,171]=19:20:18= INFO [Platform] {00000588} - HEVC decoder not supported! [2025-10-18 23:20:18,171]=19:20:18= WARNING [Platform] {00000588} - Failed to get decoder capability. Fall back to default resolution 1280x720 with codec h264 [2025-10-18 23:20:18,171]=19:20:18= INFO [Platform] {00000588} - Transcoding not supported for 1280x720 [2025-10-18 23:20:18,171]=19:20:18= INFO [Platform] {00000588} - Allowing GRC without transcoding [2025-10-18 23:20:18,171]=19:20:18= INFO [DXVADecoder] {00000588} - Using getMaxDecoderCapability_DX11 [2025-10-18 23:20:18,171]=19:20:18= WARNING [GPUCapabilities] {00000588} - HDR is not supported for codec 1
That can be seen in `~/.wine/drive_c/users/${USER}/AppData/Local/NVIDIA Corporation/GeForceNOW/geronimo.log`. There is much more, but I am limiting it to that to avoid spamming the bug.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #8 from Richard Yao richard@ryao.dev --- Copying the files from a Windows install that has logged into GeForce Now to a Wine prefix (i.e. from `/Users/${USER}/AppData/Local/NVIDIA Corporation/GeForceNOW`) lets it start logged into GFN. Clicking on anything that would open a web browser window results in the following being printed:
kf.kio.gui: Failed to determine systemd version, falling back to extremely legacy forking mode. [26289:26289:1019/164245.077881:ERROR:third_party/crashpad/crashpad/util/linux/socket.cc:120] recvmsg: Connection reset by peer (104)
The connection failure is in some sort of IPC mechanism that GeForce Now uses, rather than any actual network communication. That is unfortunately even more tricky to debug.
That said, since the DXVA2 is a giant stub, you cannot actually stream any games even if you get to this point. It being a stub is a bit surprising since the wine-staging repository was changed with a note saying that the patches were in the process of being upstreamed 5 years ago, but none of the functionality to use vaapi was upstreamed. The result is basically what was reported on the forums, although I am confused how this even worked for him without the patch to ntdll:
https://forum.winehq.org/viewtopic.php?t=40791
I tried grafting the old dxva2 code from aabgrall/wine-base-geforcenow onto wine-staging 10.16 to see if it made a difference, but surprisingly, it made none.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #9 from Jorge Leguiza coki@hotmail.com ---
The result is basically what was reported on the forums, although I am confused > how this even worked for him without the patch to ntdll:
Hello, that is me, I wrote that post some days after this initial bug report, since at first I believed to be stuck, further attempts seem to show some lenience in the initialization process as I was not the only one to manage to make it run without the ntdll patch, see comment 7 on https://bugs.winehq.org/show_bug.cgi?id=52542
This ntdll issue may just be the most common and individual reports are needed for the other problems in initialization, past initialization I have not suffered any other issue that you commented on, Geforce NOW worked without issues, opening my browser and logging in correctly, no further issues with wine presented until the hardware decoding implementation was necessary
I have yet to try it myself on current WINE and my system now is completely different from then, same hardware however so I just have to get to it
To close for now, the issue I linked was fixed by 5c597119a069cc0343b6fa82d0ba946048d038ea which is also a submission from the GeforceNOW-oriented wine patches available out there into upstream, if you feel confident on it perhaps it's best to submit it and we can further work on the next issue that pops
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #10 from Jorge Leguiza coki@hotmail.com --- I have done new testings on WINE Staging 10.17, to my complete all start-up issues seem to be gone?
I made these tests in two virtual machines with barebones installation of Arch Linux and Artix Linux, so this should be entirely reproducible
From within virtual machine, I just installed Wine-Staging 10.17, winetricks, mesa, vulkan virtio drivers and Firefox
On the Arch Linux machine I used the LxQT Desktop Environment (running on X11) and on the Artix Machine (see systemd-less distribution) the Labwc wayland Compositor
I installed arial32 font using winetricks on both and ran the GeforceNOW installer, both install with no problems and then open the main program, the only immediate difference is that X11 has graphical glitches that make the program flicker black, where wayland labwc doesn't, otherwise functionality is completely seamless
I am able to proceed with the log-in normally, and I'm able to click "Play" on a game and perform the network test, past that nothing happens as expected without any kind of hardware decoding support.
If someone can reproduce this, we may be able to close the issue as solved?
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #11 from Richard Yao richard@ryao.dev ---
If someone can reproduce this, we may be able to close the issue as solved?
I cannot reproduce that. I don't understand how you are able to avoid the crash without that patch and how you are able to login or do anything else that involves a web browser. Installing arial makes no difference for me, but that is to be expected because I have core fonts installed via my package manager. Try renaming your wine prefix and installing into a fresh wine prefix to see if you are still immune to the issues. If you are, there are a number of things going right on your machine that are not going right on mine.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #12 from Richard Yao richard@ryao.dev --- Interestingly, wine-staging 10.17 eliminates the need for me to use DXVK. If I do use DXVK, it starts crashing with NULL pointer exceptions in libcef. I only need that patch to get it to start properly, although I cannot login unless I use an install from Windows where I already logged in.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #13 from Richard Yao richard@ryao.dev --- I have solved half of the mystery. Running `wine winebrowser www.github.com` breaks on my machine too. The message being printed was being printed by my native chromium browser, rather than CEF. Nothing I do in the registry to change the browser appears to fix it, but if I change KDE to use firefox instead of chromium as its default browser, login works. This is a different bug that I will need to file later. That said, How Jorge can avoid the need for that patch to be able to run this at all is still a mystery to me.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #14 from Jorge Leguiza coki@hotmail.com --- I did more testing today, in the same virtual machines I mentioned on comment 10 and followed what was requested on comment 11 and in fact this issue is still there
Both testings I did on comment 10 are legitimate however, I was able to start the already installed application on both virtual machines with no issues, and I have it recorded in video, after re-generating WINE and trying again the error returned. the only notable difference is the update 10.3 of WINE Mono though I believe that to not be the cause
I believe what happened is that "leniency" I had mentioned prior in comment 9 or in other words, I got really lucky to initialize correctly on both virtual machines on my tests for that comment
The issue is definitely still present and at this point I should try the suggested patch on comment 4 however my machine is not fast, compiling wine will take me many hours and I would be grateful if binaries could be provided, otherwise I'll report back once I have tested it
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #15 from Richard Yao richard@ryao.dev --- (In reply to Jorge Leguiza from comment #14)
The issue is definitely still present and at this point I should try the suggested patch on comment 4 however my machine is not fast, compiling wine will take me many hours and I would be grateful if binaries could be provided, otherwise I'll report back once I have tested it
There are a few issues with running binaries compiled by random strangers on the internet:
1. They could put malware into them. You are putting trust into the person who provides them that they are not going to do anything malicious. You are also trusting that their machine is not compromised, such that no malware will automatically inject itself into whatever they provide, even if they themselves are not malicious. 2. They are tied to the system’s libc, so they might not even run. I run Gentoo with the latest packages and I am on glibc 2.42. If I build binaries on my machine without cross compiling, the binaries will likely only work on systems running glibc 2.42 or later. Arch Linux is using glibc 2.42, but I cannot tell whether Artix is, as it is giving a 500 error on its packages page for glibc and the DDG cache suggests it is using glibc 2.41.
Then there are the legal requirements of the LGPL to provide source code upon request potentially indefinitely. This is not an issue for the person receiving the binaries, but it is a possible headache for the person providing them. Thankfully, if can be avoided by bundling the source code with the binaries, but that will boost the tarball size.
It has been years since I built wine outside of my package manager, but if nobody does one before me, I could do a build in the morning and put it on my HTTP server for you to download. However, you should keep in mind all of the caveats stated above about this. If you want to be able to compile wine yourself quickly, setup ccache. The first build would be slow, but subsequent builds would be fast. They would be even faster if you specify a job count with the -j option to try to keep the build process parallelized.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #16 from Richard Yao richard@ryao.dev --- I have built wine and placed the tarball on my HTTPS server for you:
https://ryao.dev/wine-gfn-10.17.tar.xz
The sha256 checksum should be 7773de3cb23ededa0094c4c033386e619ca7d40ad0c7fe9bd4ccdf1890162447.
After patching the wine sources, it was built roughly this way on my Gentoo ~amd64 host (using glibc 2.42):
mkdir build cd build ../configure --prefix=$HOME/my-custom-wine --enable-archs=i386,x86_64 make -j$(nproc) make install DESTDIR=/tmp/wine -j$(nproc)
I used DESTDIR to verify that nothing was installed outside of the prefix, which was the case. Then I renamed my-custom-wine to wine-gfn-10.17, made a sources directory inside it and placed a copy of the sources used to build it there. I made a tarball like this:
cd /tmp/wine/home/richard tar -vcf wine-gfn-10.17.tar wine-gfn-10.17/ xz -9e wine-gfn-10.17.tar
Also, I did some basic tests on the result by doing the following and verifying that the application ran without crashing:
env WINEPREFIX=~/test-prefix /tmp/wine/home/richard/wine-gfn-10.17/bin/wineboot -i env WINEPREFIX=~/test-prefix /tmp/wine/home/richard/wine-gfn-10.17/bin/wine Downloads/GeForceNOW-release.exe env WINEPREFIX=~/test-prefix /tmp/wine/home/richard/wine-gfn-10.17/bin/wineserver -k
Although I cannot guarantee indefinite availability on github, a copy of the sources is also available there in the nvidia-10.17 development branch at commit d6de1cfeea99385ffd6156e6facaa464ef5ed0aa:
https://github.com/aabgrall/wine-base-geforcenow
If I ever take down the tarball and the github repository ceases to operate, I will be unable to satisfy requests for sources under the LGPL, but my obligation to provide sources is implicitly fulfilled by bundling them in the tarball, so I wash my hands of any further obligations to provide sources.
I am probably being pedantic, but ensuring source code availability is legally required by the LGPL whenever anyone provides binaries across organizational boundaries. I do not like unbound legal obligations, which is why I almost never provide GPL/LGPL binaries and usually insist on providing source code to others. If I could not circumvent the LGPL/GPL requirements by bundling the sources, I would not have done this.
Finally, I should reiterate that you should never trust binaries built by random people on the internet. You should always insist on building from source yourself rather than implicitly trusting others who provide binaries. In the cases where you do trust people who provide binaries, they should always be from well trusted sources such as distributions, rather than random individuals. I usually never provide binaries to others for the above reasons, and I am only doing this so that you can verify that the patch works in your VM environment.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #17 from Richard Yao richard@ryao.dev --- I have gotten the old DXVA2 code working locally via some hacks, but it implements acceleration via a D3D9 interface and if we tell GeForceNow to use D3D9 by editing `.wine/drive_c/users/${USER}/AppData/Local/NVIDIA Corporation/GeForceNOW/CEF/GeForceNOW.json`, we get a black screen, even if we install DXVK. Coincidentally, wine-staging 10.17 regressed and installing DXVK in it will cause CEF to start crashing.
Getting this working will either require fixing the D3D9 black screen issue or implementing the D3D11 interface for DXVA2. The D3D11 interface appears to be partially implemented via vulkan video if you do `winetricks renderer=vulkan` to set the renderer to vulkan. Also, no matter how this is made to work, AV1 support will need to be implemented to enable higher streaming resolutions and refresh rates.
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #18 from Richard Yao richard@ryao.dev --- Created attachment 79508 --> http://bugs.winehq.org/attachment.cgi?id=79508 Hack to semi-stub functions to let GeForce Now progress further
When it fails to stream, it prints a key line to geronimo.log:
[2025-05-13 17:21:03,712]=14:21:03= ERROR [DXVADecoderInstance] {00000A8C} - GERONIMO_ERROR 0xC0F1106C GERONIMO_DXVA_DX11_DECODER_FORMAT: DXVA(DX11) CheckVideoDecoderFormat failed.
After switching to the vulkan backend and applying this patch, it now prints this line:
[2025-10-24 05:35:30,814]=01:35:30= ERROR [DXVADecoderInstance] {00000A64} - GERONIMO_ERROR 0xC0F11069 GERONIMO_DXVA_DX11_CREATE_TEXTURE_2D: DXVA(DX11) CreateTexture2D failed.
That is rather interesting, since WINEDEBUG=d3d,d3d11 shows that the texture was made successfully. It also shows that dxgi_resource_GetSharedHandle is a stub:
0a64:fixme:dxgi:dxgi_resource_GetSharedHandle iface 0000000036DDD408, shared_handle 000000000090BAE8 stub!
My theory is that GetSharedHandle is being called on the texture and when dxgi_resource_GetSharedHandle returns that it failed, GeForce Now logs that creating the texture failed. It is a shame since it looks like everything else is in place for it to attempt to decode the video. I say attempt because I found a test program for this:
https://github.com/turanszkij/mini_video
I compiled it by running `x86_64-w64-mingw32-g++ mini_video_dx11.cpp -o mini_video_dx11.exe -std=c++17 -fpermissive -Wall -ffunction-sections -finline-functions -DNDEBUG -D_CONSOLE -D_UNICODE -DUNICODE -O2 -static-libgcc -static-libstdc++ -fexceptions -ld3d11 -ldxgi -ldxguid -ld3dcompiler -luser32 -lkernel32 -O0 -g` after doing a small patch so that the "Linux" version of `firstbitlow()` is used rather than the Windows version, which relies on a compiler intrinsic specific to the MSVC compiler. Running that test program gives me a green screen.
Whether or not that will happen if GeForce Now succeeds is unknown to me. However, it looks like further progress will be blocked on implementing dxgi_resource_GetSharedHandle().
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #19 from Jorge Leguiza coki@hotmail.com --- (In reply to Richard Yao from comment #16)
I have built wine and placed the tarball on my HTTPS server for you:
As mentioned I am immensely grateful for your effort, unfortunately the binary was compiled for an instruction set superior to what my processor supports (x86_64v2) and I was unable to run it, regarding the risks of running binaries from strangers, this is not an issue for my case, fully restoring my system takes me way less time than what WINE takes to compile
I have since re-initialized both virtual machines (arch and artix) and compiled WINE with the patch following the guide on WineHQ for a Shared WOW64 build; https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#shared-wow64
I ran the installation and initialization multiple times to make sure I wasn't falling for the "leniency" again, and the ntdll issue seems actually fixed this time but strangely I did not find any Stack Overflow errors as you had previously commented
Stranged by this I decided to make another wine compilation, this time using the building scripts provided by Kron4ek on over on https://github.com/Kron4ek/Wine-Builds which generate the binaries I usually run, and ran the tests again on both virtual machines multiple times to account for the leniency and I still did not find any Stack Overflow errors
If these still persist for you until now, I'm inclined to say there is something going on your setup that is prone to generating errors, perhaps a container or a virtual machine with hardware pass-through would be good to consider for future testings
http://bugs.winehq.org/show_bug.cgi?id=57797
--- Comment #20 from Jorge Leguiza coki@hotmail.com --- (In reply to Richard Yao from comment #17)
I have gotten the old DXVA2 code working locally via some hacks, but it implements acceleration via a D3D9 interface and if we tell GeForceNow to use D3D9 by editing `.wine/drive_c/users/${USER}/AppData/Local/NVIDIA Corporation/GeForceNOW/CEF/GeForceNOW.json`, we get a black screen, even if we install DXVK. Coincidentally, wine-staging 10.17 regressed and installing DXVK in it will cause CEF to start crashing.
On Windows this change makes the black screen happen as well, I believe the application is just not suitable to run on DX9 and the path of trying to make it work with it is best avoided
Unfrotunately my hardware is not compatible with current vulkan versions I can only run on opengl, I'll be unable to help further testing requiring vulkan
-
WineHQ Bugzilla