It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
I am baffled that this is even an issue! What a weird limitation to have -- and for what purpose?

Sadly, changing NoInteractiveServices to 0 did not solve it either.

According to the relevant log, C:\ProgramData\GOG.com\Galaxy\logs\CommunicationServiceInitialization.log, the issue boils down to GOG Galaxy apparently having a hardcoded reliance on the console session of the machine.

2021-09-16 01:48:02.187 [Information][ (0)] [TID 16284][comm_service]: Log started. Application version: 2.0.4.164 (2021-07-14 17:35).
2021-09-16 01:48:02.187 [Information][ (0)] [TID 16284][comm_service]: Operating system: Windows 8 6.2 (Build 9200) (IA32)
2021-09-16 01:48:02.515 [Warning][ (0)] [TID 16284][comm_service]: The process session ID is not equal to the current active console session ID while getting the process token from the process 'explorer.exe'.
2021-09-16 01:48:02.515 [Warning][ (0)] [TID 16284][comm_service]: Either no processes exist or the snapshot did not contain process information while searching for the process 'explorer.exe' and having checked 195 processes.
2021-09-16 01:48:02.515 [Error][ (0)] [TID 16284][comm_service]: Failure getting the token for 'explorer.exe' the current user's security identifier.
2021-09-16 01:48:02.515 [Warning][ (0)] [TID 16284][comm_service]: GetCurrentUserSID() failed
2021-09-16 01:48:02.515 [Information][ (0)] [TID 16308][comm_service]: [main] Stop serving due to lack of user authorization info
Suffice to say that the RDP session IDs will never be equal to the current active console session ID of the system, which is why GOG Galaxy's "GetCurrentUserSID()" function apparently fails...

I... I have no idea why it's coded like this... I assume it's intended as a form of security barrier of sorts -- the service technically runs as NT AUTHORITY\SYSTEM and not as the user, and they apparently need to figure out which user started the service to ensure the authentication is handled properly, and so instead of implementing a solution that could handle secondary user sessions, they ended up hardcoding it to the console session of a machine.
Post edited September 22, 2021 by Aemony
My logs show the exact same thing. This is the first thread I've seen that actually has real troubleshooting info in it, hopefully GOG will fix it. This is one of the only applications I've ever used that can't function properly in an RDP session. I vaguely recall the old ironkey unlocker being borked, but certainly nothing this big/mainstream.

I'm currently looking for different game library/launcher as really need to do my organization via RDP. Not a huge deal, but I'd rather be using GOG. The more time I spend in the GOG client, the more likely I am to impulse buy games there :)
OK, so I have some potential workarounds. Only limited testing, I haven't tried starting games or anything since I'm only interested in installing/organizing. For all I know it'll crash 15 minutes from now. Issue is this communication process will only run when it detects you're on the console session. So, the idea is to start it up on the console session and then switch to RDP.

1) Most secure - walk up to system, log in, start GOG, then use RDP
2) This is likely secure, but running another service always adds extra attack area - install VNC, start it in VNC, then switch to RDP
3) The least secure way, the only one I've actually tested: Set up windows auto login and make sure gog is set to auto start and save its login info. Then give it an extra minute after a boot/reboot to make sure the system is logged in and gog is running. You can't log in before GOG is running or this won't work. Auto login stores your password with reversible encryption in the registry. So there be dragons. If you still want to proceed, you can use the Systernals auto login tool to set up the automatic login. Google it, dunno if I'm allowed to share links. Systernals tools will be on the Microsoft site. If you're going to go this route, at least make sure that you don't use that PC password for anything else.


If GOG crashes or you quit it, you will have to start it from a console again. Assuming GOG doesn't crash on you a lot, 3 requires no work after initial setup, but that password in the registry really makes me nervous. I think I'm going to install VNC cuz I'm too lazy to get up and do 1.

Again, I've only tested #3, YMMV.
> Most secure - walk up to system, log in, start GOG, then use RDP

Doesn't work. You can use the client but not launch games.

> I... I have no idea why it's coded like this... I assume it's intended as a form of security barrier of sorts

Seems like half-baked security to me. I can't think of any reason why Galaxy could not run under the current user account.
Browsers, Steam, VSCode, media players, games - everything works except for Galaxy.

I would not be surprised if this is actually a vulnerability.
Also not surprised if some engineer of questionable skill initially used it as a workaround and now either nobody wants to touch it or nobody cares because who uses RDP anyway and "We have our season ID check there anyway, it's gonna be fiiine..."
Have been having this issue for weeks and now I know why. This is incredibly annoying.
Any new about this bug? I have the same problem...
I have the same problem.
The issue with RDP persist for years now, dating back to the old Galaxy Client. GoG are aware of that but explicitly said they are not gonna spend effort to fix it. This is kind of stupid as I almost always upon a release of a game I wait I log in from my office and start game install so it is done when I get back home.
Also as a user of the Vivaldi browser (Chromium based) their store site has issues with it so it is one of the few browsers I use firefox to open.
As a workaround, using Parsec or Moonlight works. Has the advantage that you also can play games remotely, but requires you to be able to install the client and have some bandwidth available.
I have been struggling for an hour trying to figure out the problem and just stumbled on this topic. I'm amazed at how backwards GoG can be at times... wow, years just... not caring.
Oh man, I just want to backup my game installers using my storage server, instead of via my desktop. What's the point of this restriction?
Having the same problem here on a NUC with Win10 21H2 and installing stuff via RDP.
I managed to install the games by downloading the 500kb bootstrap installers and running them. Error message popped up but installation continued in the background as long as I did not close the error message dialog.

Unfortunately using Sysinternals Autologin to perform an automatic login did not help. I WAS able to run an previously installed game, but starting the GalaxyCommunications service manually still yields the error "Service cannot start" and the above mentioned entries in the logfile that the SID of the user cannot be determined. Same behavior when I run GOG Galaxy manually.

Very frustrating issue and hard to understand why this can't be fixed easily.
You can start the client and get the updates installed if you are quick enough to get it going, just don't click OK to dismiss the error (which WILL close GOG) and instead just leave it open - GOG will happily download and install then.

edit: spelling errors
Attachments:
gog-error.png (430 Kb)
Post edited November 08, 2022 by joat42
So GOG fixed this problem now?
At least it works for me, starting games and everything.

At least im going to start buying games again.
avatar
Teiturhar: So GOG fixed this problem now?
At least it works for me, starting games and everything.

At least im going to start buying games again.
No. It still exists and is annoying as hell. Every other software works with RDP.