https://bugs.winehq.org/show_bug.cgi?id=50158
Bug ID: 50158 Summary: Oculus Runtime won't start: "Could not load file or assembly 'Daybreak'" Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: criteria32@gmail.com Distribution: ---
Created attachment 68674 --> https://bugs.winehq.org/attachment.cgi?id=68674 Crash log
Can be downloaded at oculus.com/setup or with this direct link: https://www.oculus.com/download_app/?id=1582076955407037
https://bugs.winehq.org/show_bug.cgi?id=50158
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.oculus.com/down | |load_app/?id=15820769554070 | |37 Ever confirmed|0 |1 Keywords| |download Status|UNCONFIRMED |NEEDINFO
--- Comment #1 from Austin English austinenglish@gmail.com ---
0170:err:module:open_builtin_file failed to load .so lib "/usr/lib32/wine/mp3dmod.dll.so" 0178:err:winediag:gnutls_initialize failed to load libgnutls, no support for encryption
Looks like a broken setup (likely missing 32-bit libraries).
Try installing (at least) 32-bit libgnutls.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #2 from criteria32@gmail.com --- I'm not sure why those errors are there, I'm pretty sure I already had libgnutls installed lol But I reinstalled and tried again in a fresh wineprefix. The gnutls errors go away but still the same Daybreak exception in the same spot.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #3 from Austin English austinenglish@gmail.com --- (In reply to criteria32 from comment #2)
I'm not sure why those errors are there, I'm pretty sure I already had libgnutls installed lol But I reinstalled and tried again in a fresh wineprefix. The gnutls errors go away but still the same Daybreak exception in the same spot.
Please attach the terminal output.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #4 from criteria32@gmail.com --- Created attachment 68691 --> https://bugs.winehq.org/attachment.cgi?id=68691 Fresh prefix, gnutls properly installed
Attached new log
https://bugs.winehq.org/show_bug.cgi?id=50158
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #5 from winetest@luukku.com --- indeed
Unhandled Exception: System.TypeLoadException: Could not load type of field 'Dawn.DawnController:_window' (4) due to: Could not load file or assembly 'Daybreak, Version=1.16.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. 0024:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0031FEA4
wine 5.21. I still don't have 5.22.
https://bugs.winehq.org/show_bug.cgi?id=50158
Jan jan_007@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jan_007@hotmail.com
--- Comment #6 from Jan jan_007@hotmail.com --- I tracked this down to a bug in Mono. OculusSetup has a custom AssemblyResolve callback used to load DLL files from embedded resources instead of from disk. Mono does not call the AssemblyResolve callback when the type is required, but the assembly can not be found. (Which is happening in this case).
The corresponding Issue on the mono github repo is https://github.com/mono/mono/issues/11319
https://bugs.winehq.org/show_bug.cgi?id=50158
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |mscoree See Also| |https://github.com/mono/mon | |o/issues/11319 Status|NEEDINFO |NEW CC| |z.figura12@gmail.com
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to Jan from comment #6)
I tracked this down to a bug in Mono. OculusSetup has a custom AssemblyResolve callback used to load DLL files from embedded resources instead of from disk. Mono does not call the AssemblyResolve callback when the type is required, but the assembly can not be found. (Which is happening in this case).
The corresponding Issue on the mono github repo is https://github.com/mono/mono/issues/11319
Nice, thanks for debugging.
https://bugs.winehq.org/show_bug.cgi?id=50158
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net URL|https://www.oculus.com/down |https://web.archive.org/web |load_app/?id=15820769554070 |/20201017013439/https://www |37 |.oculus.com/download_app/?i | |d=1582076955407037
https://bugs.winehq.org/show_bug.cgi?id=50158
nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
--- Comment #8 from nekoNexus@protonmail.ch --- Installing dotnet 48 into the prefix fixes this issue
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #9 from nekoNexus@protonmail.ch --- Well, to be more accurate, it renders a black window
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #10 from Esme Povirk madewokherd@gmail.com --- The pattern it uses to install the AssemblyResolve hook looks like one we should be able to handle. It's done in a static constructor of the entry point class, and the entry point class does not itself reference any classes that require the AssemblyResolve hook.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #11 from Esme Povirk madewokherd@gmail.com --- The trick is that we need it to execute the static constructor before it attempts to compile the entry point method.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #12 from Esme Povirk madewokherd@gmail.com --- That gets it past the initial error, but now I get: [ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'System.DirectoryServices.AccountManagement, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. File name: 'System.DirectoryServices.AccountManagement, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' at Dawn.DawnAnalytics.BuildSubstitutions () [0x00000] in <2a018e1517ef4abca1e2507bb32143fc>:0 at Dawn.DawnAnalytics.Initialise (Dawn.Flags flags, Daybreak.Net.Networker networker) [0x00010] in <2a018e1517ef4abca1e2507bb32143fc>:0 at Dawn.DawnController..ctor (Dawn.Flags flags, Dawn.DawnController+Action action) [0x0004b] in <2a018e1517ef4abca1e2507bb32143fc>:0 at Dawn.DawnController.ActualMain (System.String[] args) [0x00062] in <2a018e1517ef4abca1e2507bb32143fc>:0
System.DirectoryServices.AccountManagement is part of .NET Framework that's not provided by Mono. It's in .NET Core so we may be able to import it.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #13 from Esme Povirk madewokherd@gmail.com --- With that dll in place, the dll loads and gets to a page that says "Update Required". I think it's because this WMI query fails:
[00000118: 2.33194 10] ENTER:c System.Management.ObjectQuery:.ctor (string)(this:028a7b30[System.Management.ObjectQuery OculusSetup.exe], [STRING:03d04d20:SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID = "KB2670838" OR HotFixID = "KB3033929"])
Those can be manually added to the quickfixengineering table in dlls/wbemprox/builtin.c, but after that it fails saying "Not Enough Space". I think that's due to this unimplemented ioctl:
0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 2d0c14 (device=2d access=0 func=305 method=0)
That appears to be IOCTL_STORAGE_GET_HOTPLUG_INFO. The program also shows an exception in Daybreak.Win32.Kernel.IsInternal, and it makes sense that this ioctl would be used to check for an internal drive.
Both of these errors most likely exist with .NET Framework too, so that should probably be a separate bug.
The rendering issue with .NET Framework may be bug 50743. I'd guess that if you work around that, you should see the same problems in .NET Framework.
I'll clean up the dll import in wine-mono and commit that. Once that and the fix for the static class constructor is in and there's another release, that should fix this bug.
https://bugs.winehq.org/show_bug.cgi?id=50158
Esme Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |1f8eb4a9c28417ee98f90aa8a5a | |95177088d082a Status|NEW |RESOLVED
--- Comment #14 from Esme Povirk madewokherd@gmail.com --- Fixed in Wine Mono 7.2.0. We'll need a new bug for the remaining issues that are not caused by Wine Mono.
https://bugs.winehq.org/show_bug.cgi?id=50158
--- Comment #15 from Esme Povirk madewokherd@gmail.com --- Looks like the further issues were already reported in bug 52300.
https://bugs.winehq.org/show_bug.cgi?id=50158
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.6.