Archisteamfarm: Command-line arguments in ImagePath are ignored while running ASF as a service

[zypA13510]

Hello,

First of all

The wiki page doesn't state clearly how to correctly specify command line arguments while running ASF as a service.

If installation went successfully, you can now find your ASF service in Services and configure it further, such as if it should start Manually or Automatically etc.

Issue description:

So I assume appending the arguments after the original ImagePath _(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ArchiSteamFarm\\ImagePath)_ is ok, as it is with other services:

So the result looks like this:

And when I start the service, it launched with the arguments indeed:

But then it seems the arguments are completely ignored, WCF is not listening on port 1242, and the AES private key is never used. (Notice the CryptographicException and the following "_LogOn requires a username and password to be set in 'details'._" in the log) log-error.zip

Steps to reproduce:

1. Download both the ASF-Service.exe and the ASF.zip from the latest stable release page.

2. Extract files from ASF.zip to somewhere on the disk. (In this instance, I used "D:\Steam\~tools\Archi's Steam Farm")

3. Properly configure the client, and test it by running ASF.exe (with command line arguments in this case).

4. Install ASF-Service.exe as a service.

5. Open registry editor of your choice, and navigate to _HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ArchiSteamFarm_, change _ImagePath_ to "D:\Steam\~tools\Archi's Steam Farm\ASF-Service.exe" --server --cryptkey=XXX

6. Start service ArchiSteamFarm via services.msc or net start command.

• Expected behavior: ASF accepts the command-line arguments, starts listening to port 1242 (WCF) and decrypts password using the key specified.

• Current behavior: ASF ignores the command-line arguments, doesn't listen to any port and throws an exception while trying to decrypt the password.

Environment:

• ArchiSteamFarm V2.1.7.9
• Windows 10 Pro Version 1607 Build 14393.576
• .Net Framework 4.6.2
• Steam built Dec 19, 2016

Other testings:

1. Running ASF-Service.exe in the command line with same arguments starts correctly:
   

2. In services.msc, starting the service with arguments filled in the _start parameters_ input will run correctly:
   

but it will not show command line arguments in task manager:

And most importantly, specifying command-line arguments here is one-time only. Proof

For your reference, I have included log from this situation as well: log-expected.zip

You should notice here the WCF correctly listened to port 1242 and logged the event.

Attachments

screenshot 1 - other services
screenshot 2 - my ASF service config
screenshot 3 - taskmgr info via ImagePath
screenshot 4 - start via cmd
screenshot 5 - start via services.msc
screenshot 6 - taskmgr info via services.msc
log-error.zip
log-expected.zip

[JustArchi]

Thanks for very detailed bug report.

Based on this, it seems like I need to drop args provided by the service start, and instead get args from the environment. That's quite weird that official docs state something like this, but I guess there must be a reason for that.

I closed this issue as it should work, even though I didn't check the fix myself. Feel free to download latest automated AppVeyor build if you want to confirm that it solved your issue. Remember that you will need to re-install ASF service with new executable.

[JustArchi]

Also if everybody reported bugs like you did, we'd already be around version V17.7.3.0. I'm very happy to see that there are still people that put serious effort into making it easier for me to locate the culprit, even if it's very trivial like in this case (assuming the fix works). Double thanks for that! 🥇

[zypA13510]

Hi Archi,

Thanks, this fix works fine for me.

Also, I suggest updating the wiki to include how to update the command-line arguments for ASF-Service.

And btw, I think as a developer you have done pretty much for the community. I'm a developer myself, I understand sometimes it's hard to identify (or even to reproduce) the issue without enough detail. Glad I can help. 😄

Merry Christmas and happy New Year!