The Walking HeadlessHost - WP 8.1 Feedback Feature and Zombies

Photo by Juanedc



I was recently working on a rather large Windows Phone app project and came across an issue which took many head scratching hours to figure out. Therefore here's a short heads up if you work on Windows Phone apps with background agents and have those running on Windows Phone 8.1 devices: The WP 8.1's Feedback setting can influence how your background process behaves.

We are talking about a WP 8.0 app with an UI (TaskHost.exe) and a VoIP background agent (HeadlessHost.exe) communicating with each other through an out-of-process RPC server. This approach follows the WP 8.0 VoIP app architecture. When this 8.0 app runs on 8.1 devices I've seen sporadic issues where an instance of the HeadlessHost background process was kept alive when the app was deactivated, for example with fast app switching. When the app get's activated again another instance of the HeadlessHost is started while the previous zombie HeadlessHost is still not dead, so you will end up with two HeadlessHost processes which leads to issues like endless "Resuming..." screens and app crashes when navigating back. This can be seen even without a debugger attached.

If you disable the WP 8.1 device's Feedback setting that issue is gone and the ForegroundLifetimeAgent's HeadlessHost is quickly exited as expected when the UI gets deactivated.
I'm not sure why the Feedback feature is related, my best guess right now: The WP 8.1 Feedback feature gathers telemetry data and therefore keeps the HeadlessHost undead. The weird part is that the HeadlessHost is even undead after a minute and no crash of the background agent happened which means no Watson data should actually have been collected at all or at least not that long.

I'm not sure yet if Silverlight 8.1 apps on 8.1 devices are affected as well or if it's only an issue with 8.0 apps on 8.1 developer unlocked devices. Nevertheless I still wanted to share my experience since it's a rather unknown case and not much information can be found anywhere else so far.

Content for the Modern Camera and Imaging Apps Build 2014 Session

I had a chance to give a presentation at Microsoft's largest developer conference //build 2014 about the great new capturing APIs. The session Modern Camera and Imaging Apps was given together with Jeff Day who's the Windows Camera API lead PM.

The session was recorded and available at Channel 9.

The slides can also be viewed / downloaded here.
The source code of the demos is available here.

No Biggie - How to Query the Available Storage Size in WinRT

Tape drive photo by P. Hollenback

The Windows Runtime (WinRT) provides a nice file IO API called Windows.Storage. Part of it are atomic operations to create files and folders, etc. It also has a KnownFolders class with static references to different library folders like documents, videos, photos, plus RemovableDevices. Additionally does ApplicationData.Current provide references to the app's temporary, local and roaming folder.
Unfortunately there's no built-in way to check for the available free storage size / free disk space at those locations, although there are scenarios where that information can be essential, especially when dealing with removable devices. But no worries, the good old Win32 has it covered with the GetFreeDiskSpaceEx  function and it can be used with Windows 8 and Windows Phone 8. In order to use it from managed code it just has to be called through P/Invoke or wrapped in a WinRT component which I prefer nowadays, therefore this post provides a short WinRT C++/Cx snippet.

I assume you know how to create a custom C++/Cx WinRT component with Visual Studio, if not go back to my previous blog post which shows just that.


How it works

1. Open the generated precompiled header file pch.h of your WinRT component's Visual Studio project and add an include for windows.h:
   

   // pch.h - Header for standard system include files.
   #pragma once
   
   #include <windows.h>

   
   
2. Open the header file of your component and add the method declaration of GetAvailableBytes to your WinRT component which will internally use the GetFreeDiskSpaceEx, but only takes a path as string parameter and returns a WinRT uint64 (unsigned long) type with the available free space in bytes.
   

   namespace MyNativeStuff
   {
       public ref class MyStorageExtensions sealed
       {
       public:
           uint64 GetAvailableBytes(Platform::String^ path);
       };
   }

   
   
3. Add the method implementation in the source file of the component (.cpp).
   The GetDiskFreeSpaceEx function takes a pointer to an ULARGE_INTEGER which is an union from ancient times when compilers didn't support 64 bit types. Our method then returns the filled unsigned long QuadPart of it.
   

   #include "pch.h"
   #include "MyNativeStuff.h"
   
   using namespace MyNativeStuff;
   using namespace Platform;
   
   uint64 MyStorageExtensions::GetAvailableBytes(Platform::String^ path)
   {
       ULARGE_INTEGER availableBytesToCaller;
       availableBytesToCaller.QuadPart = 0;
   
       GetDiskFreeSpaceEx(path->Data(), &availableBytesToCaller, NULL, NULL);
   
       return availableBytesToCaller.QuadPart;
   }

   
   
