[Bug 41713] New: Explorer.exe is wrong when started from the process creating the Wine prefix
https://bugs.winehq.org/show_bug.cgi?id=41713 Bug ID: 41713 Summary: Explorer.exe is wrong when started from the process creating the Wine prefix Product: Wine Version: 1.9.8 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- To reproduce this do the following: rm -rf ~/.wine cd dlls/shell32/tests rm shelldispatch.ok make shelldispatch.ok This normally results in the following failure: shelldispatch.c:624: Test failed: got 0x80040152 Which corresponds to the following line: ok(hr == S_OK, "got 0x%08x\n", hr); /* TODO: remove when explorer startup with clean prefix is fixed */ if (hr != S_OK) return; The workaround is to ensure the Wine prefix has been created before running the test: rm -rf ~/.wine ./wine hostname ./server/wineserver -w cd dlls/shell32/tests rm shelldispatch.ok make shelldispatch.ok Note that wt-daily is now implementing this workaround (see https://github.com/fgouget/wt-daily). -- 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=41713 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- So the problem here is that the ShellWindows class belongs to explorer.exe, and must be registered as local server by explorer.exe. wineboot does the following things in order: * create a dialog window notifying the user that Wine is updating its prefix * update the prefix, with rundll32.exe * start the application Both creating this dialog window, and using rundll32.exe (for reasons I am unsure of) start explorer.exe, which attempts to register the ShellWindows class. This fails, because in order to do this we need the marshalling classes, and those haven't been registered yet. This is what's responsible for the error messages that get printed on every startup: err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} err:ole:marshal_object couldn't get IPSFactory buffer for interface {6d5140c1-7436-11ce-8034-00aa006009fa} err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004002 err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 80004002 err:ole:get_local_server_stream Failed: 80004002 err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} err:ole:marshal_object couldn't get IPSFactory buffer for interface {6d5140c1-7436-11ce-8034-00aa006009fa} err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80004002 err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, 80004002 err:ole:get_local_server_stream Failed: 80004002 The most obvious solution, as it seems to me, is to start explorer.exe a third time in wineboot.exe, to ensure that those classes get registered. -- 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=41713 --- Comment #2 from Nikolay Sivov <bunglehead(a)gmail.com> --- The actual issue I think was that registry is not fully populated by the time we try to access interface/proxy keys. -- 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=41713 --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Nikolay Sivov from comment #2)
The actual issue I think was that registry is not fully populated by the time we try to access interface/proxy keys.
Right, isn't that what I said? Or am I wrong somehow? -- 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=41713 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- (In reply to Zebediah Figura from comment #3)
(In reply to Nikolay Sivov from comment #2)
The actual issue I think was that registry is not fully populated by the time we try to access interface/proxy keys.
Right, isn't that what I said? Or am I wrong somehow?
Yes, sorry, I guess I skipped important part when reading your comment. -- 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=41713 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #5 from Fabian Maurer <dark.shadow4(a)web.de> --- *** Bug 45232 has been marked as a duplicate of this bug. *** -- 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=41713 --- Comment #6 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 45600 has been marked as a duplicate of this bug. *** -- 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=41713 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Explorer.exe is wrong when |Initial 'explorer' process |started from the process |fails to register/run |creating the Wine prefix |ShellWindows class local | |COM server in new | |WINEPREFIX due to | |incomplete registry data CC| |focht(a)gmx.net Component|-unknown |programs --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. I've encountered this in bug 45600 again, see https://bugs.winehq.org/show_bug.cgi?id=45600#c3 If you don't mind I refine the summary line a bit more. It's not easy to find/remember in Bugzilla. I suspect a number of apps suffering from this and users currently just get away by chance: * WINEPREFIX recycling (using existing prefix) * manual bootstrapping/creation of WINEPREFIX * unelevated process starts using "ShellExecuteFromExplorer" method happen separately, after installer has terminated (launcher) How about propagating the HRESULT from 'shellwindows_init' to 'manage_desktop' caller and let the process terminate if the COM server fails to register/run due to incomplete registry data? This also ensures that the "root" instance which can't run a COM server by design (only pumps messages) is gone. Then either let the next (UI) process that needs the desktop window automatically bootstrap 'explorer.exe' process again or do it explicitly in 'wineboot' at late stage. At that point all the proxy data is in registry. https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop.... https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop.... https://source.winehq.org/git/wine.git/blob/HEAD:/programs/explorer/desktop.... $ wine --version wine-5.0-144-g9a9a1821a3 Regards -- 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=41713 --- Comment #8 from Anastasius Focht <focht(a)gmx.net> --- Hello again, adding another way to reproduce the problem without even having tests compiled. Taken from my analysis https://bugs.winehq.org/show_bug.cgi?id=45600#c3 --- snip --- # run against existing WINEPREFIX # 9ba05972-f6a8-11cf-a442-00a0c90a8f39 -> CLSID_ShellWindows $ while true ; do wine cmd.exe /c "echo test > \\\\.\\pipe\\{9ba05972-f6a8-11cf-a442-00a0c90a8f39}" ; sleep 1 ; done 0034:fixme:ntdll:server_get_file_info Unsupported info class 14 Invalid function. 0036:fixme:ntdll:server_get_file_info Unsupported info class 14 Invalid function. ... # kill explorer process/local COM server ... File not found. --- snip --- 'Invalid function.' -> ok, named pipe can be opened 'File not found.' -> error, named pipe does not exist (COM server not running) If this is run against a newly created WINEPREFIX it will always fail. Just use some builtin app to bootstrap and keep it from being shut down. Regards -- 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=41713 --- Comment #9 from Zebediah Figura <z.figura12(a)gmail.com> --- Just to add another interesting variable to this, I have a set of patches which actually uses IShellWindows for its intended purpose—that is, to locate existing Explorer windows browsing a given path so that they can be brought to foreground instead of duplicated. This naturally fails with the first window, because explorer.exe isn't started until a window is created. I don't have a good solution for this yet. -- 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=41713 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xantares09(a)hotmail.com --- Comment #10 from Nikolay Sivov <bunglehead(a)gmail.com> --- *** Bug 49918 has been marked as a duplicate of this bug. *** -- 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=41713 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch -- 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=41713 --- Comment #11 from François Gouget <fgouget(a)codeweavers.com> --- This bug is still present in Wine 6.1 (433b9081ba7c). -- 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=41713 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24(a)gmail.com --- Comment #12 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 50327 has been marked as a duplicate of this bug. *** -- 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla