Steam Crashing

[GoogleCodeExporter]

When installing or updating certain games, the Steam app crashes to desktop.

It seems to occur primarily on uncommon games, possible the titles don't appear 
on the free servers for my provider (Bigpond). The only error given is the 
"Steam Bootstrap Loader" has stopped responding.

I'm running the latest steam-limiter, latest version of Steam, have seen the 
crash under Windows XP Professional x64, Windows 7 Ultimate x64, Windows 8.1 
(home) x64. I've been using (and loving) steam-limiter for a few months now 
without issue on multiple versions of Windows, it wasn't until yesterday 
(18/12/2013) that the issue presented itself.

My guess is a recent update to Steam does not like being limited.

Original issue reported on code.google.com by shcop...@gmail.com on 19 Dec 2013 at 3:24

[GoogleCodeExporter]

In the Steam install folder there should be a directory called "dumps", inside 
which it will store a capture of part of the Steam process as it was at the 
time it actually crashed. I can load these into Visual Studio and try to use 
that information to see whether the actual point of failure was in my code or 
not, and maybe speculate on the cause (or maybe not, it's hard to know).

If you zip up the most recent .DMP file and either attach it here (or e-mail it 
to me if you're more comfortable doing that), I can take a look and see whether 
it gives me any hints as to the root cause of why things are failing on your 
system.

I've just re-checked my Steam version (which has been downloading fine) and 
it's on the 3 Dec build, but evidently there's an 11 Dec update pending which 
I'll apply shortly to see if I can see anything going wrong. If you can suggest 
any games that you observe this on, I might have one of them to try and 
reproduce this myself (although I'm on a different ISP, you never know until 
you try).

You can search my games list at 
http://steamcommunity.com/id/nigel_bree/games/?tab=all and see if one of the 
ones I have is one (or more) that doesn't work for you and I'll try them out.

Original comment by nigel.bree@gmail.com on 19 Dec 2013 at 4:01

[GoogleCodeExporter]

Hello Nigel
I'm (unfortunately) at work at the moment, will gather as much as I can
when I get home this evening for you.
- Latest DMP file.
- Current Steam version.
- List of games I attempted when crash occurred. I'll try a few more this
evening also, get a screenshot of the error for you.

Many thanks for creating this application - as I am forced to be a Bigpond
user due to availability, you have saved me countless days at shaped speeds
on my 50gb download quota. :)
--Steve

Original comment by shcop...@gmail.com on 19 Dec 2013 at 4:58

[GoogleCodeExporter]

Hey guys, I'm having the same issue here. Getting the bootstrap error and crash 
to desktop. This started a week or so ago for me, had to turn off steam-limiter 
for a few games to update them. 

I noticed State of Decay was needing a game update this morning so i pushed it 
to the top of my download queue in Steam, and after a minute or two trying to 
download Steam crashed. I've attached a screenshot of the error message and my 
latest .DMP file. I'm using Windows 8.1 x64 and my ISP is Internode.

Cheers

Original comment by tom...@gmail.com on 20 Dec 2013 at 11:13

Attachments:

• steam_crash.png
• crash_steam.exe_20131221100741_1.zip

[GoogleCodeExporter]

I too have a very similar issue. It seems to occur when changing position of 
games in the queue or pausing and then resuming a download. From looking at 
debug view it just seems to continually reject URLs until I have the same steam 
crash window as above.

I have also attached my dmp file as well.

Original comment by mythica...@gmail.com on 21 Dec 2013 at 1:17

Attachments:

• [Steam Crash.dmp](https://storage.googleapis.com/google-code-attachments/steam-limiter/issue-30/comment-4/Steam Crash.dmp)

[GoogleCodeExporter]

> From looking at debug view it just seems to continually reject URLs until I 
have the same steam crash window as above.

OK, that's some great information! When I just download normally things work 
100% fine, but when fiddling with the download queue I can reproduce this 
problem here.

When you normally start downloading, the Steam client asks Valve for a list of 
servers to use. That list of servers is different per ISP, and normally has a 
big bunch of things in it, including your ISP's servers.

When you pause and resume (or fiddle with the download queue, which is 
essentially the same thing) for some internal reason the Steam client doesn't 
request a new server list, and it doesn't try and use any of your ISP servers 
either.

Instead, it just tries to hammer a small set of what Valve calls "CS" type 
servers; to do any downloads from these type of servers, the Steam client goes 
through a login process similar to the one it does with the Steam store, and 
that's what steam-limiter is blocking. Since none of these are ever unmetered, 
I force-block them all in steam-limiter, but when you pause and download, 
that's the only kind of download server Steam will ever try and use.

The eventual crash is just a bug in Steam itself - as it keeps retrying by 
trying to get through to these metered servers, and not ever trying to use your 
ISP's unmetered server because it's basically forgotten the list of servers 
Valve told it to use, it eventually just crashes due to bugs internal to its 
download code. If it would ever attempt to contact your ISP server, it wouldn't 
crash, but it never does and because I block the only servers it'll ever try 
and use, it eventually falls apart.

Basically there doesn't seem to be any easy way around this; the new download 
queue system recently patched into Steam just has serious bugs of its own (when 
I do this kind of pause/resume with the filter off, my download speed tanks and 
goes to nearly zero because Steam is no longer using a server in New Zealand, 
only a couple of offshore ones that are going to be dog-slow with the Holiday 
Sale on).

I'll think more about it, but it's looking like until Valve fix the download 
queue system they recently added to Steam, if you pause a download you just 
either have to allow (really REALLY slow) metered download or it'll fall over 
dead.

Original comment by nigel.bree@gmail.com on 21 Dec 2013 at 4:43

[GoogleCodeExporter]

One more thing to add into the mix, I downloaded Brutal Legend on one
system (without steam-limiter), ran the backup procedure and took it to
another system (running steam-limiter) and tried to restore the backup. At
the "creating local cache" part, Steam would crash every time. As soon as I
disabled steam-limiter, it restored the backup perfectly.

Could this be doing the same thing? Forcing a check that I own the game
from these "CS" servers?

I'm going to try a work-around later today - I'll turn off steam-limiter,
queue up a heap of downloads, quit Steam, re-enable the steam-limiter and
fire up Steam again and not touch the download queue. I can't see Valve
putting out a patch to fix until the current sale is over....

Original comment by shcop...@gmail.com on 21 Dec 2013 at 4:50

[GoogleCodeExporter]

> Could this be doing the same thing?

It's definitely doing the same thing; I just did a backup and restored it, and 
it immediately hit the "CS" type download servers no others.

> Forcing a check that I own the game from these "CS" servers?

That's not what it's doing, oddly enough. The login done to the "CS" - I can 
only presume the name is something from many years ago when they first built 
Counter-Strike, maybe some ancient system they built for map hosting - servers 
is just a general account one. It doesn't have anything to do with ownership 
checks, it's just some old piece of vestigial Steam client behaviour from years 
ago that doesn't appear to have any actual modern use.

I've done plenty of backups and restores with Steam-limiter before, and my 
guess is that this is the same underlying bug; basically, when you restore a 
game from a backup disk set, after unpacking all the disk data it internally 
sets it up as a paused download (since you could have restored from old data 
that needs patching) and then "resumes" it to get any new changes.

This used to work 100% fine with steam-limiter, but it looks like this got 
affected by the same pause/resume bugs they've introduced with the download 
queue. Because it doesn't ask for a list of servers to use, it only looks for a 
small fixed set of metered servers (really, really slow ones).

Ultimately, for Valve even to become aware of this as a bug, it'd require that 
they perceive it as a download performance problem. And those are hard to get 
escalated because when they are reported they are generally a bit nebulous - 
"goes slow" is pretty vague, and doesn't give their people much to go on. 
They'd need to see *both* a large number of people reporting the fact that 
queue re-ordering tanks their download speed (which it surely does for me) to 
make the problem "important", and then other people reporting the detail of why 
it's going wrong so they get the details of how to fix it right.

Original comment by nigel.bree@gmail.com on 21 Dec 2013 at 5:26

[GoogleCodeExporter]

OK, I've been looking deeper into this, and I'm developing an idea about what I 
can do about this.

The first thing to note is that Valve have over recent times re-organized how 
their own server structure works. The "CS" server type used to be more 
different, but what has happened over the past while is that *all* of the 
classic Valve-run servers now have DNS names of the form *.cs.steampowered.com, 
which they never used to do. They don't actually *need* the session handshake 
stuff either, it's there for Valve to do statistical monitoring. So the old 
classic Sydney Steam server is now valve217.cs.steampowered.com (although they 
don't have reverse DNS for it, so that's a hard fact to discover).

Another thing that's interesting is that the "CS" server handshake has two 
parts; /initsession/ is a POST which yields a reply document, but it's actually 
pretty meaningless. The HTTP proxy my ISP runs lets that through, and it 
indirectly fetches a valid response. However, there's a second POST part which 
is /authdepot/ and on a real "CS"-type server that returns "200 OK" and an 
empty response, but the proxy is returning "403 Forbidden".

I'll keep digging, but basically it appears that a DNS rewrite for 
*.cs.steampowered.com to point at the ISP-level proxy (plus whatever other 
trickery is needed for that to work; nothing for me, but possibly extra things 
for different ISPS) seems to allow the ISP-level HTTP proxy to appear to Steam 
to be a "CS" type server and then Steam can work OK.

I'm going to be experimenting a whole lot more but it may be that there will be 
a complex set of rule workarounds (and possibly a new version of steam-limiter, 
depending on whether I add a new rule feature to stub out the /authdepot/ POST).

The other thing I've observed today is that some of the Akamai servers are 
using HTTP 302 redirect codes; it may be that I can fudge something else up by 
generating fake 302 redirects for the "CS"-type servers.

Basically, this is just to let you guys know I'm not giving up, and I'm trying 
to come up with something. How complicated it ends up being will probably 
depend on your ISP, because the ISP proxies are sometimes really restrictive 
(whereas the one at vodafone.co.nz is not) so once I have something that's 
working well for me it will probably take a couple rounds of experimenting to 
figure out the right variant for other ISPs.

Original comment by nigel.bree@gmail.com on 21 Dec 2013 at 11:45

• Changed state: Started

[GoogleCodeExporter]

After many hours and much testing, I've got something that may help; here's a 
link to the announcement with the download link and extra instructions 
https://groups.google.com/forum/?fromgroups#!topic/steam-limiter/ksMFySIQQqI

It seems to do the trick for me and I'm not getting any more Steam client 
crashes when fiddling with the download queue, so give it a whirl with the 
associated new rules.

Original comment by nigel.bree@gmail.com on 22 Dec 2013 at 4:02

[GoogleCodeExporter]

I haven't had a single crash, have downloaded about 8gb and it has all
shown up as freezone traffic for Bigpond.

I've tested with both popular and uncommon games, they both install and
download without issue. Have tried mixing up the download order,
pausing/resuming downloads, no crashing. The only thing I've noticed (which
may well have happened before) is that titles fairly uncommon (Blood of the
Werewolf, Cognition) come down a lot slower than I'd have thought, though I
expect these aren't cached on the Bigpond servers and they're getting a
fresh copy from the CS master servers before passing through to me.

In any case; no crashing, all traffic comes through freezone. Very much
appreciated for getting ontop of this so quick :)

