Windows Phone Power Tools

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 09:47:10 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio.

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

If you're writing a library you're going to want to select your own GUID that doesn't clash with the standard app developer one and then publicize it so that developers can collect it when they use your library.

Compiling the Manifest

In order to decode your events from the ETL (Event Trace Log) the system needs to read your manifest out of a binary that has your manifest compiled into it as a resource. While you can register arbitrary providers (and their associated manifests) on your local machine, you can't do this on the Phone, so the Phone won't be able to recognize your events. To work around this we will be post-processing your events on your local machine using an x86 (or x64) resource only dll that includes your manifest.

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

While the name is generally unimportant for clarity sake we’ll go with the name of the provider, In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command (substitute your manifest name:

mc -um Phone-Direct3DXaml-App.man
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Registering your manifest on your local machine allows you to decode your events so that they don't show up as "unknown". If you run VS as admin you can have you can do this as part of the compile step, otherwise you can do it manually using the same commands as below (just expand the paths):

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:
```
#pragma once 
#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"
```
Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Writing Events from Managed Code

Our first order of business will be creating a WinRT class to expose the events to Managed code:

Right click on your existing Native WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once
#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{

private:

Etw() {};

public:

};

}

Don’t forget to add the namespace declaration to Etw.cpp as well.

Now add functions for provider registration and deregistration and a function that represents each event macro in your header (search for "EventWrite").

Recommendation: make your functions static (which matches the private constructor above) so that you don't have to instantiate the Etw object everywhere.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{
private:
Etw() {};

public:
static void RegisterProvider();
static void UnregisterProvider();
static void WriteInitialized();
static void WriteFramerate(float fps);
static void WriteFrameStart();
static void WriteFrameEnd();

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent
{

void Etw::RegisterProvider()
{
EventRegisterPhone_Direct3DXaml_App();
}

void Etw::UnregisterProvider() |
{
EventUnregisterPhone_Direct3DXaml_App();
}

void Etw::WriteInitialized()
{
EventWriteInitialized();
}

void Etw::WriteFramerate(float fps)
{
EventWriteFramerate(fps);
}

void Etw::WriteFrameStart()
{
EventWriteFrameStart();
}

void Etw::WriteFrameEnd()
{
EventWriteFrameEnd();
}

}

Word to the wise: your function names cannot match your task names. In the example above you cannot have a function named simply "Initialized" since that is the same name as one of my tasks (you'll know you've done this when you get Template cast errors).

Now, in your app constructor / initializer code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

And we’re done!

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 09:44:54 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio.

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

While the name is generally unimportant for clarity sake we’ll go with the name of the provider, In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command (substitute your manifest name:

mc -um Phone-Direct3DXaml-App.man
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:
```
#pragma once 
#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"
```
Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Writing Events from Managed Code

Our first order of business will be creating a WinRT class to expose the events to Managed code:

Right click on your existing Native WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once
#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{

private:

Etw() {};

public:

};

}

Don’t forget to add the namespace declaration to Etw.cpp as well.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{
private:
Etw() {};

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent
{

void Etw::RegisterProvider()
{
EventRegisterPhone_Direct3DXaml_App();
}

void Etw::UnregisterProvider() |
{
EventUnregisterPhone_Direct3DXaml_App();
}

void Etw::WriteInitialized()
{
EventWriteInitialized();
}

void Etw::WriteFramerate(float fps)
{
EventWriteFramerate(fps);
}

void Etw::WriteFrameStart()
{
EventWriteFrameStart();
}

void Etw::WriteFrameEnd()
{
EventWriteFrameEnd();
}

}

Now, in your app constructor / initializer code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

And we’re done!

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 09:39:50 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio.

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

While the name is generally unimportant for clarity sake we’ll go with the name of the provider, In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command (substitute your manifest name:

mc -um Phone-Direct3DXaml-App.man
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:
```
#pragma once 
#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"
```
Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Writing Events from Managed Code

Our first order of business will be creating a WinRT class to expose the events to Managed code:

Right click on your existing Native WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once
#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{

private:

Etw() {};

public:

};

}

