To Dehydrate or Not to Dehydrate…

Now that the tech-savvy of us can disable dehydration for faster resume times, the question becomes should you? What are the negative effects? And what happens when you set the registry key to 1 or 2 as opposed to 3(default) or 0(never dehydrate)? Within Windows has done a little experimenting and explaining about what they think is going on when you mess with these settings. The take away is that you probably don’t want to change the setting for everyday use. Current apps are not designed to resume from where they left off, so they leave a lot of junk behind when you navigate away without dehydrating them.

The DehydrateOnPause value controls the operating system’s Dehydration Policy. It can be set to a value ranging from 0 to 3.

0. Don’t dehydrate

1. Forcefully dehydrate

2. Gracefully dehydrate

3. Automatically decide

By default, Windows Phone ships with the Dehydration Policy set to 3. This instructs the task host – again, your application’s container – to gracefully dehydrate when possible. I admittedly don’t fully understand how eligibility is determined, but it appears opt-in is the default. (Some tasks, like the CameraCaptureTask, appear to opt-out.)

For the hackers out there, it appears you can control this behavior. Simply call the aygshell!SHSetAutoDehydratingHostEligibility function with an eligibility set to false to opt-out of dehydration. But you better be damn sure you handle the change in behavior properly (keep reading).

HRESULT SHSetAutoDehydratingHostEligibility(BOOL fEligible);

With the policy value set to 2, the operating system always starts the dehydration process. Differentiating it from forceful dehydration (policy value 1), a Win32 WM_CLOSE window message is sent to the application. In theory, this message could be processed and either ignored or accepted. It’s unclear if this message is simply an advance warning, in which dehydration would still continue, or if dehydration would be aborted.

Set to 0, dehydration is completely disabled. Your application will not terminate unless explicitly stopped. That means, for example, the .NET Framework is never shut down, your class instances aren’t destroyed, native resources left locked, etc. While this sounds great, given .NET Framework spin up is mainly the cause of the infamous resume screen, applications rarely behave properly in this scenario. After all, we were told to save state and abandon ship!

An easy way to see this in action is to create a Silverlight application with a sample page. In the page’s constructor, write some code. Tap the Search button on your phone, then tap the Back button. With dehydration disabled, this class is created once and left behind for re-use when your application resumes. Your constructor will not get called again.

Aside from all the quirks that arise from leaving junk behind, you also increase the chance of hitting out-of-memory (OOM) conditions. And with task host containers cluttering up RAM, their threads eat CPU cycles attributing to unnecessary battery power loss. (Admittedly, I don’t know how much loss we’re talking about here.)

So no, I wouldn’t fiddle with the dehydration policy on your phone.

[source]