Package: x2goclient

Version: 4.1.0.0

Steps to reproduce:

1. Fire up x2go client

2. Establish a session

3. Session starts fine and all is well

3. Stop working and walk away and, due to IT policy, Windows screen will lock after 15 minutes of inactivity

4. Ctrl-Alt-Delete and log back into Windows

5. Find a popup error dialog indicating vcxsrv.exe crashed. The runtime error Windows popup message dialog says:

=========================================================

Microsoft Visual C++ Runtime Library

Program:

C:\Users\mpetronic\<path-to-my-install>\VcXsrv\vcxsrv.exe

R6025

- pure virtual function call

=========================================================

I can also force the crash if, after I establish a working x2go session, I Ctrl-Alt-Delete and lock my desktop manually. Same crash occurs when I log back in. To recover, I have to close the x2go client and restart it then I can restart my session. On the server side, my session is restarted just fine. Everything I had open there is restored. So, this is really annoying in that, every time I walk away from my PC for a short time, I know I have to reestablish all my sessions due to this crash.

I have further experimented and found this crash ONLY occurs when I run in -rootless configuration. I use that so that Alt-Tab works properly in my X session otherwise, when I Alt-Tab, I bounce back to windows in Windows. I basically use these settings set in the "X.Org Server Settings" dialog per (http://www.terheyden.com/blog/?p=202):

-rootless -notrayicon -clipboard -keyhook

Another tidbit of information is this crash only started to happen a few months ago but I made no changes to my x2go client installation or configuration. It started after a Windows update. Background: To access our remote systems at work, we have to use VMWare's VDI (Virtual Desktop Infrastructure). So, I have to first log into my corporate desktop, then start a VDI session using RSA key login, which gives me another Windows VDI desktop. On the VDI Windows instance, I have x2go installed in the portable way because I don't have admin access these to install it by running the setup program. Some months back, the VDI admins installed some Windows update per normal security patching. After that, this crash started happening. There happens to be a old VDI configuration that apparently has NOT been patched. If I log onto that instance, the crash does not occur. This crash happens with your latest version 4.1.0.0 and two previous versions so it appears to be related to something common to all versions. Since we still have this old (working) VDI configuration (until some realizes it and updates it) and new (broken) one, maybe there is a way I can help by getting you some information as to what is different between the two related to the Windows run time libraries installed?

I am glad to help in any way to get you information to help in debugging and fixing this issue. Please let me know what I can do to assist.

Thanks!