Don’t forget to add the namespace declaration to Etw.cpp as well.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{
private:
Etw() {};

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent
{

void Etw::RegisterProvider()
{
EventRegisterPhone_Direct3DXaml_App();
}

void Etw::UnregisterProvider() |
{
EventUnregisterPhone_Direct3DXaml_App();
}

void Etw::WriteInitialized()
{
EventWriteInitialized();
}

void Etw::WriteFramerate(float fps)
{
EventWriteFramerate(fps);
}

void Etw::WriteFrameStart()
{
EventWriteFrameStart();
}

void Etw::WriteFrameEnd()
{
EventWriteFrameEnd();
}

}

Now, in your app constructor / initializer code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

And we’re done!

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 09:21:32 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio.

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

I usually set the name to the name of my provider. In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command:
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:
```
#pragma once 
#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"
```
Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Writing Events from Managed Code

Our first order of business will be creating a WinRT class to expose the events to Managed code:

Right click on your existing Native WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once
#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{

private:

Etw() {};

public:

};

}

Don’t forget to add the namespace declaration to Etw.cpp as well.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{
private:
Etw() {};

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent
{

void Etw::RegisterProvider()
{
EventRegisterPhone_Direct3DXaml_App();
}

void Etw::UnregisterProvider() |
{
EventUnregisterPhone_Direct3DXaml_App();
}

void Etw::WriteInitialized()
{
EventWriteInitialized();
}

void Etw::WriteFramerate(float fps)
{
EventWriteFramerate(fps);
}

void Etw::WriteFrameStart()
{
EventWriteFrameStart();
}

void Etw::WriteFrameEnd()
{
EventWriteFrameEnd();
}

}

Now, in your app constructor / initializer code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 09:20:36 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio,

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

I usually set the name to the name of my provider. In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command:
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:
```
#pragma once 
#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"
```
Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Writing Events from Managed Code

Our first order of business will be creating a WinRT class to expose the events to Managed code:

Right click on your existing Native WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once
#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{

private:

Etw() {};

public:

};

}

Don’t forget to add the namespace declaration to Etw.cpp as well.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent
{

public ref class Etw sealed
{
private:
Etw() {};

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent
{

void Etw::RegisterProvider()
{
EventRegisterPhone_Direct3DXaml_App();
}

void Etw::UnregisterProvider() |
{
EventUnregisterPhone_Direct3DXaml_App();
}

void Etw::WriteInitialized()
{
EventWriteInitialized();
}

void Etw::WriteFramerate(float fps)
{
EventWriteFramerate(fps);
}

void Etw::WriteFrameStart()
{
EventWriteFrameStart();
}

void Etw::WriteFrameEnd()
{
EventWriteFrameEnd();
}

}

Now, in your app constructor / initializer code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 08:37:42 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio,

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

I usually set the name to the name of my provider. In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command:
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:

#pragma once 

#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"

Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Creating a WinRT Wrapper for Managed code

I'd like to be able to use to my events from Managed code, so my first order of business will be creating a WinRT class to expose the events to Managed code.

Right click on your existing WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

};

}

Also make sure to add the namespace declaration to Etw.cpp

Now add functions for provider registration and deregistration and a function that represents each event macro in your header (search for "EventWrite").
Recommendation: make your functions static (which matches the private constructor above) so that you don't have to instantiate the Etw object everywhere.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

static void RegisterProvider();

static void UnregisterProvider();

static void WriteInitialized();

static void WriteFramerate(float fps);

static void WriteFrameStart();

static void WriteFrameEnd();

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent

