Steam never understands when my game shuts down

Hello,

I'm using Steamworks.NET to implement Steam achievements, but I have a serious issue where, when running my game from Steam, Steam never understands when my game shuts down, so if for example I try to restart it I get a "Failed to start game (app already running)" message. This is not related to Unity's editor and happens even when I run a standalone build or the Steam build itself.

Steamworks.NET is correctly calling Shutdown when the game ends, so the problem is not there.

Anyone encountered the same issue and maybe has a solution?

 

If you're using PC press Ctrl + Alt + Del to access the Task Manager, shutdown your game, if it's still running in the task manager you're not shutting your game down properly.

I don't know anything about steam, just trying to lend a helping idea.

 

@N1warhead Thank you for the help but no: I'm developing a Steam game and it correctly shuts down (process and all). The problem is Steam not realizing it

 

Oh okay, was just making sure because sometimes we forget the basics when dealing with advanced stuff lol.
Wish I could furthur help, but I never delt with steam yet

 

It's the most time expensive market in the world, considering all the stuff you have to prepare (almost all optional, but still)

 

Check the issue tracker. It looks like this isn't an unheard of problem. You might just have to get dirty with this one.

 

I also stumbled across this problem and I might have the solution.
If you have, by any chance, the Unity Editor open, close it and the message should disappear.

 

@Mauri Thanks but it's not that. I should've specified in the main post that it happens even when I run a standalone build (or the Steam build itself).

@RockoDyne Trying to get dirty now and hoping to find a solution, whew.

 

Got the same problem. Anyone solved it yet?

 

Install wireshark and record your game's connection with steam. Look for the error in the wireshark log. Copy the error and report it to the Steam Developer Technical Support. From there I don't know if they keep you informed as what to do or if you must periodically remember to check the fix status yourself; uh assuming the wireshark log didn't reveal that you're code is the cause of the bug at which point you can fix it yourself.

 

Still have the same problem? Anyone?

 

I realized it happened only if I connected to Steam from Unity's editor. After that, Steam doesn't recognize the game shutting down even if you close and restart Steam itself.

 

Will try that, thanks

 

Just realized I have same problem. I use Application.Quit() to exit the game. But this doesn't tell Steam that the game isn't running anymore.

Maybe there's an extra step missing before quitting in Steam?

 

Guys, there's an issue with Unity editor, where adb.exe keeps running even after closing editor.

If adb.exe is running, you will get this issue in Steam. Kill abd.exe from Task Manager, while unity editor is closed, and hopefully that should fix it for some of you.

Just keep in mind Unity editor needs to be closed as you run your game from Steam, or else Steam will still show your game as running after you quit.

 

I was having this problem as well. Once I launch Unity and it connects to Steam, it doesn't seem to release the connection. I can't find the process that is causing it to hang so unfortunately I have to reboot to solve the problem.

 

I finally figured it out. It's the dumbest thing ever... guess what you open through Unity's asset browser... explorer windows. And then you use that explorer window for something else and suddenly your game never exits. Close your explorer windows and your game stops running.

That's why a reboot appears to be the only thing that fixes it because that's the only time you close your explorer windows! Note: "adb.exe" in Task Manager stated above is also a culprit indeed.

 

I just wanted to see if other people had this issue, and I guess it's been around for quite a while since this thread started in 2014. I did sort out that adb.exe was my issue mainly just based on it being weird that it was running at all - I'm not sure why Unity insists on starting it even if you're not actively doing Android work.

 

I just recently noticed this issue too. Running the game from my steam build works fine if there are no other development versions running at all. However it wasn't the Unity editor that causes the problem, it was Visual Studio attached to the editor. Once you have attached Visual Studio to your editor and run the program once even if you have disconnected it, steam seems to think that Visual Studio is the program that its running.

I noticed this because the Steam overlay kept trying to appear over my visual studio when using Shift+Tab.

In short try closing your development IDE, it may be that Steam thinks that the IDE is your app and its still running.

 

Couldn't be that simple. Could it? Been wracking my brain and the interwebs for 2 weeks on this.

 

