On fixing crashes that don't happen on your own computer.

[RinkuHero]

I'm developing a game and it's currently in playtesting. The last version, v0.5, worked perfectly for all playtesters (about 10 to 20 people).

The next and current version, v0.6, works perfectly for me and for several playtesters, but three of them experienced problems: one has it soft crash (it freezes, but doesn't crash the computer) randomly with seemingly no pattern, and two others have it hard crash (it crashes their computer entirely), and in a consistently repeatable place -- however, that place is *different* for those two (one is when he starts a stage, the other is when a countdown preparation part of a stage reaches 0). I've asked all three of the people it crashes on for their system and driver etc. specs, and can find nothing in common.

Now, I'm not asking this as a technical question, obviously you'd have to know far more about the game than I mention here in order to help with that. What I'm asking is a more general question: when you are confronted with situations like this, where a game has a problem on several computers but you don't have access to any computer it has problems on, what exactly can you do? Do you try to solve it remotely? Do you try to gain access to a computer that it crashes?

What I probably need to do is send them v0.51, v0.52, v0.53 and so on and see at which point the crashes were introduced, narrowing it down to particular changes I made, but that will take awhile, and it would be annoying to them -- they're doing me a favor by playtesting it and I'd be asking them to repeatedly try something which they know will crash their computer.

[JoshuaSmyth]

I hate it when that happens... and I'd like to know what others have to share on the matter.

Whenever it's happened to me in the past, its usually been something to do with either having a different operating system version (eg xp vs 98) or having a different video card and/or older drivers.

The only way I've managed to think of is simply to never throw your old computer away, keep it for testing.

[mDEV]

It sounds a lot like memory access violation (pointer problem) gaining access to the crashing computer wouldnt help much without having some sort of tracking mechanism for debugging.

What I would do is checking all the new pointers since your last non-crashing version, maybe overriding new () and delete () operator with some sort of simple tracking mechanism would possibly help if you're using C++ that is..

hth..

[RinkuHero]

I'm actually using Game Maker *^^* -- and that uses an interpreted language with no real memory pointers accessible to me, which makes this even stranger, because I don't think I changed anything between the two versions which would cause these crashes.

[cliffski]

general tips:

add lots of asserts, and make it easy to make a debug build with the asserts in (actually my release builds keep them in, but my games aren't performance critical).

Make it easy in the options for your game to totally disable certain things, especially sound. Being able to 100% rule out the problem being related to your sound system is massively helpful.

Build in some debug log code so that once the game crashes, you have some idea what was going on shortly beforehand, and log all warnings or errors to it.

If possible, build code that offers to email you the error message when an assert is triggered, and make sure any logging or email also contains as much system info as you might need, especially the version of the O/S and the video card data.

Good luck!

[princec]

Quick tip: if it's crashing hard and requiring a reset that means it's crashed in kernel mode (after ruling out overheating and duff memory problems), which means it's crashed in a driver (probably a graphics driver but sound can occasionally go wrong too).

Cas