{

void Etw::RegisterProvider()

{

EventRegisterPhone_Direct3DXaml_App();

}

void Etw::UnregisterProvider()

{

EventUnregisterPhone_Direct3DXaml_App();

}

void Etw::WriteInitialized()

{

EventWriteInitialized();

}

void Etw::WriteFramerate(float fps)

{

EventWriteFramerate(fps);

}

void Etw::WriteFrameStart()

{

EventWriteFrameStart();

}

void Etw::WriteFrameEnd()

{

EventWriteFrameEnd();

}

Now, in your app constructor / initializor code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 08:35:09 GMT

Using ETW Events within a Windows Phone 8 Application

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio,

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

I usually set the name to the name of my provider. In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command:
Specify the "No Entry Point" option in the linker (since this will be a resource only dll):
Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"
wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.
Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files
2. In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file that includes your generated header file:

#pragma once 

#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"

Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Creating a WinRT Wrapper for Managed code

I'd like to be able to use to my events from Managed code, so my first order of business will be creating a WinRT class to expose the events to Managed code.

Right click on your existing WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

};

}

Also make sure to add the namespace declaration to Etw.cpp

Now add functions for provider registration and deregistration and a function that represents each event macro in your header (search for "EventWrite").
Recommendation: make your functions static (which matches the private constructor above) so that you don't have to instantiate the Etw object everywhere.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

static void RegisterProvider();

static void UnregisterProvider();

static void WriteInitialized();

static void WriteFramerate(float fps);

static void WriteFrameStart();

static void WriteFrameEnd();

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent

{

void Etw::RegisterProvider()

{

EventRegisterPhone_Direct3DXaml_App();

}

void Etw::UnregisterProvider()

{

EventUnregisterPhone_Direct3DXaml_App();

}

void Etw::WriteInitialized()

{

EventWriteInitialized();

}

void Etw::WriteFramerate(float fps)

{

EventWriteFramerate(fps);

}

void Etw::WriteFrameStart()

{

EventWriteFrameStart();

}

void Etw::WriteFrameEnd()

{

EventWriteFrameEnd();

}

Now, in your app constructor / initializor code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

Updated Wiki: Using ETW Events within a Windows Phone 8 Application

nachmore — Mon, 13 May 2013 08:06:00 GMT

The sample code used in this article can be found <here> and is based on the standard “Windows Phone Direct 3D with XAML App” project template from Visual Studio,

The Manifest

Your ETW manifest is an XML file which defines what your events look like so that event viewers can intelligently display your events once you've collected them in a log.

Windows Phone uses the same manifests as Windows, so the regular documentation applies:

Writing an Instrumentation Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs.85).aspx
Sample Manifest: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996912(v=vs.85).aspx

The sample manifest that we'll be using can be found <here>.

Provider GUID

If you're developing a regular application you will want to use the developer GUID for your provider: 7A68C8E0-BE90-4039-9048-2A69F64BDF3C

Compiling the Manifest

First, add a new project to your solution:

File -> Add -> New Project -> Other Languages -> Visual C++ -> Win32 -> Win32 Project

I usually set the name to the name of my provider. In this case "Phone-Direct3DXaml-App"
In the wizard select an "Application Type" of "DLL", "Empty Project" and clear any other check boxes:
Add the manifest to your project (so that it appears in your solution and you can edit it in VS)
Add the following pre-build command:

Specify the "No Entry Point" option in the linker (since this will be a resource only dll):

Make sure the project is set to build with everything else by going to Build -> Configuration Manager and selecting "Build" next to your project:

Registering Your Manifest

Registering your manifest on your local machine allows you to decode your events so that they don't show up as "unknown". If you run VS as admin you can have VS do this every time you make a compile, otherwise you can expand the macros below and run this yourself from an elevated command prompt:

Right click your project -> Properties -> Config… -> Build Events -> Post-Build Events -> Command Line (hit the little down arrow and click <edit>)
Paste in the follow lines:

wevtutil um "$(ProjectDir)Phone-Direct3DXaml-App.man"

wevtutil im $(ProjectDir)Phone-Direct3DXaml-App.man /mf:"$(TargetPath)" /rf:"$(TargetPath)"

