This project is read-only.


Diagnosing problems and finding bugs can be a bit challenging in paarc, due to the following reasons:
  • Several multi-threaded components are involved, and distributed over multiple places on a network (phone/emulator, PC)
  • Some features (multicast) cannot be used on one physical machine in the emulator and on the desktop simultaneously
  • Using the emulator to control an application on the same PC sometimes is impossible (see PCController sample)
  • Networking does not work when the phone is connected to the PC/Zune software, so you cannot debug on the phone

To overcome this, I have added detailed tracing to the library to aid debugging, both in the client and on the server side. This allows you to test your application on the phone and the PC as you would in a normal production setup, and follow the operations that are performed down to the method level. To make this work, both the client and server parts make use of NLog and write their log messages to a remote service. This means that you can inspect the tracing from both sources, conveniently merged in one place, which helps tremendously with correlating the client-side operations to what happens in your .NET application and vice versa.

The service implementation for this is the LogService sample project included in the library. This essentially is a WPF application that uses a self-hosted WCF service which collects the trace messages from both the PC side and WP7 side. The messages are displayed with all detail information like the timestamp, the logger name, thread id and message in a data grid.


As you can see, messages originating from the phone are tinted with this muted lime-ish color, whereas messages from the PC use a light red shade.

One new problem that arises here is that it's next to impossible to synchronize the clocks on the phone and PC exactly enough to interweave the received messages correctly. To solve this, the application allows you to shift the timestamp of the Windows Phone trace messages by a configurable amount of milliseconds back or forth. To simplify this, you can select two correlating messages, one originating from the PC, the other one from the phone, and let the application calculate the difference automatically.

Synchronization example

Using the included PCController sample, what you could do is: create a short raw touch data transmission by putting your finger on the screen and remove it. Then look through the list of received trace messages. Select the last entry originating from the phone that reads "Sending data" and is written by the "UdpSocketWrapper" logger. This is the last logged message before the actual sending happens. Then, find the corresponding entry from the PC "UdpSocketWrapper" that reads "Received Completed event from socket async event args" which ultimately reports the touch data. This is the first message on the PC side that corresponds to the sending.

With both messages selected, hit the "Calc automatically" button to let the software calculate the difference. After that, you should see that new trace messages are correctly interwoven (or at least close enough to allow inspecting the sequences), like this:


Logging to a different target

If you are interested in using a different logging target, you can simply add an NLog configuration file to the LogService application. The mechanism used internally is a customized so-called forwarding service, which means that by specifying an NLog configuration, you can simply pass through whatever trace messages are received from both the PC and phone to another logging target - this allows you to write the log messages to a file, database, another remote service or whatever other NLog target you want to use, even your custom ones.

Custom parameters used by the logging are:
  • ClientName: either "PC" or "WP7"
  • time: the original timestamp created on the PC or phone
  • threadid: the id of the thread the message was written from

This means that if you want to use what the LogService receives and write it to the console, you could use an NLog configuraton file (NLog.config) like the following:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns=""

  for information on customizing logging rules and outputs.
    <target name="console"
            layout="${event-context:time} [${event-context:ClientName}] ${logger}: ${message} (thread: ${event-context:threadid})" />            

    <logger name="*"
            writeTo="console" />

Known limitations

At the moment the url of the hosted WCF service is hard-coded to "" - if you want or need to change this, you need to change it in code and recompile the sample. This will be changed in a future update. This has been fixed in the latest change set; you can configure the service address in the UI.

At the moment, there are no known limitations.

Last edited Nov 20, 2011 at 9:03 AM by Mister_Goodcat, version 3


No comments yet.