Saturday, 14 July 2012

WP7 ScheduledActionService = Scheduled Crash!

I’ve been on the trail of an irreproducible bug for a couple of weeks now, described on the forums

In effect, what has been happening is that ScheduledActionService.Find is throwing an exception, but I wasn’t able to duplicate the fault in our program Terminator which shows sunrise and sunset times.

However, we’ve been trying to get rid of some other navigation bugs, and it struck me that this was probably another banging on the back key bug.

And it turned out I was right, that’s exactly what it was.  If you repeatedly stop and start our app (and probably any other app that refreshes a live tile on startup) you can provoke this failure.

It appears the crux of the problem is that the previous instance of the app has not quite completed when you launch the new instance.  If you get the timing exactly right, the call to ScheduledActionService.Find will throw, and if you're even more lucky you’ll catch it in the debugger, and see that immediately after it fails, it throws a ThreadAbortException

That’s a pretty good clue that there’s some internal bug that is triggered by the previous instance not having let go.

My solution?  Initially I thought wrapping a mutex around the whole program would do it, but it still failed.  That implies that the abort on the previous version released the mutex, but hadn’t yet cleaned up the remainder of the ScheduledActionService.

So the working solution is to retry the call to ScheduledActionService.Find up to three times, delaying 100ms each time, to let the previous instance shut down correctly and get out of the way.  Timing of course may vary depending on your app.

No comments:

Post a Comment