One of the reasons is because Unity (annoyingly and unnecessarily) runs ADB (Android Debugger) in the background when you start Unity -- EVEN if you don't use Android. This persists beyond Unity. This means when you shut down Unity, ADB is start a spawn of the Unity process.

1. You need to kill adb.exe within your shutdown sequence if within the editor~

2. Yell at Unity for lazy coding for spawning adb.exe when we're not even using Android as a selected platform. All they'd need to do is check out platform and only include it if (android)

 

Anyone filed bug ?

 

I doubt anyone filed a bug - this is a relatively minor nuisance and at least to some degree not the fault of Unity at all. The issue with adb though is probably specific enough that it is actionable and worth a report.

 

Yep, since 2016:

https://issuetracker.unity3d.com/is...e-build-platform-set-to-standandalone-windows

Seems that it was fixed -- for 2017.1, go figure, even though it was reported a year ago in 5.x.

And I thought 5.6 was unstable, reading some horror stories about the freezing in 2017 and how the next .NET version was just sort of thrown in, more or less unusable if you don't want to freeze every few mins. Of course no one would upgrade for this little fix haha, but I've definitely looked into it.

I'd pay cash for a truly stable version, even though most enterprise software companies are generally expected to do that, it's a shame that Unity doesn't follow standard expectations when it comes to "stable releases". "Upgrade to the next version for fixes!", they say --oh, we forgot to mention the other 10k bugs we introduced and left untested. Buy the next version, it'll fix those! --oh, we forgot to...--<paradoxical loop continues>.

If it's like many of the other bugs, there's also a good chance it was just "marked" as fixed, hoping no one would notice, like many of the other "fixed" bugs

 

Not sure what relevance Baron Beartooth has because it won't mean the game is automatically fixed at all, or even if Rust will ever, ever move to that version.

 

This is not a Unity issue, it's a Steam issue. Starting the steam API will permanently mark the current process to be running for the "in-game" check. This spreads to any child process you spawn while the steam API is loaded. I believe it does not matter if you call the shutdown API, that only frees memory (does not unmark it).

So if you run the API in the editor, any process spawned has to be stopped (including the editor itself) before you'll stop being "in-game". Whether this is a spawned browser from the asset store, any program through opening an asset or ADB running doesn't matter.

 

If you talk about editor then its because Steam have a hard time understand which process that it should monitor. i usually just kill the steam client process when it fails to understand the game is not running

 

So it's Steam's fault that Unity unnecessarily creates a subprocess of ADB when no Android is present at all? And it was apparently fixed in 2017.x as a bug (should be a patch since it's existed for years), so it doesn't.... really make sense what you say. But hey.

 

Yeah the ADB for non-windows is a unity issue, sorry. I should've read better. (It's still sort of a steam issue though, it just gets worse when combined with the ADB issue)

 

I just came across the same issue. There was no adb in my Task Manager. I ended up restarting my computer, and my game was back to normal. I am pretty sure that it's Unity Editor's fault.

 

Did you also close any file explorer / web browser windows that may have been opened from within Unity? As others have pointed out, Steam also considers these.

Unrelated to Unity, this explains issues I've seen while using Steam in general.

If this is the case, to me that's pretty clearly a Steam thing because of the exact use cases mentioned. If a game opens a browser and I then go and do other stuff in that window, the game should be able to explicitly tell Steam that it's not running any more and Steam should respect that.

It could be worth checking to see if that's an issue in the Steam API, or the .NET wrapper.

 

As this thread popped up when I looked for my own notes for this issue (and those notes did not), and because it's probably also helpful for others, I'm posting this here:

My (summary) comment on OnDestroy SteamAPI.Shutdown() is NOT working #187, which links to Test (unity) app does not shut down properly. #13.

In a nutshell: When running the game inside Unity, any process that was started by Unity will keep the game "running" in Steam. That includes Visual Studio, Rider or any IDE that Unity opens. It also includes processes like adb.exe, or, as I found out after doing some process dependency investigation, VBCSCompiler.exe and conhost.exe. Or SteamVR. And of course, Unity itself still running (exiting play mode obviously doesn't close the Unity process - and that's what Steam is looking at).