4. You are now ready to use the component in your managed C# code.
   

   var myNativeComponent = new MyNativeStuff.MyStorageExtensions();
   
   // Create a folder in temp folder of the app and check the available free space
   var myTempFolder = await ApplicationData.Current.TemporaryFolder.CreateFolderAsync("test", CreationCollisionOption.OpenIfExists);
   var availableSpaceTempFolder = myNativeComponent.GetAvailableBytes(myTempFolder.Path);
   
   // Create a folder in videos lib and check the available free space
   var myVideoFolder = await KnownFolders.VideosLibrary.CreateFolderAsync("test", 
   CreationCollisionOption.OpenIfExists);
   var availableSpaceVideoLib = myNativeComponent.GetAvailableBytes(myVideoFolder.Path);

Note, the GetFreeDiskSpaceEx works with any directory path the calling code is allowed to access.

Windows Phone Natives - How to Leverage Native Code on Windows Phone

With Windows Phone 8 the possibility to use native code for development was introduced to the public SDK. It's a powerful feature and it can help to improve the performance for certain heavy computing tasks, reduce the memory footprint or just to leverage certain APIs which are only available in native code. Media Foundation or Direct3D for example are native only, but it could as well be a proprietary library from another third party written in C/C++.
In order to use native code on Windows Phone one has to write a native Windows Phone Runtime Component (WinPRT). Such a WinPRT library encapsulates the native code internally and only exposes WinRT types, therefore it can be consumed through the WinMD projections also in managed C# projects.

This blog post provides an introduction with an easy sample to get started. The MSDN also provides a very good Windows Phone native code overview, a list of the available Win32 and COM APIs on Windows Phone including an index of all supported Win32 functions. It contains such important things like the native sockets API Winsock, the National Language Support (NLS) functions for all things around region, language and culture and much more native APIs.

How it works

1. First of all you need to create a Windows Phone App 8 project with Visual Studio.


2. Then add a new Visual C++ Windows Phone Runtime Component (WinPRT) project to the solution.
   
   


3. Now you need to add the solution's WinPRT project as reference to the App project. Note that Visual Studio will automatically take care of adding the required ActivatableClass definition to your consuming App project. Refer to this if you ever need to add a WinRT component manually to another project.
   


4. Open the generated precompiled header file pch.h and add an include for windows.h:
   

   // pch.h - Header for standard system include files.
   #pragma once
   
   #include <windows.h>

   
   For this sample we use the Win32 function IsProcessorFeaturePresent to query if certain processor features are supported. This function is defined in windows.h.
   
   
5. Open the header file of your component (ProcessorInfoComponent.h) and add the method declaration of IsNeonSupported to our WinPRT component which will internally use the IsProcessorFeaturePresent, but only expose a WinRT bool type. The MSDN has a nice Quick Reference which provides a table how Standard C++ types and constructs map to C++/Cx WinRT.
   

   namespace ProcessorInfoComponent
   {
       public ref class ProcessorInfoProvider sealed
       {
       public:
          bool IsNeonSupported();
       };
   }

   
   
6. Open the source file (ProcessorInfoComponent.cpp) and add the method implementation to our WinPRT component which will call IsProcessorFeaturePresent and return the result.
   The IsNeonSupported wrapper method here will provide the information if the processor supports the ARM VFP/Neon: 32 x 64bit register bank. There are many other queryable parameters available beside PF_ARM_VFP_32_REGISTERS_AVAILABLE used here. Those are defined in winnt.h and partly documented at the MSDN.
   

   #include "ProcessorInfoComponent.h"
   using namespace ProcessorInfoComponent;
   
   bool ProcessorInfoProvider::IsNeonSupported()
   {
      return IsProcessorFeaturePresent(PF_ARM_VFP_32_REGISTERS_AVAILABLE);
   }

   
   
7. You are now ready to use the component in your managed C# code.
   

   private void Button_Click(object sender, RoutedEventArgs e)
   {
      var infoProvider = new ProcessorInfoComponent.ProcessorInfoProvider();
      var hasNeon = infoProvider.IsNeonSupported();
   
      Info.Text = string.Format("Is ARM Neon supported: {0}", hasNeon);
   }

