https://bugs.winehq.org/show_bug.cgi?id=52500
Bug ID: 52500 Summary: error with winediag (nodrv_CreateWindow) Product: Wine Version: 6.23 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: josue.bock@univ-smb.fr Distribution: ---
Created attachment 71795 --> https://bugs.winehq.org/attachment.cgi?id=71795 output in command line showing errors
Hello, When upgading from 6.22 to 6.23, wine does not open anymore with a software.
It seems to be related to another bug report (https://bugs.winehq.org/show_bug.cgi?id=51210) but AFAIC see, this was not the same wine version involved.
My laptop also has two GPU, one Intel and one Nvidia. The Intel one is expected to be unactivated.
I asked for help on the forum before sending this bug report, the discussion is here: https://forum.winehq.org/viewtopic.php?f=2&t=36155&p=135932#top
https://bugs.winehq.org/show_bug.cgi?id=52500
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Severity|blocker |critical
--- Comment #1 from Austin English austinenglish@gmail.com --- Does this persist for you in 7.1? If so, please run a regression test: https://wiki.winehq.org/Regression_Testing
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #2 from jb_usmb josue.bock@univ-smb.fr --- Hi,
It does persist in 7.0 and 7.1.
I tried to run the regression test, but the first compilation fails: [code] $ CC="ccache gcc -m32" ./configure --verbose --disable-tests checking build system type... x86_64-pc-linux-gnux32 checking host system type... x86_64-pc-linux-gnux32 checking whether make sets $(MAKE)... yes checking for gcc... ccache gcc -m32 checking whether the C compiler works... no configure: error: in `/home/josue/wine-git': configure: error: C compiler cannot create executables See `config.log' for more details [/code]
The config.log is in attachment
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #3 from jb_usmb josue.bock@univ-smb.fr --- Created attachment 71801 --> https://bugs.winehq.org/attachment.cgi?id=71801 compilation log
https://bugs.winehq.org/show_bug.cgi?id=52500
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- (In reply to jb_usmb from comment #3)
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc
Your gcc can't compile 32bit binaries without having its 32bit libraries. The wiki or forum should help here.
https://bugs.winehq.org/show_bug.cgi?id=52500
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Austin English austinenglish@gmail.com --- Invalid
https://bugs.winehq.org/show_bug.cgi?id=52500
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED
--- Comment #6 from Austin English austinenglish@gmail.com --- (In reply to Austin English from comment #5)
Invalid
My apologies, there's still (likely) a bug here (the regression).
I mistakenly closed after only reading the compile problem.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #7 from jb_usmb josue.bock@univ-smb.fr --- I am sorry but I don't succeed with the regression testing (despite many attempts)
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Is there a free download we could use to try and reproduce?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #9 from jb_usmb josue.bock@univ-smb.fr --- a free download of the software? Yes: https://wwwguidelinegeoc.cdn.triggerfish.cloud/uploads/2018/09/TerrameterToo...
However, as stated in my first message, I'm affraid that the issue arises at least partly from the double GPU (Intel + Nvidia) in my computer
https://bugs.winehq.org/show_bug.cgi?id=52500
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://wwwguidelinegeoc.cd | |n.triggerfish.cloud/uploads | |/2018/09/TerrameterToolbox_ | |Setup.2.0.2.0.zip
--- Comment #10 from Fabian Maurer dark.shadow4@web.de --- Possibly, I can't reproduce it. However, if another dev/user comes across this and has such a setup, they now can test it.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- Archived at https://web.archive.org/web/20220204163354/https://wwwguidelinegeoc.cdn.trig...
https://bugs.winehq.org/show_bug.cgi?id=52500
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #12 from Bernhard Übelacker bernhardu@mailbox.org --- Attachment 71795 contains also an execution attempt "wine notepad.exe", which fails the same way (and just creating the prefix).
Are any applications able to open windows from this shell prompt? (e.g. wines builtin 'notepad' or 'winecfg', or linux native 'xterm'?)
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #13 from Bernhard Übelacker bernhardu@mailbox.org --- This is a 64-bit system? Therefore could this also be caused by missing 32-bit X11 libraries?
From where got the wine binaries retrieved and how installed, just
through the package management or some manual way?
Maybe the winex11.drv.so from a 32-bit path could be located and maybe ldd shows missing libraries for this file?
https://bugs.winehq.org/show_bug.cgi?id=52500
nj8ne5e16@mozmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nj8ne5e16@mozmail.com
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #14 from jb_usmb josue.bock@univ-smb.fr --- Thank you for your help.
I recently made little progress to understand what's happening. As described in my first message in this thread, the computer has 2 graphic cards installed, an integrated Intel one, and a Nvidia one.
I noticed that depending on the screen used (thus I imagine the graphic card used), wine fails or not. So I believe that wine is properly installed to work with one graphic card, but not the other. And I cannot find a way to make an install that would be versatile, and work whatever the graphic card used.
For more info: - I use the computer in 3 screen settings: alone (laptop), with a screen plugged through HDMI (single screen), or with a screen plugged through docking station. - the Nvidia X server settings utilitary allows to choose between 3 options for prime settings (Nvidia, on-demand, or Intel (disabled)). I tested the 3 settings, without success - I reinstalled wine from scratch (currently stable release 7.0) without success. As far as I can see, 32 bits libraries are installed (the first step of the install was "sudo dpkg --add-architecture i386")
I am obviously willing to make test and trials following any hints that you could advise me. Thank you for your help
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #15 from jb_usmb josue.bock@univ-smb.fr --- Created attachment 72564 --> https://bugs.winehq.org/attachment.cgi?id=72564 output of 2 repeated "wine notepad" attempts, first failed, second worked
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #16 from jb_usmb josue.bock@univ-smb.fr --- Hello,
After upgrading Ubuntu to 22.04, and re-installing Wine (v7.10 devel), the same issues as previously encountered persist: - wine usually does not work, but it depends on the screen display settings - repeated trials to start a wine application (for instance, wine notepad) is sometimes a solution: after a few attempts, it works - once a first application is running, starting other wine applications work well. I attachment is the output of 2 repeated attempts to start wine notepad, the first failed, the second worked fine.
As expressed previously, my feeling is that the presence of 2 graphic cards on my computer is, at least partly, causing these troubles.
Amongst the error/warning messages, the "no driver could be loaded" is always present when wine fails to start.
I add another attachment with a few output showing my computer configuration, if this can help.
Any help would be much appreciated, thanks.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #17 from jb_usmb josue.bock@univ-smb.fr --- Created attachment 72565 --> https://bugs.winehq.org/attachment.cgi?id=72565 output of inxi -SGxxx and glxinfo -B commands
In this case, the computer is used as a laptop: no docking station, no external screen. In this configuration, the "wine notepad" first failed when started, then worked after a second trial.
Once notepad was opened, another program could be successfully started (while it was not starting previously).
https://bugs.winehq.org/show_bug.cgi?id=52500
Jeremy Walker winehq.machg@spamgourmet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq.machg@spamgourmet.co | |m
--- Comment #18 from Jeremy Walker winehq.machg@spamgourmet.com --- I too am experiencing this issue. Like jb_usmb, I have:
2 graphic cards installed, an integrated Intel one, and a Nvidia one.
Specifically I have a GK104M (GeForce GTX 870M) card, which I guess falls back on an Intel motherboard card. On Linux I believe they call it Nvidia Prime, or Nvidia Optimus, or something like that?
Anyhow, when I try a simple:
winecfg
It fails with:
0244:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0244:err:winediag:nodrv_CreateWindow The explorer process failed to start.
Also, this fails identically:
NODEVICE_SELECT=1 winecfg
I strongly suspect this is graphics-related, but I'm stuck on the latest stable Nvidia drivers (470), because I experience major issues with the Noveau (ie. OSS) driver, or with the older (390) Nvidia driver.
I should note that I used to run an older version of Linux Mint on this exact same machine, and WINE worked great. Since then however I've reinstalled with Cinnamon instead of MATE, and with a newer Linux Mint distro (that has who knows what changes compared to my old system).
I do still have the drive with the old install, so if there's any files from it that I can provide that would be helpful, please let me know. I'm also happy to provide any other diagnostics or details that could help.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #19 from Fabian Maurer dark.shadow4@web.de --- @Jeremy If you still experience the issue, can you do a regression test?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #20 from Jeremy Walker winehq.machg@spamgourmet.com --- Not sure what you mean by regression test, but I think I did one accidentally, on my graphics drivers. I tried lowering the graphics card driver version from 470 to 390, because 390 (https://www.nvidia.com/Download/driverResults.aspx/196213/en-us/) does support my graphics card (870m), while 470 (https://www.nvidia.com/Download/driverResults.aspx/194637/en-us/) doesn't.
Interestingly (after a restart) I saw:
$ winecfg 00d8:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 00d8:err:winediag:nodrv_CreateWindow The explorer process failed to start. $ MESA-INTEL: warning: Haswell Vulkan support is incomplete MESA-INTEL: warning: Haswell Vulkan support is incomplete
But, I tried again, and:
$ winecfg Xlib: extension "NV-GLX" missing on display ":0". MESA-INTEL: warning: Haswell Vulkan support is incomplete 0104:fixme:imm:ImeSetActiveContext (0x261b40, 1): stub 0104:fixme:imm:ImmReleaseContext (000000000001005E, 0000000000261B40): stub 0068:fixme:imm:ImeSetActiveContext (0x25d120, 0): stub 0068:fixme:imm:ImmReleaseContext (0000000000010020, 000000000025D120): stub
So it seems to me that if anyone is to blame, it's Linux Mint for pushing me onto the newest drivers, when those drivers don't actually support my card.
https://bugs.winehq.org/show_bug.cgi?id=52500
Aybabtu lesdf123@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lesdf123@gmail.com
--- Comment #21 from Aybabtu lesdf123@gmail.com --- Hello,
I have the same poblem. I try to downgrade drivers for may GC but too much bug, it's not workiing. So now what is the next step ? waiting for a update ? Thnx, best regards.
https://bugs.winehq.org/show_bug.cgi?id=52500
wine@loeb-it.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@loeb-it.de
--- Comment #22 from wine@loeb-it.de --- Created attachment 74013 --> https://bugs.winehq.org/attachment.cgi?id=74013 output of successful attempt with wine-8.1
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #23 from wine@loeb-it.de --- Created attachment 74014 --> https://bugs.winehq.org/attachment.cgi?id=74014 output of failed attempt with wine-8.1
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #24 from wine@loeb-it.de --- Hi, I can confirm the same issue with wine-vanilla (7.0 and 8.1) on Gentoo. This includes the strange behavior that wine starts after repeated tries with only one screen as described in comment #17. However, i noticed it also start with multiple displays (3), it just takes more tries. So it might be some timing issue.
This machine also is a laptop with dual graphic card setup (Nvidia Quadro RTX 4000 Mobile / Max-Q and Intel UHD Graphics P630)
Added terminal output of wine 8.1 with this setup. Maybe it is useful for comparison.
Tomorrow I will try the same on a machine with nearly identical setup, but only one graphic card (Iris Xe)
regards
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #25 from wine@loeb-it.de --- Tried with (nearly) the same gentoo setup on a different machine with a single graphics card (Iris Xe)). So it really looks like, this is connected to the dual graphic cards.
https://bugs.winehq.org/show_bug.cgi?id=52500
nj8ne5e16@mozmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|nj8ne5e16@mozmail.com |
https://bugs.winehq.org/show_bug.cgi?id=52500
Lyam lyamcwitherow@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lyamcwitherow@gmail.com
--- Comment #26 from Lyam lyamcwitherow@gmail.com --- Created attachment 74156 --> https://bugs.winehq.org/attachment.cgi?id=74156 winecfg failed start
Just to add to this, I also have two GPUs and am currently expienceing this issue.
Yesterday, 2023-03-04, wine and wine applications were working. I did a full system update (pacman -Syu) and installed some of the latest available firmware and intel graphical components that evening (10PM CST). After reboot, wine applications wouldn't run/load/etc. I tried an older kernel but I didn't get the GUI, so I'm immediately suspicious of the graphics drivers.
I have since downgraded packages, but I still have the same exact problem. Testing with winecfg gets me the errors as shown in the attachment. Either I am somehow missing the package that needs to be downgraded, or, one of the packages that were updated caused an issue that persists after a downgrade.
GPU (Primary): Intel ARC A770 (DG2) using the i915 driver GPU: AMD Ryzen 5600G (RADV RENOIR) using the amdgpu driver
I happen to have another machine with a Nvidia GTX 1650 and I can pull from, so if I can find the time, I'll do some testing around the dual-GPU theory.
Something to note is that whenever wine is started (and fails), whether "winecfg" or through Steam, for approx. 15 seconds the entire KDE Desktop UI becomes incredibly unresponsive. I can move the mouse around fine but anything like UI elements, KDE buttons, or terminal updates like text input would "freeze" for seconds at a time. I'm interested if anyone else experienced similar behaviour.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #27 from Lyam lyamcwitherow@gmail.com --- Created attachment 74157 --> https://bugs.winehq.org/attachment.cgi?id=74157 Working and non-working outputs
I found the cause of my issue.
After my upgrade, somehow the display manager got changed from Wayland to X11, and I didn't notice.
Changing the display server, and changing the Displayport physical connections resulted in the following. Intel ARC A770 GPU (Wayland): Success Intel ARC A770 GPU (X11): Fail AMD 5600G GPU (Wayland): Success AMD 5600G GPU (X11): Success
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #28 from wine@loeb-it.de --- My systems I mentioned before are running on X11, so it might really be related to the difference X11/Wayland. I can also see the desktop getting unresponsive when wine startup fails.
https://bugs.winehq.org/show_bug.cgi?id=52500
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=52500
Griga griga@dvbviewer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |griga@dvbviewer.com
--- Comment #29 from Griga griga@dvbviewer.com --- I can confirm that using a NVidia driver causes a timing issue (as already supposed in Comment 24) under Linux Mint 21.2 with Wine 8.19 development release. The inxi -G output shows that there is no second Graphics adapter, but another device in the Graphics section:
Device-1: NVIDIA GP108 [GeForce GT 1030] driver: nvidia v: 535.113.01 Device-2: TechniSat Digital GmbH DVB-PC TV Star HD type: USB driver: N/A Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia resolution: 1920x1080~60Hz OpenGL: renderer: NVIDIA GeForce GT 1030/PCIe/SSE2 v: 4.6.0 NVIDIA 535.113.01
It takes about 1 minute waiting time after boot-up and login before a Windows application can be launched. Earlier attempts end up with
00f0:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 00f0:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
Hence attempts to auto-start Windows applications via the Mint Startup Application menu fail after boot-up/login unless a considerable startup delay is configured for them (at least 60 seconds, better more).
Doing something else that keeps the system busy (like launching the browser) during the waiting time increases it accordingly. It may be due to the fact that there is no SSD. Everything must be read from a HD.
The waiting time seems to become significantly shorter if the TechniSat USB DVB Box is removed (see inxi -G output above). Windows applications can already be launched 30 seconds after login.
It's quite obvious that something must happen before Wine is able to launch a Windows application, and whatever-it-is takes time. It happens after login, because delaying login for a minute or more doesn't avoid the issue.
However, after logging off and in again (without reboot) the issue does not persist. Windows auto-start applications are launched without requiring a configured delay.
The issue does not appear if the Nouveau driver is used, or after Linux Mint 21.2 boot-up on another PC with an Intel HD 530 Graphics as only GPU. In both cases launching Windows applications doesn't require a waiting time.
https://bugs.winehq.org/show_bug.cgi?id=52500
O. Nykyforchyn oleh.nyk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oleh.nyk@gmail.com
--- Comment #30 from O. Nykyforchyn oleh.nyk@gmail.com --- The issue is still present in wine-9.0-rc3 making it quite unusable for me, can't even run winecfg to create a new prefix. Tested on two laptops, one with a single integrated GPU, the other with two GPUs (intel + radeon), both with Slackware-15.0+. What is interesting, when I try to debug on a "quite created" prefix what is going on with winex11 and user32 removed from RelayFromExclude and
WINEDEBUG=+relay,+module,+x11drv,+reg,+explorer winecfg 2>&1 | tee ~/wine.log egrep 'winex11|X11 Driver' wine.log > wine-winex11.log
the x11drv debug channel is silent, although other ones work as extected. Initialization of winex11.drv is started and failed, no debug messages from within at all, although there is a "deeper" message that open_hkcu_key() opens 'Software\Wine\X11 Driver' key (see attachment), which can be done only from setup_options() in x11drv_main.c.
Not working TRACEs and even ERRs for x11drv make impossible to track what goes wrong in x11drv_init().
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #31 from O. Nykyforchyn oleh.nyk@gmail.com --- Created attachment 75801 --> https://bugs.winehq.org/attachment.cgi?id=75801 part of debug messages
As I said above, these lines have been egrep'ped, the entire log is 166 Mb long.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #32 from O. Nykyforchyn oleh.nyk@gmail.com --- I downgraded to wine-7.0, now wine mostly works, but sometimes the error occurs even there. Seems like a timing issue. Would be nice to revive diagnostic message from winex11, if this is possible before x11drv is initialized.
https://bugs.winehq.org/show_bug.cgi?id=52500
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|error with winediag |Wine fails to load the user |(nodrv_CreateWindow) |driver when using NVidia | |Optimus
--- Comment #33 from Zeb Figura z.figura12@gmail.com --- It looks like NVidia Optimus is the common thread here, as well as in bug 55633, so retitling and collecting that as a duplicate.
This is probably a bug with the NVidia driver. However, if anyone is able to perform a bisect, that will probably help the bug get solved a lot more quickly.
https://bugs.winehq.org/show_bug.cgi?id=52500
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gavron@wetwork.net
--- Comment #34 from Zeb Figura z.figura12@gmail.com --- *** Bug 55633 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #35 from O. Nykyforchyn oleh.nyk@gmail.com --- Should I open a new bug report if I encounter te same error, but none of my two laptops have NVidia GPU, moreover, one of them has ONE GPU:
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
and the other one reports Intel 3rd Gen Core processor Graphics Controller + Radeon HD 8730M?
Or should I post to https://bugs.winehq.org/show_bug.cgi?id=51210 ?
And the absence of debug messages from x11drv when its initialization fails- is it normal or I have to file a bug?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #36 from Ehud Gavron gavron@wetwork.net ---
Should I open a new bug report
It's a two year old ticket that the devs are too lazy to handle. One suggested it's up to the users (who typically don't build Wine* from source) to bisect.
The rot in this project is reaching the surface, and it doesn't smell like roses, except to Wine* devs who don't give a rat's ass about this two year old issue affecting hundreds of thousands of people. They offer excuses "Oh it must be Nvidia" despite it working on previous Wine, and they offer insipid suggestions "just bisect the code."
Lazy bitchaz.
https://bugs.winehq.org/show_bug.cgi?id=52500
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #37 from Zeb Figura z.figura12@gmail.com --- (In reply to O. Nykyforchyn from comment #35)
Should I open a new bug report if I encounter te same error, but none of my two laptops have NVidia GPU, moreover, one of them has ONE GPU:
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
and the other one reports Intel 3rd Gen Core processor Graphics Controller + Radeon HD 8730M?
Or should I post to https://bugs.winehq.org/show_bug.cgi?id=51210 ?
Eh, that may mean I was too hasty to set the status of this bug / resolve duplicates.
And the absence of debug messages from x11drv when its initialization fails- is it normal or I have to file a bug?
It's not inexplicable. I can see a couple of ways initialization can fail without any log messages. Can you please add +seh to your debug channels and upload the whole log here? (You can compress it if it's too large to fit.)
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #38 from O. Nykyforchyn oleh.nyk@gmail.com --- Created attachment 75888 --> https://bugs.winehq.org/attachment.cgi?id=75888 xz'ed log of a failed attempt to run winecfg
First I run WINEDEBUG=+relay,+seh,+explorer,+x11drv,+reg,+module winecfg 2>&1 | tee ~/wine.log to create a fresh prefix, but when the log size reached 3 Gb, I gave in.
The attached log is for an already created prefix.
Hope that will help to find out what is going wrong.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #39 from O. Nykyforchyn oleh.nyk@gmail.com --- (In reply to Zeb Figura from comment #37)
It's not inexplicable. I can see a couple of ways initialization can fail without any log messages.
I would consider this as a code defect: issues with winex11 initialization arise regularly, then the are kind of solved (or hidden), but users have no possibility to diagnose the root of evil. Why not add some messages after each major step if initialization that can fail?
To tell the truth, I tried to add extra messages to the code of explorer and of winex11 to get more info, the first worked, but the second did not. Maybe no debug messages from x11drv code can be printed until the driver is initialized completely?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #40 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75889 --> https://bugs.winehq.org/attachment.cgi?id=75889 DEBUG-make-winex11.drv-DllMain-visible.patch
(In reply to O. Nykyforchyn from comment #38)
Created attachment 75888 [details] xz'ed log of a failed attempt to run winecfg
0048:trace:module:build_module loaded L"\??\C:\windows\system32\explorer.exe" 00007FFFFE223620 0000000140000000 0048:Call KERNEL32.LoadLibraryW(7ffffe1ff290 L"winex11.drv") ret=14000220f 0048:warn:module:process_attach Initialization of L"winex11.drv" failed 0048:Ret KERNEL32.LoadLibraryW() retval=00000000 ret=14000220f
I guess this failing LoadLibraryW is the first visible sign of the issue.
Unfortunately by default winex11.drv is excluded from +relay. If you want to see calls done by winex11.drv you could remove it from the exclusion list (I assume command line is working?):
$ wine reg query 'HKCU\Software\Wine\Debug' /v RelayFromExclude HKEY_CURRENT_USER\Software\Wine\Debug RelayFromExclude REG_SZ winex11.drv;winemac.drv;user32;gdi32;advapi32;kernel32
$ wine reg add 'HKCU\Software\Wine\Debug' /v RelayFromExclude /t REG_SZ /d "winemac.drv;user32;gdi32;advapi32;kernel32"
$ wineserver -k
Afterwards a +relay should include calls done from winex11.drv.
If you want to add some debug logging I guess in dlls/winex11.drv/dllmain.c the function DllMain might be therefore the starting point.
Unfortunately output of explorer.exe at this stage is kind of hidden. Attached patch should make it better visible, if you want to give it a try?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #41 from Zeb Figura z.figura12@gmail.com --- (In reply to O. Nykyforchyn from comment #39)
(In reply to Zeb Figura from comment #37)
It's not inexplicable. I can see a couple of ways initialization can fail without any log messages.
I would consider this as a code defect: issues with winex11 initialization arise regularly, then the are kind of solved (or hidden), but users have no possibility to diagnose the root of evil. Why not add some messages after each major step if initialization that can fail?
I agree that's a good idea, but there's unfortunately quite a lot of code in Wine that catches unexpected failures silently. If nothing else I don't have time to fix every instance.
Anyway, based on the log, it fails after loading ntdll [in __wine_init_unix_call()] but before setup_options() in x11drv_init [otherwise we'd get registry traces], and it doesn't crash, or hit the ERR in x11drv_init(). I believe that means that winex11.so itself fails to load, possibly because libX11.so or some dependency failed to load. I don't think that's diagnosable any further on the Wine side.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #42 from O. Nykyforchyn oleh.nyk@gmail.com --- (In reply to Zeb Figura from comment #41)
(In reply to O. Nykyforchyn from comment #39)
(In reply to Zeb Figura from comment #37)
It's not inexplicable. I can see a couple of ways initialization can fail without any log messages.
I would consider this as a code defect: issues with winex11 initialization arise regularly, then the are kind of solved (or hidden), but users have no possibility to diagnose the root of evil. Why not add some messages after each major step if initialization that can fail?
I agree that's a good idea, but there's unfortunately quite a lot of code in Wine that catches unexpected failures silently. If nothing else I don't have time to fix every instance.
Anyway, based on the log, it fails after loading ntdll [in __wine_init_unix_call()] but before setup_options() in x11drv_init [otherwise we'd get registry traces], and it doesn't crash, or hit the ERR in x11drv_init(). I believe that means that winex11.so itself fails to load, possibly because libX11.so or some dependency failed to load. I don't think that's diagnosable any further on the Wine side.
Added the patch, so now: ... 0074:err:module:build_module loaded L"\??\C:\windows\system32\explorer.exe" 00007FFFFE223790 0000000140000000 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0070:0074:DllMain: before DisableThreadLibraryCalls 0070:0074:DllMain: before __wine_init_unix_call 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0074:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0074:err:winediag:nodrv_CreateWindow L"The explorer process failed to start." 0074:err:systray:initialize_systray Could not create tray window ...
Hence __wine_init_unix_call() returned nonzero status. Does this agree with the assumption that winex11.so fails to load? If so, how could I diagnose the hypothetic lacked dependency?
https://bugs.winehq.org/show_bug.cgi?id=52500
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #75889|0 |1 is obsolete| |
--- Comment #43 from Bernhard Übelacker bernhardu@mailbox.org --- Created attachment 75903 --> https://bugs.winehq.org/attachment.cgi?id=75903 DEBUG-make-winex11.drv-DllMain-visible_v2.patch
Hence __wine_init_unix_call() returned nonzero status.
Maybe you could revert my last patch and apply this new version. That should show the returned status and might point to which function failed inside __wine_init_unix_call.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #44 from O. Nykyforchyn oleh.nyk@gmail.com --- Return value is c0000135.
https://bugs.winehq.org/show_bug.cgi?id=52500
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|dark.shadow4@web.de |
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #45 from O. Nykyforchyn oleh.nyk@gmail.com --- Created attachment 75904 --> https://bugs.winehq.org/attachment.cgi?id=75904 log with extra messages
Maybe a complete log can help.
Or should I add some channels to WINEDEBUG?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #46 from O. Nykyforchyn oleh.nyk@gmail.com --- (In reply to Bernhard Übelacker from comment #43)
Created attachment 75903 [details] DEBUG-make-winex11.drv-DllMain-visible_v2.patch
Hence __wine_init_unix_call() returned nonzero status.
Maybe you could revert my last patch and apply this new version. That should show the returned status and might point to which function failed inside __wine_init_unix_call.
Thanks to Your patch I seem to have found out the cause. Strange but it is indeed a dependency of winex11.so. Don't understand how but it affects loading of ntdll.
Would be nice if Wine gave some more clear clue in such cases. I leave Your patch for the future, who knows what can happen...
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #47 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to O. Nykyforchyn from comment #46)
Thanks to Your patch I seem to have found out the cause. Strange but it is indeed a dependency of winex11.so.
Could you please provide some more details what exactly you found out? So you were able to fix the issue for you? If yes how?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #48 from O. Nykyforchyn oleh.nyk@gmail.com --- (In reply to Bernhard Übelacker from comment #47)
(In reply to O. Nykyforchyn from comment #46)
Thanks to Your patch I seem to have found out the cause. Strange but it is indeed a dependency of winex11.so.
Could you please provide some more details what exactly you found out? So you were able to fix the issue for you? If yes how?
Nothing interesting, just a *.so in a nonstandard location due to an installation error. Put it in a correct place, ldconfig, and that's it.
But I still don't understand why it affected loading ntdll, sorry for my ignorance.
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #49 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to O. Nykyforchyn from comment #48)
(In reply to Bernhard Übelacker from comment #47)
(In reply to O. Nykyforchyn from comment #46)
Thanks to Your patch I seem to have found out the cause. Strange but it is indeed a dependency of winex11.so.
Could you please provide some more details what exactly you found out? So you were able to fix the issue for you? If yes how?
Nothing interesting, just a *.so in a nonstandard location due to an installation error. Put it in a correct place, ldconfig, and that's it.
But I still don't understand why it affected loading ntdll, sorry for my ignorance.
Can you please add the name of the *.so and the location. Maybe you even know where this file originated from in the first place?
https://bugs.winehq.org/show_bug.cgi?id=52500
--- Comment #50 from O. Nykyforchyn oleh.nyk@gmail.com --- (In reply to Bernhard Übelacker from comment #49)
(In reply to O. Nykyforchyn from comment #48)
(In reply to Bernhard Übelacker from comment #47)
(In reply to O. Nykyforchyn from comment #46)
Thanks to Your patch I seem to have found out the cause. Strange but it is indeed a dependency of winex11.so.
Could you please provide some more details what exactly you found out? So you were able to fix the issue for you? If yes how?
Nothing interesting, just a *.so in a nonstandard location due to an installation error. Put it in a correct place, ldconfig, and that's it.
But I still don't understand why it affected loading ntdll, sorry for my ignorance.
Can you please add the name of the *.so and the location. Maybe you even know where this file originated from in the first place?
No, it is nothing related to Wine, at list to the mainstream, "vanilla" one, it is just a result of my experiments. I was sure that I reverted changes to the plain code completely, but a dependency was left in a Makefile for winex11, not used, but required. A shared library available at a compile time but not at run time.
Sorry for disturbing You. Anyway, I believe that it worth to add permanently some extra messages to winex11 code.
-
WineHQ Bugzilla