Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 1

Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 1

  • Comments 8
  • Likes

With such a long and promising title, this series of posts better be a good one – you’ll be the judge of it. However, the real reason for this long title is rather simple. All these “big” words simply represent different aspects of the execution model. There are a few things that you need to know if you want to maximize your user’s experience. This post explains the Windows Phone (WP) application execution model by taking you step-by-step through the different aspects of launching, running, and closing a Silverlight application. Note that for XNA games the terms and ideas remain the same with some minor implementation differences. In following posts we’ll cover deactivation, reactivation, and how launchers and choosers work with tombstoning.

With the latest Beta release of the Windows Phone developer tools, applications running on WP employ an updated execution model. Now, when your application is removed from the phone foreground (a different application occupies the phone foreground like incoming phone call, or the lock screen being activated), it is actually being terminated (more on this later). In earlier version of the WP tools, you could get into all kinds of strange scenarios if you went from one application to another. That is because in the previous version of the tools, the WP operating system didn’t terminate your application, it “parked” it. However that led to some issues regarding launching a new instance of your application vs. navigating back to the instance on the back stack. Adding to the confusion, the events and API were less than perfect. I guess that is one of the reasons we have technical previews—to test and fix such “issues.”

A Few Ground Rules

Just to make sure we are all on the same page, by now you probably already know that the WP operating system doesn’t allow any 3rd party applications to run in the background. To be more specific, there can be only one application running in the foreground at any given time, and if your application is not running in the foreground, it means that your application is NOT RUNNING. The main reasons for not allowing 3rd party applications to run in the background are to preserve battery life (see Push Notification post) and to ensure a responsive and consistent user experience.

All WP devices feature a hardware Back button. This button allows the user to navigate back in a given application and even between applications. This is a rather cool feature, mainly because unlike other phones, you can navigate from your application to the browser or to another application, and then press Back to seamlessly return to your application. This yields a much more consistent user experience across different applications, whether they are 3rd party applications or part of the phone's built-in application suite. This also implies that WP operating system is maintaining a journal of you navigation actions to support the Back button functionality. This is also known as the back-stack.

The Basics – Launching, Running, and Closing Applications

It is time to jump into the Windows Phone execution model, and the best way to do this is to start looking at some code. Simply start a new Windows Phone application and look at the auto-generated code of a new WP Silverlight application template, and you will find four new methods in the App.xaml.cs file that are directly related to the execution model:

  • Application_Launching
  • Application_Activated
  • Application_Deactivated
  • Application_Closing

As a side note, all these events (the functions are the event handlers) are members of the PhoneApplicationService class in the Microsoft.Phone.Shell namespace.

I think the names of these methods are rather self-explanatory, but just to be on the safe side, let’s review them. We’ll address the Activated and Deactivated methods later; for now, let’s focus on the simple events: Launching and Closing. I’ve added a single line of code to each method:

// Step 1 - Util is helper class for logging
Util.Trace("***** in MainPage CTOR\t\t ( " + DateTime.Now.Ticks + " *****)");

Util is a simple helper class that we’ll use to help us with debugging. The text in each method changes according to the event but you get the idea. I log the time of each event in order to prove a point later when we talk about Activated and Deactivated events.

Running the application in its current state yields the expected result. Upon launching your application the “Launching” method is called. As expected, after that event, your application runs. Press the Back button (not the Windows button) and your application terminates and the “Closing” event is raised, as you can see in the following image (copy of the output window from Visual Studio).


As we said, by pressing the hardware Back button, the navigation model allows the user to “step back,” or navigate backwards through the application pages, and even across applications. However once you reach to the application’s first page (the first page, and its first instance) pressing the Back button raises the Closing event and terminates your application. You can see that from the above image, where it clearly states that the “program” exited. If you are following this post while coding in Visual Studio you will also note that the emulator exits your application and returns to the Start window.

Understanding Activated and Deactivated Events and Tombstone

So far so good, I mean there is nothing new here. However, let’s try the following trick. From Visual Studio, start your application in debug mode (so we can see the traces). As expected, your application starts and you should see the Application Launching trace in the log. Now, instead of pressing the Back button (which if you do, will terminate your application), press the Windows button (the middle button).