The complete sample solution can be downloaded here.
If you run the sample in the emulator you will see IsNeonSupported() returns false, since it's running on the x86 CPU, but if you execute the sample on a device IsNeonSupported() should return true. Keep in mind you are now using native code so you have to compile a build for ARM (device) or x86 (emulator). AnyCPU won't work anymore.

The presented is just a very easy sample but it already shows how native code on Windows Phone can help you to access information not available otherwise.

What are you Awaiting for - How to Turn a C/C++ Callback into a C++/Cx WinRT IAsyncAction

Windows and Windows Phone 8 and its WinRT / WinPRT component model provide a nice way to leverage good ol' native C/C++ libraries in all WinMD language projections by wrapping them in a WinRT C++/Cx component. Such a native WinRT component only exposes WinRT types and can therefore be consumed through the WinMD projections also in C# or WinJS.
Often those good ol' native libraries provide events or callback functions for asynchronous calls. This means one would also have to provide a WinRT wrapper for those events and callbacks as well, although the WinRT has the nice IAsyncAction and IAsyncOperation constructs together with the Parallel Patterns Library (PPL) which make the WinRT component way better to use.
This post describes how to plug both worlds together to turn your good ol' C++ code into rose colored C++/Cx consumable through WinMD.

We won't go too deep into C++/Cx in general here. There's a good intro at the MSDN and also a nice Quick Reference which provides a table how Standard C++ types and constructs compare to C++/Cx. I also don't cover how the PPL and WinRT async works here, but there's a great MSDN page: Creating Asynchronous Operations in C++ for Windows Store Apps.


Assuming you have a good ol' native interface like this with a defined callback template:

template <typename TCallback>
HRESULT StartAsyncOperation(const TCallback &callback)
{
...
}

It could be used like this using a C++11 lambda as callback function:

StartAsyncOperation([this](HRESULT error) -> HRESULT
{
   // Do whatever here after the async is done...
   // Notify the calling code through an event or another callback 
   // that the async operation has finished.
   return S_OK;
});

It's worth mentioning this will also work with C function pointers and you can use a C++ 11 lambda for it as long as the lambda does not capture any variable. Stateless lambdas will just degrade to function pointers.

// Definition of fucntion pointer and a function expecting it as parameter
typedef void (*SomeOtherCallback)(int param1);

FunctionExpectingSomeOtherCallback(SomeOtherCallback cb);

// Example call using a stateless lambda
FunctionExpectingSomeOtherCallback([](int param1)
{
   // Perform some operation with param1
});

This is how your C++/Cx WinRT component's method which wraps the above C++ template could look like:

Windows::Foundation::IAsyncAction^ MyWinRtComponent::RunAsync()
{
 // Setup  the Task Completion Event and the async Task
 Concurrency::task_completion_event<void> tce;
 auto tsk = Concurrency::create_task(tce);
 Windows::Foundation::IAsyncAction^ asyncOp = Concurrency::create_async( [tsk]() 
            -> Concurrency::task<void> 
 {
  return tsk;
 });

 // Run good ol' native code wih callback defined as C++ lambda
 StartAsyncOperation([this, tce](HRESULT error) -> HRESULT
 {
  try
  {
   // Check for error and wrap in platfrom exception
   if (FAILED(error))
   {
    throw Platform::Exception::CreateException(error);
   }
  }
  catch(...)
  {
   // Pass exception on to calling code using the 
   // Task Completion Event's dedicated method
   tce.set_exception(std::current_exception());
   return error;
  } 

  // Set the Task Completion Event's Result to mark the Task as complete
  // If a IAsyncOperation is used the result value is passed
  tce.set();

  return S_OK;
 });

 return asyncOp;
}

You could then use your WinRT component in C# like this:

var component = new MyWinRtComponent();
await component.RunAsync();

And similar in WinJS using a JS Promise:

this._component.runAsync().then(function () {
 WinJS.log("My component finished the async call! :-)", null, "status");
});

Way better API for the custom WinRT component if you ask me!
The trick to achieve that is the usage of the PPL's create_async, create_task and especially the task_completion_event which provides a nice way to make that callback-based model work with the proper WinRT modern async Task-based way.