Using Lumberjack²

This is the easy part, once you got the application set up and launch it, you see the following interface:

Main Interface

1. This panel indicates, whether WCF is configured to capture service calls. Make sure to disable event capturing at the end of your debugging session. Click to toggle the WCF configuration status.
2. This button shows, whether Lumberjack is currently collecting events. When displaying Idle, all WCF events coming in will be discarded. You may ask yourself, why this is a separate option in addition to enabling/disabling the event hook. The reason for this is, that there is a perofrmance penalty, when switching WCF settings, however there is none discarding events. Clicking the button will togglle between collecting and not collecting events.
3. This button shows the number of WCF messages in store. Click it to clear the message store.
4. This button sends you to the about screen.
5. In this panel you can specify search criteria for your queries. Perhaps the only unclear things here are source and metadata. Source is the hosting process that processed the WCF call. This may be interesting, when having multiple App Pools configuredin IIS. The App Pool is prefixed with the name of the machine. Metadata is a dictionary of additional properties attached to each message. When having non Rest Services, this initially starts empty and can be filled using extensions. For Rest Services this contains things like HTTP headers and status codes.
6. This panel displays the request/response of the selected message.
7. This grid displays the messages matching the results of the last search.

Debugging Workflow

To get good results with the application, I suggest to make small captures using the active/idle button and then search inside the results. Errors are marked in red in the list view to give you some additional hints. The message store is not indexed like a real database, hence queries against large stores can get quite time consuming - clear your store often.

Metadata

Once you get service calls that contain metadata, the dropdown will be filled with known keys:

An additional source of metadata are extensions which will be discussed in more detail later. Metadata will also be displayed in the message panel. Here it will be grouped to request/response and global metadata. All searches including metadata will be using contains clauses. There is no way to search for specific values.

Source

The sources dropdown is populated automatically (just like metadata). It is technically possible to have other machines submit data to your Lumberjack client. In that case, these machines would also show up - however I did not yet enable this feature in the installation process, so for now it will always be the local maschine (with different App Polls showing up). If you would like me to add support for remote debugging, just drop me a mail.