Debugging Windows Phone scheduled tasks
Mood: accomplished
Posted on 2012-02-26 14:43:00
Tags: essay windowsphone projects programming
Words: 641

I was about ready to release a beta for FlightPredictor, and then I realized that the scheduled task that updated the flights that are pinned to live tiles (a key feature of the app) was horribly, horribly broken. The reasons I'd been putting off dealing with this are:
- I have a WiFi only device, and so whenever it wakes up from sleep it has to reconnect to the WiFi, and I assumed this was why the tiles didn't update very often. But this is a pretty poor excuse, and turned out to be a little true but didn't account for many of the problems.
- I had trouble finding good ways to debug the scheduled task to figure out what was going on.

So, here are the three things I did to make debugging scheduled tasks a snap! (or, at least, possible)

1. ScheduledActionService.LaunchForTest: One thing that makes dealing with scheduled tasks difficult is that they have pretty tight restrictions - the PeriodicTask that I'm using can't use more than 6 MB of memory, or take more time than 25 seconds, and it only runs every 30 minutes. This last point would make debugging unbelievably annoying - luckily, you can call ScheduledActionService.LaunchForTest in a debug build to make it launch in a minute, or however much time you want.

For some reason, after a while of debugging on an emulator instance this call seems to stop working for me, and I had kinda forgotten that it ever worked at all, so I used it early in development but not since then. But it really does work, and if it stops working, just close and relaunch the emulator! This is a great way when you absolutely, positively have to step through code and see what's going on.

2. Little Watson - Andy Pennell blogged about this, and I had had it recommended to me but hadn't bothered to include it until a week ago. If your application crashes, you can capture the call stack, and then the next time the app is launched you can give the option to email you the stack trace. This is awesome for hard-to-track-down crashes, although I wish the call stack had a little more information. What Andy didn't talk about is the fact you can use this to capture call stacks if your scheduled task crashes! I turned this on yesterday and have already tracked down a few crashes I didn't know were happening - I was hitting the memory limit and not even realizing it...

3. ScheduledTaskLogger - This is my own creation - it's basically a way to log a bunch of data while your scheduled task is running, and then view it later in the main app. This helped me to find a glaring error in my update code (note to self: always look up the return value of CompareTo(), as I've gotten it wrong at least five times now...), and I'm hoping it can help me catch any other issues that arise.

Here are the code files for ScheduledTaskLogger:
- ScheduledTaskLogger.cs - This logs data while the scheduled task is running. You can set how many logs to keep, and also whether it writes out to file after every log message - probably not a good idea for release, but useful if there's a problem that's causing a crash. I also try to save the log in ScheduledAgent_UnhandledException.
- ScheduledTaskLog.xaml and ScheduledTaskLog.xaml.cs - these are the views in the main app that you can use to view the logs. There's also a button to email a particular log to support, although I need to add one that emails of all logs.

Edit: I added this code to the Nokia Developer Wiki.

--

Anyhow, I've squished a bunch of bugs and am on the lookout for more. I was kind of dreading trying to figure out what was going wrong, but good tools make everything easier!

1 comment

Comment from brittongregory:
2012-02-26T20:39:30+00:00
“If you want to increase your success rate, double your failure rate.” --Thomas J. Watson

This backup was done by LJBackup.