Original comment by shcop...@gmail.com on 23 Dec 2013 at 11:41

[GoogleCodeExporter]

Hello Nigel,

Sorry to bring this one back, but it seems like Steam is doing a similar thing. 
With the limiter active, Steam lists the titles that need an update, but does 
not retrieve the update size or start the download. Once I untick filter 
connections or close steam-limiter, the downloads work again. I suspect the 
last Steam client update has done something silly....

Steve

Original comment by shcop...@gmail.com on 28 Mar 2014 at 11:35

[GoogleCodeExporter]

> Sorry to bring this one back, but it seems like Steam is doing a similar thing

Is actually Steam crashing for you, or just not downloading? Since you're on 
BigPond, you may be affected by the fact their cache recently became blocked 
(effectively making it down) for a lot of their customer's IP addresses, see 
http://whrl.pl/RdVMjp

As background, you can see how Steam gets update information easily by leaving 
DebugView running; for me Steam gets information on updates via checking 
http://clientconfig.akamai.steamstatic.com/appinfo/* - the .txt.gz files are 
just Steam-format property sets. On the property page for a game is a "Local 
content BuildID:" value, and there are corresponding lists of BuildID values in 
the game information.

Anyway, the updates then come through the normal download system, so if that's 
not working for you it's probably a problem at the ISP end (as with BigPond) or 
a configuration choice the ISP has made. Since ISPs aren't running actual Steam 
servers but just simple caching HTTP proxies (Squid for me on TelstraClear, 
Varnish for BigPond) the content they serve just comes from a nominated Valve 
upstream, and generally the upstream should be a server in Valve's core group 
which means there's *never* any content which is unavailable.

However, it's still possible that an ISP might not do that, and be choosing to 
source their HTTP cache's data from a second-tier source that's not a core 
server, in which case there might be a delay before the content replicates out, 
and that'd be more noticeable for a game that's frequently having fresh updates 
pushed.

But I'm guessing for you it's most likely just the same BigPond problem that is 
affecting lots of people.

Original comment by nigel.bree@gmail.com on 29 Mar 2014 at 8:47

[GoogleCodeExporter]

Steam isn't crashing, it acknowledges a game has an update but doesn't
retrieve the size of the update or start actually downloading it.

When unticking Filter or closing Steam-Limiter, even with Steam still
running, the moment I do, the download proceeds as normal, which made me
think it was a similar issue to before - but it just looks as though its
the Bigpond content servers being blocked, with Steam-Limiter disabled its
picking up the content from others.

Many thanks for your response, I'll have to refrain from any large
transfers for the time being. If nothing else, Steam-Limiter is stopping
surprise patches from increasing my quota. Thanks again ;)

- Steve

Original comment by shcop...@gmail.com on 31 Mar 2014 at 2:48