3

I noticed that, if in WP7 application I press Start key then quickly Back key to return to the app, and very quickly repeat these steps many times, the application ends up being crashed (it exits unexpectedly and no way to recover it via Back key). This happens on device (never seen on emulator), and it takes 10-15 steps before the application gets shut down. I follow Microsoft guidelines about saving / restoring its state. Furthermore, all other apps I've tried in such way crash too. However, some apps are much harder to kill in this way than the others. During experiments with this stress test, I noticed that

  • XNA games tend to be less resistant than pure Silverlight apps
  • The more data the application saves / recovers, the less resistant it is
Unfortunately, my XNA game has to save a lot of data during deactivation, and it's pretty easy to get it crashed.

Does anyone know if it's a known problem or something else? I'd appreciate any advice of how to make the game more stable if it's not possible to completely eliminate the problem.

tshepang
  • 12,111
  • 21
  • 91
  • 136
mbakulin
  • 181
  • 1
  • 9
  • Are you given any crash details like a stack trace or exception? – Adam Houldsworth Apr 03 '12 at 12:13
  • 1
    If you can't reproduce the issue with the debugger attached, find the unhandled exception handler in app.xaml.cs, write the exception detail to the isolated storage, then at next startup display it. – Kevin Gosse Apr 03 '12 at 12:20
  • I have seen it before. It crashes while deserialization (if serialization is not completed yet), and no user code are executed to prevent it with try/catch or something else. It will be great if someone know a solution – Ku6opr Apr 03 '12 at 12:21
  • @Ku6opr Aside from not saving that much on tombstoning... this sounds like a Microsoft issue. – Adam Houldsworth Apr 03 '12 at 12:30
  • @KooKiz Thank you for your response. In fact, I can't reproduce the issue with the attached debugger. I did quite the same you told, but, unfortunately, the game exits without any exception. I also added logging to activated/deactivated/launched/closed callback functions but there is nothing special in the logs. The last record was in Application_Deactivated method which was called and exited correctly. – mbakulin Apr 04 '12 at 05:32
  • @AdamHouldsworth No, as shown by my experiments with isolated storage, there were no unhandled exceptions. – mbakulin Apr 04 '12 at 05:39

2 Answers2

1

I found a workaround how to make the application a bit more stable. Actually, we don't want to save game data to the isolated storage each time during deactivation. It's only needed when game state was changed. As my game is automatically paused after being activated, it's state didn't changed, and I don't have to save its data again until the user resumes the game. Thus, storing data to isolated storage occurs for the first deactivation only. This approach helped a little, but not too much. 20 iterations of Start key / Back key still make it go down.

mbakulin
  • 181
  • 1
  • 9
1

On the Idea that the Problem could lay within the De/-Serialization Process you could do this:

    private IsolatedStorageSettings isosettings = IsolatedStorageSettings.ApplicationSettings;
    void Application_deactivated()
    {
        isosettings.Add("serialization_finished", false);//just add once, 
                    //after that use isosettings["serialization_finished"]
        //DO: save here your code into isostorage
        isosettings["serialization_finished"] = true;
    }
    void Application_activated()
    {
        while (!isosettings["serialization_finished"])
            Thread.Sleep(500);
        //DO: read you data from isostorage
    }

So you practically build an on/off switch to test if the serialization-process is finished

Old:

The Tombstoning has a Timelimit in which he must be finished (10 seconds). My guess is here that you give him so much to tombstone that at one point one instance of the application cannot finish the tombstoning in time. But thats just an assumption on the premise that the more to save = faster to crash.

You could test that by measuring the time you need for the tombstoning and writing the data into the isolatedstorage. When you analyze the data and see that the time for the tombstoning increases (up to 8-9 seconds) you can conclude that it should be the time.

On the other hand, if the time needed never increases and stays within some seconds you can safely conclude that it shouldnt be a timeproblem

kadir
  • 1,417
  • 11
  • 35
  • Thank you for your answer. I measured the deactivation time and observed that it always stays about 1 second, so it's unlikely the problem of accumulation. But somehow decreasing of this time (e.g. by not saving the part of game data) makes the game more stable. Not too much, but anyway. – mbakulin Apr 04 '12 at 05:52