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@winehq.org Reporter: winehq@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
https://bugs.winehq.org/show_bug.cgi?id=50168
Michael Setzer II mikes@kuentos.guam.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikes@kuentos.guam.net
--- Comment #1 from Michael Setzer II mikes@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@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amnesiac97@hotmail.com
--- Comment #2 from Dmitry Timoshkov dmitry@baikal.ru --- *** Bug 50604 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=50168
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=50168
testing.tigerwolf@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |testing.tigerwolf@mail.com
--- Comment #3 from testing.tigerwolf@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"
https://bugs.winehq.org/show_bug.cgi?id=50168
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |hans@meelstraat.net Regression SHA1| |e9090e1c903578b30118ce9559c | |1824361abc6da Ever confirmed|0 |1 Keywords| |regression
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru --- Confirming.
This is a regression caused by
e9090e1c903578b30118ce9559c1824361abc6da is the first bad commit commit e9090e1c903578b30118ce9559c1824361abc6da Author: Hans Leidekker hans@codeweavers.com Date: Mon Sep 7 14:10:13 2020 +0200
advapi32: Reimplement SystemFunction036 using system interrupt information.
Signed-off-by: Hans Leidekker hans@codeweavers.com Signed-off-by: Alexandre Julliard julliard@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #5 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #6 from Dmitry Timoshkov dmitry@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?
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #7 from Hans Leidekker hans@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?
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #8 from Dmitry Timoshkov dmitry@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #9 from Hans Leidekker hans@meelstraat.net --- Created attachment 69618 --> https://bugs.winehq.org/attachment.cgi?id=69618 patch
Can you try this patch?
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #10 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #9)
Created attachment 69618 [details] patch
Can you try this patch?
This patch works. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #11 from Dmitry Timoshkov dmitry@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e6407c39bab62838081f30868cb | |2ac1362029bdf Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #12 from Hans Leidekker hans@meelstraat.net --- Fixed by e6407c39bab62838081f30868cb2ac1362029bdf.
https://bugs.winehq.org/show_bug.cgi?id=50168
--- Comment #13 from Dmitry Timoshkov dmitry@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.
https://bugs.winehq.org/show_bug.cgi?id=50168
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.5.
https://bugs.winehq.org/show_bug.cgi?id=50168
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=50168
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #15 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.2.
-
WineHQ Bugzilla