You should notice the following:

  1. The emulator returned to the Start screen and your application doesn’t occupy the phone’s foreground, which means it is no longer running!
  2. The debugging session in Visual Studio was terminated. This means that Visual Studio is not debugging your application, which makes sense since the application is no longer running.

Note: At the end, your application gets terminated. That is super easy to see in the Visual Studio Output window, as the last line in the Output windows states, “The program '[220921918] taskhost.exe: Managed' has exited with code 0 (0x0).” No worries, this is by design. However, unlike our previous example, this time the event that followed the Launching event is “Deactivated,” and NOT Closing. But in both cases your application gets terminated (at the end). So what is going here? What is the difference between Closing and Deactivated and more important, why?


  • Application Closing is simply the outcome of the user pressing the hardware Back button enough times to navigate backwards through the pages of your application, past the application’s first page. Currently, this is the ONLY way for a user to exit your application. Once your application is closed, its process is terminated, and the operating system removes any trace of that application from its memory (RAM).
  • Application Deactivated occurs when a different application takes control of the foreground - for example, an incoming phone call, launching a chooser, or the user pressing the Windows button. In both cases, your application will be deactivated (not closed). Before we step into the subtleties of the Deactivated event, let’s make sure we all understand that upon Deactivation, your application gets terminated (at the end). It's that simple; your code can’t run in the background, therefore your application gets terminated. However, unlike an application that is closed, a deactivated application gets tombstoned. Don’t get confused, a tombstoned application’s process still gets terminated. But unlike a closed application, where the WP operating system removes any trace of the application, when an application is deactivated, the WP operating system stores a record (a tombstone) of the application's state. Basically, the WP operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the hardware Back button to enhance navigation functionality.

There are several ways in which applications can become tombstoned. An application will be tombstoned and deactivated if:

  • The user presses the Windows button (as you just did)
  • The device timeout causes the lock screen to be engaged (again, a different application takes control of the foreground)
  • The user invokes a Launcher or a Chooser – which we will cover later

In any of these cases, the running application will be deactivated, the Deactivated event is raised, and your application gets terminated shortly afterwards.

At this point in the application life cycle (while your application is tombstoned), a few things can happen. The user might return to a tombstoned application. This can happen if the user completes the chooser or launcher activity and returns to the application, or if the user presses the Back button enough times to return to the tombstoned application. Regardless of how users return to the tombstone application, the application will be reactivated (raising the Activated event) and magically show the last page viewed by the user before the deactivation.

You don’t believe me, let’s try it together. I’ve added a second page to the basic WP Silverlight application, and added a trace to both constructor pages. Next, I added a button to the first page that navigates to the second page.

In Visual Studio, start debugging your application and click the button to navigate to the second page. From the second page, press the Windows button. As expected, your application is deactivated and then terminated, as you can see from the following screen capture of the Visual Studio Output window.


Note the sequence of the trace (and the corresponding time-code). First your application launches, then the main page constructor is called, and after pressing the button on page one, the application navigates to the second page (DetailsPage), after which you press the Windows button raising the Deactivated event, which indicates that your application is tombstoned.

In the next post you’ll learn about returning to a tombstoned application and managing your state between tombstoning.

You can download the code for the code samples.

Windows Phone 7 Training Kit for Developers includes a full lab dedicated to the Windows Phone Application Lifecycle.

MSDN documentation includes a topic - Execution Model Overview for Windows Phone

Blog edited by Barbara E. Alban

