Remote desktop to a windows machine crashes immediatly

piedro · 2020-12-28 18:19:23

Hello!

Since 3 years I use KRDC or Remmina to access a bunch of windows machines.

This worked perfectly until a few month ago. I cannot pinpoint the exact moment it started to fail but now:

Every remote connection using RDP (working without issues before) immediatly crashes silently after showing the RDP window for less than a second. starting KDRC or Remmina from the console doesn't produce any error message just terminates the application without notice.

I tried with "rdesktop" and with "freerdp"... same result.
I tried on a clean gnome desktop also on KDE plasma... again the same result...

I can not find any information how to tackle this problem and would be very glad if someone could help here.

The arch Wiki recommends using freerdp, the remmina recommendation is to use rdesktop.

For context:

This is on arch latest, using proprietary nvidia graphics, fully updated. I access the remote network with openVPN.
If I start a virtual box running windows 10 i can connect from the virtual windows desktop to all these machines using the win10 builtin remote desktop client.

Any ideas?

Cheers, p.

p.s.: Teamviewer works flawlessly. But I can't use this for weekly maintenance.

Last edited by piedro (2020-12-28 18:23:19)

GeorgeJP · 2020-12-28 19:50:53

On my side everything works as expected.

Installed: KDE, remmina, krdc, freerdp
Not installed: rdesktop

seth · 2020-12-28 21:23:40

Do you have backtraces?
coredumpctl?
drkonqi?

piedro · 2020-12-29 14:14:58

Thx for your reply!

So at least it should be working... that's good news.

Her is my "coredumpctl list"

Mon 2020-12-28 18:16:57 CET 3753 1001 1001 11 error /usr/bin/ibus-daemon
Mon 2020-12-28 18:17:02 CET 4023 1001 1001 11 error /usr/bin/baloo_file
Mon 2020-12-28 19:34:34 CET 4682 1000 1000 11 present /usr/bin/remmina
Mon 2020-12-28 19:35:21 CET 5171 1000 1000 11 present /usr/bin/remmina
Mon 2020-12-28 19:39:39 CET 6922 1000 1000 11 present /usr/bin/remmina
Mon 2020-12-28 19:45:30 CET 9667 1000 1000 11 present /usr/bin/remmina

How do I access DrKonqi's crash reports?

It hasn't started when crashing nor do I have crash logs in "Documents" or my home directory.

Sry, I have never done that before...

p.

seth · 2020-12-29 14:31:34

