[Bug 50168] New: Error when running notepad.exe: Failed to start RpcSs service
https://bugs.winehq.org/show_bug.cgi?id=50168 Bug ID: 50168 Summary: Error when running notepad.exe: Failed to start RpcSs service Product: Wine Version: 5.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)lv.net.nz Distribution: --- When I run `wine notepad.exe` from my `~/.wine/drive_c/windows` I get the following error: 0060:err:ole:start_rpcss Failed to start RpcSs service I am running Debian 10 on x86_64, and have installed winehq-devel from the winehq repository. I've also tried using winehq-staging. I'm using a fresh ~/.wine. The same error shows up on explorer.exe. Interestingly, the error disappears if I run and then quit explorer.exe: explorer.exe crashes on exit (wine: Unhandled page fault on read access to 0000000000000000 at address 0000000000409FC7 (thread 00d0)) and leaves wineserver and a couple of winedevice.exe processes running. Happy to provide more info on the explorer.exe crash if that helps. -- 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=50168 Vitaly Lipatov <lav(a)etersoft.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lav(a)etersoft.ru -- 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=50168 Michael Setzer II <mikes(a)kuentos.guam.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikes(a)kuentos.guam.net --- Comment #1 from Michael Setzer II <mikes(a)kuentos.guam.net> --- I get a similar message when I run Pegasus email program. 0070:err:ole:start_rpcss Failed to start RpcSs service It shows most of the time, but sometimes it doesn't. Program seems to run just fine. Did a test with running note.pad and first run gets the error, but second doesn't. Both eventually have a line that an rpcrt4.so file doesn't exist?? Sometimes getting 0070:err:ole:start_rpcss Failed to start RpcSs service But sometime not?? Simple test. strace wine notepad 2>out ; sleep 1; strace wine notepad 2>out2 ; ge out* First one gets error, second one doesn't? Searched system for rpcrt4.so and not found. Checked dnf whatprovides */rpcrt4.so and nothing returned. cat out | grep -i rpc | more 0070:err:ole:start_rpcss Failed to start RpcSs service lstat64("/home/msetzerii/.wine/dosdevices/c:/windows/syswow64/rpcrt4.dll", {st_mode=S_IFREG|0664, st_size=2480967, ...}) = 0 writev(3, [{iov_base="+\0\0\0(\0\0\0\0\0\0\0\0\0\20\200\5\0\0\0\1\0\0\0`\0\0\0\0\0\0\0"..., iov_len=64}, {iov_base="\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}, {iov_base="/usr/lib/wine/rpcrt4.dll", iov_len=24}], 3) = 104 stat64("/usr/lib/wine/rpcrt4.dll", {st_mode=S_IFREG|0644, st_size=2480967, ...}) = 0 openat(AT_FDCWD, "/usr/lib/wine/rpcrt4.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) [root(a)setzconote msetzerii]# cat out2 | grep -i rpc | more lstat64("/home/msetzerii/.wine/dosdevices/c:/windows/syswow64/rpcrt4.dll", {st_mode=S_IFREG|0664, st_size=2480967, ...}) = 0 writev(3, [{iov_base="+\0\0\0(\0\0\0\0\0\0\0\0\0\20\200\5\0\0\0\1\0\0\0`\0\0\0\0\0\0\0"..., iov_len=64}, {iov_base="\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}, {iov_base="/usr/lib/wine/rpcrt4.dll", iov_len=24}], 3) = 104 stat64("/usr/lib/wine/rpcrt4.dll", {st_mode=S_IFREG|0644, st_size=2480967, ...}) = 0 openat(AT_FDCWD, "/usr/lib/wine/rpcrt4.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) Also, notice that If I run wine notepad.exe as root, I never seem to see the message. Not sure if this is just a message that can be ignored, or if it is something. Messages I get when running Pegasus INTEL-MESA: warning: Ivy Bridge Vulkan support is incomplete 0070:err:ole:start_rpcss Failed to start RpcSs service With the 0070 line being their most of time, but sometimes not?? Thanks. Otherwise it is running great. Thanks for all the 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=50168 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amnesiac97(a)hotmail.com --- Comment #2 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- *** Bug 50604 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=50168 winetaste(a)gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste(a)gmx.net -- 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=50168 testing.tigerwolf(a)mail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |testing.tigerwolf(a)mail.com --- Comment #3 from testing.tigerwolf(a)mail.com --- Same kind of problem (0050:err:ole:start_rpcss Failed to start RpcSs service ) encounters in some bug descriptions: #26637 #44885 #50168 #50289 #50225 with always a similar behaviour : "unable to install the programm" -- 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=50168 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |hans(a)meelstraat.net Regression SHA1| |e9090e1c903578b30118ce9559c | |1824361abc6da Ever confirmed|0 |1 Keywords| |regression --- Comment #4 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- Confirming. This is a regression caused by e9090e1c903578b30118ce9559c1824361abc6da is the first bad commit commit e9090e1c903578b30118ce9559c1824361abc6da Author: Hans Leidekker <hans(a)codeweavers.com> Date: Mon Sep 7 14:10:13 2020 +0200 advapi32: Reimplement SystemFunction036 using system interrupt information. Signed-off-by: Hans Leidekker <hans(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> dlls/advapi32/crypt.c | 62 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 48 insertions(+), 14 deletions(-) However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32. The problem manifests in most (by not all) service entries missing in a freshly created ~/.wine/system.reg, and RpcSs is one of the missing services. Reverting the offending commit on top of wine-6.4, replacing open/read/close by _lopen/_lread/_lclose, and changing O_RDONLY to OF_READ, fixes the bug in wine-6.4 as well. -- 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=50168 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Dmitry Timoshkov from comment #4)
However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32.
Looks like a variation of bug 49938. The new path uses getrandom() if detected at build time, otherwise it falls back to opening /dev/urandom like we did before. So your build is probably from a newer system where getrandom() is available and kernel 2.6.32 is certainly too old to support it. -- 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=50168 --- Comment #6 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Hans Leidekker from comment #5)
(In reply to Dmitry Timoshkov from comment #4)
However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32.
Looks like a variation of bug 49938. The new path uses getrandom() if detected at build time, otherwise it falls back to opening /dev/urandom like we did before.
So your build is probably from a newer system where getrandom() is available and kernel 2.6.32 is certainly too old to support it.
Could we probably try to detect this situation at run-time, and fallback to old behaviour if appropriate? -- 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=50168 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Dmitry Timoshkov from comment #6)
(In reply to Hans Leidekker from comment #5)
(In reply to Dmitry Timoshkov from comment #4)
However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32.
Looks like a variation of bug 49938. The new path uses getrandom() if detected at build time, otherwise it falls back to opening /dev/urandom like we did before.
So your build is probably from a newer system where getrandom() is available and kernel 2.6.32 is certainly too old to support it.
Could we probably try to detect this situation at run-time, and fallback to old behaviour if appropriate?
We could, if we think it's worth it. Note that passing ac_cv_func_getrandom=no would work around the issue. I'm not sure what's reasonable here. Can you still run non-trivial apps on that kernel using a build configured for a modern system? -- 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=50168 --- Comment #8 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Hans Leidekker from comment #7)
(In reply to Dmitry Timoshkov from comment #6)
(In reply to Hans Leidekker from comment #5)
(In reply to Dmitry Timoshkov from comment #4)
However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32.
Looks like a variation of bug 49938. The new path uses getrandom() if detected at build time, otherwise it falls back to opening /dev/urandom like we did before.
So your build is probably from a newer system where getrandom() is available and kernel 2.6.32 is certainly too old to support it.
Could we probably try to detect this situation at run-time, and fallback to old behaviour if appropriate?
We could, if we think it's worth it. Note that passing ac_cv_func_getrandom=no would work around the issue. I'm not sure what's reasonable here. Can you still run non-trivial apps on that kernel using a build configured for a modern system?
Since I'm not a regular user of such a system I can't claim much, however that's a production environment, and reportedly everything worked well before that commit. -- 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=50168 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- Created attachment 69618 --> https://bugs.winehq.org/attachment.cgi?id=69618 patch Can you try this patch? -- 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=50168 --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Hans Leidekker from comment #9)
Created attachment 69618 [details] patch
Can you try this patch?
This patch works. Thanks! -- 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=50168 --- Comment #11 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Dmitry Timoshkov from comment #8)
(In reply to Hans Leidekker from comment #7)
(In reply to Dmitry Timoshkov from comment #6)
(In reply to Hans Leidekker from comment #5)
(In reply to Dmitry Timoshkov from comment #4)
However it's not trivial to reproduce. I had to run the built binaries on a virtualization server with OpenVZ kernel 2.6.32.
Looks like a variation of bug 49938. The new path uses getrandom() if detected at build time, otherwise it falls back to opening /dev/urandom like we did before.
So your build is probably from a newer system where getrandom() is available and kernel 2.6.32 is certainly too old to support it.
Could we probably try to detect this situation at run-time, and fallback to old behaviour if appropriate?
We could, if we think it's worth it. Note that passing ac_cv_func_getrandom=no would work around the issue. I'm not sure what's reasonable here. Can you still run non-trivial apps on that kernel using a build configured for a modern system?
Since I'm not a regular user of such a system I can't claim much, however that's a production environment, and reportedly everything worked well before that commit.
I should probably clarify, that while Hypervisor uses kernel 2.6.32, containers use kernels 3.2.0+, and run up to date Linux versions. -- 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=50168 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e6407c39bab62838081f30868cb | |2ac1362029bdf Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed by e6407c39bab62838081f30868cb2ac1362029bdf. -- 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=50168 --- Comment #13 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Hans Leidekker from comment #12)
Fixed by e6407c39bab62838081f30868cb2ac1362029bdf.
I've got a confirmation, that this commit fixed running Wine in a previously described configuration. Thanks Hans. -- 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=50168 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.5. -- 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=50168 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x -- 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=50168 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |--- --- Comment #15 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 6.0.x milestone from bug fixes included in 6.0.2. -- 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 (1)
-
WineHQ Bugzilla