You must be logged in to comment. Sign in or Join Now
  • hearts
    1 Posts

    From MSDN,

    The Launching event is raised when a new application instance is launched by the user from the installed applications list or from a Tile on Start in addition to other means, such as tapping on a toast notification associated with an application or selecting an application from the Photos Extras menu. When an application is launched this way, it should appear to the user to be a new instance, not a continuation of a previous instance.

    In my understanding, when a user click Start tile, or toast notification, the application will be re-launched even when there's an old application in dormant or tombstoned state.

    This is completely ANTI-Human-experience!! When I receive a notification, I need to wait for an app to completely restart itself (even my phone got enough memory to hold it's old instance), to know what the notification is. How anti-human it is.

    You should fire the person who designed such ideas.

  • Anil
    1 Posts

    Dear Yochay Kiriaty,

    I need one help.

    I developed an app for Windows Phone 8...While saving items operation going on,when we lock and unlock or when user gets call,saving operations stops and we go to home screen(tombstoned)and again need to start from begening..This takes a lot of time..

    Is there any mechanism to pause current operation and resume it??

    Plz help..

    Thanks in advance


  • This is an excellent post indeed. One difficulty I have is that when I run the example application and click on the Windows button, the example application deactivates but does not terminate as is indicated above. The message I receive is

    ***** in Application Deactivated 634777788720980000 *****)

    The thread '<No Name>' (0xf110052) has exited with code 0 (0x0).

    The thread '<No Name>' (0xe8c0042) has exited with code 0 (0x0).

    Is this the same as the program terminating? I am running Windows 7 Enterprise 64-bit, Visual Studio 10 Version 4.0.30319 SP1 Rel, Microsoft Windows Phone 7.1 Profiler, Windows Phone SDK 7.1 - ENU

    Also, there is no indication in the article as to the EXACT versions of the software being run and I am wondering whether my software is up to date? Regards, Trevor

  • Sil
    1 Posts

    I'm a big fan of WP7.5, use it everyday and couldn't do without it.

    Nonetheless I find the multitasking / tombstoning mechanisms totally broken.

    WP 7.5 isn't really multitasking and in my opinion the tombstoning is a disastrous design decision.

    All WP7.5 is interested in is to give the impression to the user  that application are working concurently, as users would expect from say a Windows computer, while in fact it isn't and there are no guarantees at all that the app is in fact still working in the background.

    The deception is even worse than no deception and the fact that there are no guarantees as to in which state the application is in when switching again is an implicit break of trust.

    Let's take a very common use case. A user is surfing the web.

    He then answers a call or needs to send a text message.

    He comes back to the browser and needs to surf back to an already viewed page.

    But then s/he is incredibly angry because:

    1. when pressing the back button s/he is thrown in another application / mango's main view when s/he expected to go back in the browser's history.

    2. The browser history was in fact deleted.

    This is 2x what wasn't expected and a clear breach of the explicit UI contract a normal user was expecting.

    Will this behavior change? I hope so but fear not.

    I just noticed that Windows 8 metro behavior was almost as bad. While watching a video on the viewer, switching to a browser or the setup of an application or anything else simply pauses the video. This is annoying as hell as I do not want w8 to force me to pause a video, I want to decide myself if and when, and it breaks more than 20 years of multitasking paradigm in Windows (and any 'modern' OS for that matter).

    Can we expect a change of behavior?

  • ericesque
    34 Posts

    Thanks for the primer.  Looking forward to reading the follow up posts!

  • Aha! Yes that does the trick, although my code still crashes. Typical!

    Thanks for the help.

  • @Ben Thanks, Part 2 will be posted tomorrow, and there are also part 3 and 4 coming real soon. Part 4 talks about Launchers and Chooser. Part will tel you the trick on how to get your app running again from VS ;) This is supposed to happen,. When you press the back button and you get your blank screen, the phone knows you were running with the debugger and is waiting for you to restart the debugger. Press F5 in VS at that point and you will get your app up and running.

    Or you can try our WP7 training kit that has a full lab dedicated on to App Lifecycle - channel9.msdn.com/.../ApplicationLifetimeWP7Lab

  • Great post, and really interested to see what you come up with in part two. Interesting to note that your sample code replicates what I think is a bug: if I add a WebBrowserTask to one of the button events on the detail page, navigating back from the Web Browser makes the app hang, then crash.

    To replicate it, use the source code in this post, and just add these lines to the click handler of a button on DetailsPage:

    private void SendSMSBtn_Click( object sender, RoutedEventArgs e )


       var webBrowserTask = new WebBrowserTask { URL = "http://example.com" };