DrKonqi (yo'll have to install it) kicks in an intercepts the signal when the (KDE) client crashes - i don't think there's a log.

But remmina looks promising, so inspect that backtrace.

piedro · 2020-12-29 18:05:43

Ah, sry, I should have been more exact... :

DrKonqi is installed and succeeds in interupting crashes I get from dolphin, systemsettings or other KDE applications.

It doesn't seem to get triggered by xorg or kwin crashes, also crashing Gtk applications seem not to get noticed by kcrash either. Now, KRDC obviously is a KDE application but it still doesn't trigger the crash dialog. Remmina does neither.

Some applications like Kodi dump a crash log in the home directory. But I do not know if xorg, wayland or kwin do as well when they crash...

That's why I posted the question... - I can't figure out how to tackle the search for the error causing the crash...

I think I already tried two or three remmina versions.

Which working version of remmina do you use?

thx anyway!

Last edited by piedro (2020-12-29 18:07:58)

piedro · 2020-12-29 19:23:01

Little addition:

- I deleted all user cache files for remmina and also renamed the remmina relalted folders in ~/.config and ~/.local
- I tried to access a local virtual machine with windows10 pro: same result, immediate crash without any hint or crash file
- I used a new user account with a "fresh" user folder: both KDRC and Remmina crashed again

For now, I am convinced now it is freerdp problem.

How should I proceed?

ty, p.

GeorgeJP · 2020-12-29 20:35:48

piedro wrote:

Which working version of remmina do you use?

Default arch way is use latest version. Your system should be updated before asking for help.

piedro wrote:

How should I proceed?

Provide dump info for remmina crash (coredumpctl) and journal info.

seth · 2020-12-29 21:22:10

https://wiki.archlinux.org/index.php/Co … _core_dump

piedro · 2020-12-30 15:11:59

@Seth: Ok, thx!

Here it is - I just used xfreerdp on the command line with the same resulting segfault:

zsh: segmentation fault (core dumped)  xfreerdp /v:192.168.163.202

> coredumpctl info 382701
           PID: 382701 (xfreerdp)
           UID: 1000 (piedro)
           GID: 1000 (piedro)
        Signal: 11 (SEGV)
     Timestamp: Wed 2020-12-30 15:56:37 CET (2min 44s ago)
  Command Line: xfreerdp /v:192.168.173.244
    Executable: /usr/bin/xfreerdp
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-\x2fusr\x2fbin\x2fyakuake-e9da6f2aad7e4a89911278afe>
          Unit: user@1000.service
     User Unit: app-\x2fusr\x2fbin\x2fyakuake-e9da6f2aad7e4a89911278afeecd7040.scope
         Slice: user-1000.slice
     Owner UID: 1000 (piedro)
       Boot ID: ca3f6bae03d8428c8f3d8d639f35fa32
    Machine ID: 510ac12913e343deb6a09f50e5fc264f
      Hostname: archie
       Storage: /var/lib/systemd/coredump/core.xfreerdp.1000.ca3f6bae03d8428c8f3d8d639f35fa32.382701.1609340197000000.zst
       Message: Process 382701 (xfreerdp) of user 1000 dumped core.
                
                Stack trace of thread 382702:
                #0  0x00007f1b58fd2615 raise (libc.so.6 + 0x3d615)
                #1  0x00007f1b5940323e n/a (libfreerdp2.so.2 + 0x2d23e)
                #2  0x00007f1b58fd26a0 __restore_rt (libc.so.6 + 0x3d6a0)
                #3  0x00007f1b5968f210 XDisplayString (libX11.so.6 + 0x2f210)
                #4  0x00007f1b50720c07 __vaDriverInit_1_10 (vdpau_drv_video.so + 0x6c07)
                #5  0x00007f1b5446cc39 n/a (libva.so.2 + 0x3c39)
                #6  0x00007f1b5446fcaf vaInitialize (libva.so.2 + 0x6caf)
                #7  0x00007f1b5701ba3e n/a (libavutil.so.56 + 0x2ca3e)
                #8  0x00007f1b57016e7f av_hwdevice_ctx_create (libavutil.so.56 + 0x27e7f)
                #9  0x00007f1b594d8fd6 n/a (libfreerdp2.so.2 + 0x102fd6)
                #10 0x00007f1b594d3906 h264_context_new (libfreerdp2.so.2 + 0xfd906)
                #11 0x00007f1b59466068 freerdp_client_codecs_prepare (libfreerdp2.so.2 + 0x90068)
                #12 0x00007f1b5946d63a n/a (libfreerdp2.so.2 + 0x9763a)
                #13 0x00007f1b59460aa4 freerdp_connect (libfreerdp2.so.2 + 0x8aaa4)
                #14 0x0000557048deb81d n/a (xfreerdp + 0x1d81d)
                #15 0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #16 0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #17 0x00007f1b59095293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 382701:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b591988a2 WaitForSingleObject (libwinpr2.so.2 + 0x3a8a2)
                #2  0x0000557048dd4122 n/a (xfreerdp + 0x6122)
                #3  0x00007f1b58fbd152 __libc_start_main (libc.so.6 + 0x28152)
                #4  0x0000557048dd419e _start (xfreerdp + 0x619e)
                
                Stack trace of thread 382719:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b59198df6 WaitForMultipleObjects (libwinpr2.so.2 + 0x3adf6)
                #2  0x00007f1b591d7be7 n/a (libwinpr2.so.2 + 0x79be7)
                #3  0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #4  0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #5  0x00007f1b59095293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 382703:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b591988a2 WaitForSingleObject (libwinpr2.so.2 + 0x3a8a2)
                #2  0x00007f1b59574bf4 n/a (libfreerdp-client2.so.2 + 0x29bf4)
                #3  0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #4  0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #5  0x00007f1b59095293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 382721:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b59198df6 WaitForMultipleObjects (libwinpr2.so.2 + 0x3adf6)
                #2  0x00007f1b591d7be7 n/a (libwinpr2.so.2 + 0x79be7)
                #3  0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #4  0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #5  0x00007f1b59095293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 382722:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b59198df6 WaitForMultipleObjects (libwinpr2.so.2 + 0x3adf6)
                #2  0x00007f1b591d7be7 n/a (libwinpr2.so.2 + 0x79be7)
                #3  0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #4  0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #5  0x00007f1b59095293 __clone (libc.so.6 + 0x100293)
                
                Stack trace of thread 382720:
                #0  0x00007f1b5908a46f __poll (libc.so.6 + 0xf546f)
                #1  0x00007f1b59198df6 WaitForMultipleObjects (libwinpr2.so.2 + 0x3adf6)
                #2  0x00007f1b591d7be7 n/a (libwinpr2.so.2 + 0x79be7)
                #3  0x00007f1b591d9732 n/a (libwinpr2.so.2 + 0x7b732)
                #4  0x00007f1b58f4c3e9 start_thread (libpthread.so.0 + 0x93e9)
                #5  0x00007f1b59095293 __clone (libc.so.6 + 0x100293)

Can you identify the problem here?

thx a lot, p.

Last edited by piedro (2020-12-30 15:13:07)

seth · 2020-12-30 15:21:05

Smells related to https://bbs.archlinux.org/viewtopic.php?id=258759 - nvidia GPU?

piedro · 2020-12-30 16:19:21

:-( ... indeed, it does smell like that...!

But I do not think I understand the discussion correctly...

If I continue to use libva-vdpau I will not be able to use xfreerdp?
Or is it possible to deactivate libva-vdpau just for xfreerdp?

Since I really need these connections up and running would the whole issue likely go away by simply grabbing a radeon supported AMD graphics card?

Thx for your advice!

Cheers, p.

piedro · 2020-12-30 16:35:08

There is another thought... :

Since there is another built in intel i5 4690 graphics chip, would it be possible to run another X-session with another user account on a secondary monitor without using libva-vdpau-driver on the secondary graphics output?

The idea would be to run all the RDP sessions from this secondary user account on a side monitor.

Don't get me wrong, - I am not asking you to provide me with a solution here.
I am just curious if this could be done and whether you would think it's worth the trouble.

Though thinking about it, it's probably the cleaner solution to just throw 150 bucks at AMD, grab a radeon chip card and be done with Nvidia for good!

Thanks again and have a great new year!

Cheers,
p.

seth · 2020-12-30 16:39:49

https://wiki.archlinux.org/index.php/Ha … celeration

lspci
vainfo
echo $XDG_SESSION_TYPE

Edit: also your xorg log.
We need to first establish the environment, could be as easy as selecting the proper vapi driver.

Last edited by seth (2020-12-30 16:45:06)

piedro · 2020-12-30 21:04:08

That sounds promising!

Though I have to postpone for the moment and work from a virtual system to connect via RDP for the moment as I am right now stuck in the end-of-year crunch... but I will come back to this when time allows...

So for the moment I leave this thread open if you don't mind.

Have a great new year's eve and a happy new year!
p.

Arch Linux

#1 2020-12-28 18:19:23

Remote desktop to a windows machine crashes immediatly

#2 2020-12-28 19:50:53

Re: Remote desktop to a windows machine crashes immediatly

#3 2020-12-28 21:23:40

Re: Remote desktop to a windows machine crashes immediatly

#4 2020-12-29 14:14:58

Re: Remote desktop to a windows machine crashes immediatly

#5 2020-12-29 14:31:34

Re: Remote desktop to a windows machine crashes immediatly

#6 2020-12-29 18:05:43

Re: Remote desktop to a windows machine crashes immediatly

#7 2020-12-29 19:23:01

Re: Remote desktop to a windows machine crashes immediatly

#8 2020-12-29 20:35:48

Re: Remote desktop to a windows machine crashes immediatly

#9 2020-12-29 21:22:10

Re: Remote desktop to a windows machine crashes immediatly

#10 2020-12-30 15:11:59

Re: Remote desktop to a windows machine crashes immediatly

#11 2020-12-30 15:21:05

Re: Remote desktop to a windows machine crashes immediatly

#12 2020-12-30 16:19:21

Re: Remote desktop to a windows machine crashes immediatly

#13 2020-12-30 16:35:08

Re: Remote desktop to a windows machine crashes immediatly

#14 2020-12-30 16:39:49

Re: Remote desktop to a windows machine crashes immediatly

#15 2020-12-30 21:04:08

Re: Remote desktop to a windows machine crashes immediatly

Board footer