IMHO, this is neither Unity's fault, nor Steam's fault. It's just how these things work and you have to know it. There are good reasons for Steam to do it the way it does it, and there are good reasons for Unity to behave the way it does.

 

It's a pretty annoying issue though. It spans across to ANY process that you invoke through Unity, including Explorer windows, VLC Media Player, Photoshop, etc.

In future when I'm not specifically testing Steam API features I think I'll write an editor feature to just turn it all off to save me this hassle.

 

it'a 2020 and I'm dealing with this

 

In 6 more years it will be fixed, I have a good feeling

 

Six more galactic years, right?

 

Thats only between 225 - 250 million years, we can wait

 

It is very unlikely that this will ever change. It's not a bug. It's simply how the two systems are designed. Steam is primarily designed for players, Unity is designed for developers. If you find the behavior annoying, one simple way to solve it is to disable connecting to Steam in the editor unless you really have to.

 

yes yes let's sit and wait
who knows? I might also make a penny out of my games by then

 

18.04.2020 not fixed!

 

I discovered what was causing this for me - leaving VSCode open

 

Another fun thing is if you run the game (in editor) and save a script by mistake, this reloads the app domain and fubars Steam tracking of host process completely .P

Talking about app domains wonder how Unity will solve reload code when they move to NET 5, Net 5/Core 3.x does not have app domains.

 

Alternatively, you can start VSCode on its own, instead of implicitly starting it by double-clicking a code-file in Unity (or clicking on a log-statement). When Unity opens VSCode, VSCode becomes a child process of Unity in Steam's eyes, so that's why you need to close VSCode for Steam to see that the game is no longer running.

 

I have been investigating this and see what is possible child process cause this. So far I have these:

• VBCSCompiler.exe - looks like Unity spawn it while using. not sure if it shared between editor instances or not.
• explorer.exe - yes, if you right click an asset to browse its folder (opening explorer) sometimes it counts as Unity editor spawn it. So open task manager, try terminate explorer.exe and relaunch it again.
• devenv / vscode - or any editor of your choice that was double clicked and spawned from editor.
• adb - I dont have adb (android SDK) installed myself, but I will just include this based on what people complained above.
• conhost - never found in my case, but also added as suspicion list based on member comment.
• unity hub (?) - As last resort, just in case.

This is known issue.

There is github issue report on Steamworks.NET (it is also appear in their FAQ page). That, in the end Steam uses aggressive process ID + child process checking, that all must exit.

https://github.com/rlabrecque/Steamworks.NET/issues/13

 

This happens even in built project without Unity installed in 2020.2. Not always but sometimes and not for every player.

 

The first thing I'd investigate is whether or not this issue occurs only for people who start your game without first starting up VR. At least with the Editor, SteamVR is then a child process of the editor, so keeping SteamVR open keeps the "game" open in Steam. And it's likely that you'll have the same behavior when starting a standalone through Steam.

In this case, Steam will stop showing your game as "playing" as soon as you close SteamVR. While I think it's nice that SteamVR automatically starts when a game requires it, it does cause this problem. The solution in that case would be shutting down SteamVR when your game closes ... but I'm not sure that's possible or really desirable.

If that's not it, you might want to investigate if your game starts any other processes. That would be a little unusual and you'd probably be aware of it but could be the case if you're using 3rd party packages. I believe there are tools mentioned earlier in this thread (or in the GitHub links that I posted above) that should make this a fairly straightforward process. In fact, I actually think even the task explorer in Windows 10 does a decent job at revealing this kind of thing but I'd have to double-check to know if this covers all potential cases.

 

Thanks but my game doesn't use VR.

 

Ah, ok, so then it isn't SteamVR being started up, so that's one step less when isolating the issue ;-)

So, "If that's not it, you might want to investigate if your game starts any other processes."

 

In 2020 SteamVR and Steam does not play nice. Keith from Valve is on it