The Windows Phone team made waves when the platform was introduced by indicating that, at least initially, Window Phone would not multitask 3rd party applications. The answer sounded pretty absolute. The actual implementation isn’t.
This isn’t the place for a treatise on multithreaded managed applications. But briefly, very briefly, Windows Phone applications can be multithreaded. The main thread of the application calls the appropriate methods to create the main application form and is the “user interface thread”. Other threads created by the application can’t directly interact with the user interface. These threads are called “worker threads” or “background threads”.
When an application is sent to the background, the foreground thread is suspended. However, any worker threads currently running in the suspended application continue to run. These worker threads can call base class library methods such as querying the file system, reading and writing files, and such even while the application is “suspended”.
When a worker thread tries to invoke a method on the foreground thread, that request is queued but not executed. When the application is resumed, the queued calls are invoked.
Of course, “suspended” applications live on borrowed time. If the system needs the memory used by the application it will be terminated. At that point, the Application_Exit event should (but sometimes doesn’t) fire.