How-to: Tracking Page Navigation in Your WinRT or WinJS Applications

Today MarkedUp released a new report type which shows how often users view all of the distinct pages inside your Windows Store applications on Windows 8; so how do you how to actually capture all of this page navigation information in your app using MarkedUp?

Easy! You can use a single method to automatically track all of the page navigation information inside of your C# / C++ / HTML5 Windows Store apps: RegisterNavigationFrame.

The RegisterNavigationFrame method allows MarkedUp to automatically detect how users navigate between pages inside your application and eliminates the need for developers to have to write their own handler code and call the PageEnter event manually.

Calling RegisterNavigationFrame in C# / XAML

If you’re using C# and XAML to develop your Windows Store applications, you’ll want to call MarkedUp.AnalyticClient.RegisterNavigationFrame inside the Application.OnLaunched method, as shown below:

Calling registerNavigationFrame in HTML5 / JavaScript

If you’re using HTML5 and JavaScript to develop your Windows Store applications, you’ll want to call MK.registerNavigationFrame inside the WinJS app.onactivated method, as shown below:

Pretty simple! If you add this single line of code to your Windows Store applications you’ll see data light up on your application page views report and on others that we’re actively developing right now!

Let us know in the comments if you have any questions.

How-to: Logging Crashes Using MarkedUp

One of the most useful use-cases for MarkedUp is the ability for it to log and analyze all of the crashes users experience when consuming your apps in the Windows Store. As a developer, your number one priority is to ensure that your users are able to consume your app!


Rather than just give you a big crash dump file, MarkedUp gives you some context around why and how the crash occurred. We have a bunch of new reports and stats built around this feature specifically that we’ll be rolling out over the next few weeks ;)

I’ve written before about how to handle last-chance exceptions using WinJS, and today I’m going to show you how to use MarkedUp to capture last-chance exceptions in both C# / XAML and HTML5 / JavaScript.

How to Set Up MarkedUp Crash Logging in WinJS and WinRT

In the most recent version of MarkedUp (0.5.5 as of writing this) we expose a new method called LogLastChanceException – this is a special method designed to persist crash dumps to disk at the very last possible moment when an application crashes.

Both C# / XAML and WinJS provide a last-chance exception handler as an event off of the Application (WinRT | WinJS) object, and this is the tool you can use to log crashes.

In C# / XAML, you can log crashes using MarkedUp’s LogLastChanceException method and the Application.UnhandledException event like this:

In WinJS (HTML5 / JavaScript), you can do the same thing using Application.onerror event:


MarkedUp writes the crash dump to disk on your user’s machine when the app crashes, and the next time the user starts your application we transmit their crash dump data back to our servers for analysis and reporting.

We preserve the time that it happened locally on that user’s machine so you’ll always have completely verifiable data to accurately correlate when a crash did or did not happen.

Further Reading

If you have any additional questions about how to set up crash logging, please refer to MarkedUp’s SDK reference documentation on crash logging or contact support at!

How-To: Last Chance Exception Handling in WinJS Applications

One of the things we designed MarkedUp to do was to be able to capture and save fatal errors that crash your Windows 8 applications and to reliably transmit them back to the developer for analysis and diagnosis.

Most fatal errors fall into one of two categories:

  1. Something went wrong with the environment outside the application, like an OS / driver error or an hardware issue; or
  2. The application failed to handle an exception thrown by the application itself.

Fatal errors in category #1 are impossible to recover from (usually because the application runtime or OS crashed) and are typically outside the control of the developer anyway.

Errors in category #2 are firmly in the control of the developer, however – and I’m going to show you how to tackle them in WinJS.

Sometimes you’re going to forget to handle an error in-context in your application – so what can you do to stop unhandled exceptions from crashing your application? Use the last-chance exception handler.

If you’ve done any serious Windows Phone 7 development, then you might have worked with LittleWatson at some point for simple last-chance exception handling and reporting – like this:

So how do you tackle this in WinJS?

The answer is fairly simple – in your default.js file you just need to chain an event handler to WinJS.Application.onerror event, like this:

In this instance I’m just using MarkedUp to transmit the fatal error message back to our servers next time the app starts (which is really the only safe way to capture a fatal error message.)

This technique has worked well for me for my Windows Phone 7 applications and should work fine for WinJS / Win8 too!