The above lines unregister your provider (which may, or may not already be registered) and then reregister it providing full paths to your resource dll. Unregistering is required to update your provider with any new changes you may have made.

Next, make sure that the resource project is set to build first in your solution (so that it generates it's files before anyone can use them) by right clicking on your solution -> Project Build Order -> Dependencies. Under your native project select the manifest project and then verify in the "Build Order" tab that it will build first.

Finally

So we have our resource events, now, let's use them!

Optional Step - easy header access:
1. Add the header file generated from your manfiest to your project. If you are using the above steps to compile your manifest then you should find the header in the root of your manifest project. The file will be added with a small link icon to indicate that the file is in a different location to the rest of your project files

In case you ever change anything, and so that you don't have to #include the full path to the header file every time create a EtwEvents.h file with the following contents:

#pragma once

#include "..\..\Phone-Direct3DXaml-App\Phone-Direct3DXaml-App.h"

Add a call to the EventRegister* macro before using any of the marker macros for the first time
Add a call to the EventUnregister* macro during your shutdown code
You can now include "EtwEvents.h" wherever needed and simply call EventWrite<func> (you can find the names in your ETW header).

Creating a WinRT Wrapper for Managed code

I'd like to be able to use to my events from Managed code, so my first order of business will be creating a WinRT class to expose the events to Managed code.

Right click on your existing WinRT project (or, if you don't have one, add a new one) -> Add -> Class.
In the wizard give your class whatever name you like (we'll be using Etw)
Since we need this to be a WinRT class you'll need to sprinkle some WinRT sugar around your class definition (Etw.h) to make it visible to managed code. At the same time we're going to make the constructor private and remove the destructor since the Etw class won't maintain any state and all of its members will be static.

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

};

}

Also make sure to add the namespace declaration to Etw.cpp

Now add functions for provider registration and deregistration and a function that represents each event macro in your header (search for "EventWrite").
Recommendation: make your functions static (which matches the private constructor above) so that you don't have to instantiate the Etw object everywhere.

Etw.h

#pragma once

#include "EtwEvents.h"

namespace PhoneDirect3DXamlAppComponent

{

public ref class Etw sealed

{

private:

Etw(void) {};

public:

static void RegisterProvider();

static void UnregisterProvider();

static void WriteInitialized();

static void WriteFramerate(float fps);

static void WriteFrameStart();

static void WriteFrameEnd();

};

}

Etw.cpp:

#include "pch.h"

#include "Etw.h"

namespace PhoneDirect3DXamlAppComponent

{

void Etw::RegisterProvider()

{

EventRegisterPhone_Direct3DXaml_App();

}

void Etw::UnregisterProvider()

{

EventUnregisterPhone_Direct3DXaml_App();

}

void Etw::WriteInitialized()

{

EventWriteInitialized();

}

void Etw::WriteFramerate(float fps)

{

EventWriteFramerate(fps);

}

void Etw::WriteFrameStart()

{

EventWriteFrameStart();

}

void Etw::WriteFrameEnd()

{

EventWriteFrameEnd();

}

Now, in your app constructor / initializor code you can run Etw.RegisterProvider() and in your shutdown code you can call Etw.UnregisterProvider().

Updated Wiki: Temporary Post Used For Theme Detection (845bc7d9-b28b-4948-8b92-ee0240ccafe6 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

nachmore — Mon, 13 May 2013 07:35:08 GMT

This is a temporary post that was not deleted. Please delete this manually. (f72a1017-6ad4-405f-b6cc-1494d6a6fd03 - 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Commented Unassigned: can not select a device [37]

MoonRaven — Tue, 07 May 2013 12:21:11 GMT

When I have the device is connected, the drop-down box is empty..
version:2.05.486289
Comments: To be honest, I have not had this problem ever since.

New Post: Microsoft.Web.Infrastructure Version 1.0.0.0 be installed in the Global Assembly Cache first

liisa57 — Thu, 02 May 2013 14:15:23 GMT

Thanks a lot. It works! :) :)

Updated Release: Windows Phone Power Tools 2.5.07 for WP 8 (Apr 30, 2013)

nachmore — Wed, 01 May 2013 16:47:46 GMT

Newly updated version of the tools that supports Windows 8 and the Windows Phone 8 SDK. This version should work with both WP 7.5 devices / emulators and the WP8 devices and emulators.

Please note! The profiler feature is in Beta and is missing some basic fit, finish and polish, please report bugs and feature requests on our issue tracker (http://wptools.codeplex.com/workitem/list/basic).

Changelist

v2.5.07

Removed all references to System.Web
Cut down download size from 3.2MB to 0.4MB

v2.5.06

Removed dependency on Web.Mvc
Fixed escaping of etl paths when opening them in wpa

v2.5.01-5

Removed debug code that was causing a crash when configuring the profiler for the first time
Slight tweak to the standard trace session to collect CPU usage
Added prompt to restart the Power Tools after profiler installation (CoreCon needs to be refreshed)
Fixed profiler analytics

v2.5

After quite a bit of work the profiler is finally here! It's a full(ish) ETW profiler that gives you near complete control over your profiling sessions. It's still in Beta, here are some caveats / coming features which should all be fixed in future versions:
- ETLs are saved to My Documents
- ETLs are always, automatically, opened in WPA
- There is no way to add custom providers
- There is no way of saving a custom scenario to use again
- You can stop an in-progress profiler, but you can't cancel one
- There isn't much documentation - but I'm working on it. Volunteers?
Bug 35: Fixed incorrect url for reporting issues - thanks OmegaMan!
Some small amounts of code cleanup and performance fixes

v2.041

BUG 28: The fix to bug 27 caused an internal exception when trying to get file data for WP7 which broke the IsolatedStorage explorer for WP7. This is now fixed, though WP7 is stuck with limited file information (while WP8 has the full set).

v2.04

BUG 27: Fixed issue where some file properties were not being displayed in the Remote Isolated Storage explorer
BUG 26: Cap number of remembered xaps at a reasonable cap (100). There is also infrastructure to make this configurable in the future.
Some slight tweaks to the elevate button to make it more visible

Since we haven't heard about any blocking issues this version is also being marked as release. yay!

v 2.03 Beta

Removed dependency on Microsoft.Web.Infrastructure that was blocking some installs (bug #25)
UI tweaks
All previous xaps are remembered and displayed in a ListBox for your future selection
Analytics are now disabled for debug builds or when running under debugger

v 2.02 Beta

Added analytics to figure out what areas are most used and need more attention
1st round of feedback from David Rickard (thanks!)
- File selection textbox now stretches with the window
- Tweaked unhandled exception message
- Window size and position are now restored on launch

v 2.0.1 Beta

Removed manifest signing to clear up future upgrade paths
Fixed Bug #23 which blocked the tool running on ZH-CN
Rewrote IsolatedStorage Drag and Drop to make it a lot more robust

v 2.0 Beta

Support for both WP7.5 and WP8 (device + emulator)
New UI (still rough around the edges)

Planned items

Actions on a background thread
More UI refinement
More detailed error messages to match new error codes
Profiler

Released: Windows Phone Power Tools 2.5.07 for WP 8 (Apr 30, 2013)

Wed, 01 May 2013 16:47:46 GMT

Removed all references to System.Web
Cut down download size from 3.2MB to 0.4MB

v2.5.06

Removed dependency on Web.Mvc
Fixed escaping of etl paths when opening them in wpa

v2.5.01-5

Removed debug code that was causing a crash when configuring the profiler for the first time
Slight tweak to the standard trace session to collect CPU usage
Added prompt to restart the Power Tools after profiler installation (CoreCon needs to be refreshed)
Fixed profiler analytics

v2.5

After quite a bit of work the profiler is finally here! It's a full(ish) ETW profiler that gives you near complete control over your profiling sessions. It's still in Beta, here are some caveats / coming features which should all be fixed in future versions:
- ETLs are saved to My Documents
- ETLs are always, automatically, opened in WPA
- There is no way to add custom providers
- There is no way of saving a custom scenario to use again
- You can stop an in-progress profiler, but you can't cancel one
- There isn't much documentation - but I'm working on it. Volunteers?
Bug 35: Fixed incorrect url for reporting issues - thanks OmegaMan!
Some small amounts of code cleanup and performance fixes

v2.041

BUG 28: The fix to bug 27 caused an internal exception when trying to get file data for WP7 which broke the IsolatedStorage explorer for WP7. This is now fixed, though WP7 is stuck with limited file information (while WP8 has the full set).

v2.04

BUG 27: Fixed issue where some file properties were not being displayed in the Remote Isolated Storage explorer
BUG 26: Cap number of remembered xaps at a reasonable cap (100). There is also infrastructure to make this configurable in the future.
Some slight tweaks to the elevate button to make it more visible

Since we haven't heard about any blocking issues this version is also being marked as release. yay!

v 2.03 Beta

Removed dependency on Microsoft.Web.Infrastructure that was blocking some installs (bug #25)
UI tweaks
All previous xaps are remembered and displayed in a ListBox for your future selection
Analytics are now disabled for debug builds or when running under debugger

v 2.02 Beta

Added analytics to figure out what areas are most used and need more attention
1st round of feedback from David Rickard (thanks!)
- File selection textbox now stretches with the window
- Tweaked unhandled exception message
- Window size and position are now restored on launch

v 2.0.1 Beta

Removed manifest signing to clear up future upgrade paths
Fixed Bug #23 which blocked the tool running on ZH-CN
Rewrote IsolatedStorage Drag and Drop to make it a lot more robust

v 2.0 Beta

Support for both WP7.5 and WP8 (device + emulator)
New UI (still rough around the edges)

Planned items

Actions on a background thread
More UI refinement
More detailed error messages to match new error codes
Profiler

Commented Issue: Failure to launch, requiring Microsoft.Web.Infrastructure [25]

mstorsjo — Wed, 01 May 2013 10:04:22 GMT

As reported by toaderadrian:

I'm having some problems with Power Tools for Windows Phone 8 platform since yesterday. Suddenly it stopped working and when I try to install it again I get an error saying that I need a System Update and I require the assembly Microsoft.Web.Infrastructure Version 1.0.0.0 install in GAC. Don't know how to do that..

This also occurred to other two colleagues of mine. Do you have a solution for this?
Comments: It was fixed in 2.5.07 (see https://wptools.codeplex.com/workitem/38).

New Post: Microsoft.Web.Infrastructure Version 1.0.0.0 be installed in the Global Assembly Cache first

nachmore — Wed, 01 May 2013 06:22:06 GMT

Hey Liisa57,

This is now fixed in 2.5.07 :)

Oren

Closed Unassigned: web.infrastructure [38]

nachmore — Wed, 01 May 2013 06:21:26 GMT

See attached.
Comments: Closed in 2.5.07

Commented Unassigned: web.infrastructure [38]

nachmore — Wed, 01 May 2013 06:21:11 GMT

See attached.
Comments: Awesome! Great to hear that this fixed it.

Commented Unassigned: web.infrastructure [38]

mstorsjo — Wed, 01 May 2013 00:12:37 GMT

See attached.
Comments: Thanks - now I've finally managed to install this!

Commented Unassigned: can not select a device [37]

nachmore — Tue, 30 Apr 2013 23:51:54 GMT

When I have the device is connected, the drop-down box is empty..
version:2.05.486289
Comments: Weird - is this consistent?

Commented Unassigned: web.infrastructure [38]

nachmore — Tue, 30 Apr 2013 23:51:12 GMT

See attached.
Comments: Ok - this should, hopefully, be fixed in 2.5.07 which I just pushed. Sorry for the rundaround and thanks for all the info!