Carlos

Windows Active Directory Explorer - Debugger

So many of you might be asking I came up with a great idea to build the old “ADHC” {which for many reasons I can not use that name} then I changed it to DSExplorer but that didn’t sound right. “The Wong Guy” {Mr B. Wong} a good friend of mine and probably one of the best Microsoft Exchange guys that **I** have seen in a while, recommended two names [See comments on my ADHC is now known as … post] the one I liked was WADE – Windows Active Directory Explorer. So from now on we have WADE as the application name.

Now this is not the reason that I have been quite :) I have been doing a lot of testing in my test lab at home; it’s a basic network all VM’s running of one machine. Five machines two forests both with a root domain and a child domain and an exchange server.

Now I always handle my errors in code and have certain ways of displaying the errors to the user however its sometimes difficult to marry a context to a error message to what’s happening in the code.

A great coder Joao Paulo Carreiro introduced me to the awesome Log4net logging library (which has now been bought by Apache so who knows for how much longer its going to be free). This library introduces a easy way to log stuff from your code in many different ways:

1. Text files
2. Databases
3. SMTP messages
4. UDP broadcast

I needed a way to be able to log exactly what is going on at each line of code, errors and abnormalities in the code in different environments.

The problem: Once I start something I try make it so fancy I run away with the entire idea. I decided to make use of the UDP broadcast method to display my logs. The reason being, I needed a way to see each log as it was happening and instead of writing the log to a text and have a form reading the text file and getting file locks etc or logging to a database and either building a trigger to send info to a form or constantly pinging the database {and the additional database software you have to install on your machine), I found that UDP was a lightweight solution. Later I found it wasn’t the easiest data to work with but anyway.

So I started creating a debug form that can be run while you are running WADE, this will log everything I need to be able to debug the app that has just run in your environment. First off I don’t hide any data, second of all I simple export it to a CSV when I am done which you can view nothing is hidden. WADE in debug mode is controlled (for now) by a Boolean value in the config file ”EnableDebugger=True” I am deciding if I should not move that as a parameter i.e. WADE.Exe /Debug.

So lets get into what the debugger looks like and you can see what I have been busy with:

First off when you have the debugger running as  you start WADE you will get a warning that the debugger is running: The reason being any application that has an attached debugger has slower performance, and its easy to forget that you have the debugger on as it lives in your system tray. The image below shows you the system tray warning.

Then if this is the first time you are running WADE you will get prompted by your Windows Firewall about WADE trying to send data over the network.

1. This is great cause you know your Windows Firewall is working {you should have it running if you have any other third party firewall you would need to follow the steps below}
2. You will see WADEs name in the Firewall warning so you know what application is trying to access the network
3. WADE isn’t trying to send data “over” the network, since you sending data to your self (loopback) it needs to go “out” and then come back “in” even though you sending it to yourself. A lot of our products does this with UDP messages i.e. SQL Server
4. Click on the Unblock button (as seen in the screen shot below), if you don’t want to be prompted again go to the Windows Firewall and make an exception called “WADE”, type UDP, Port: 5670 (this value is configrable for what ever port you want)

 

Now that we have all the little niggles out the way we can debug (btw – you only have to do the Firewall settings ONCE if you create an exception for WADE). Once the debugger has started WADE is activated and you ready to go, as you navigate your network through WADE the CODE PATH, ERRORS,WARNINGS and FATAL exceptions will be logged to the debugger not your network details, you will be able to see EXACTLY what is being logged in any case.

So adding some “bling” to the debugger (I really should have just carried on with WADE but I like making my apps look good) I then added a system tray icon which is fully animated, i.e. as UDP packets come in and received the icon changes (kinda like the two blue computer for your network connection). This is important as you don’t want your screen real estate taken up by to many windows from one application and you won’t really care what the debugger is doing most of the times. The important part of the debugger is that at any time you can right click and view what is going on in the debugger and then hide it!

Secondly if you want to see the last debug message you just click on the system tray icon and you will get the last debug message displayed to you (see below)

So let’s look at the MEAT of the debugger we have been looking at the BLING, when you click “Show Debugger” you will get a window with three sections (for now), Section 1 is a datagrid that shows each debug message. It is color coded for quick viewing.

1. Powered Blue ---> Normal Information Message
2. Orange ---> Error message
3. Red (or rather “Tomato Red”) ---> Fatal error

Section 2 and 3 are basically to debug if anything goes wrong with the debugger :)

Well now that I can debug the application correctly when its not running on my machine I am carrying on with development on the application and things are looking really good. Alpha testers are needed soon!!!

Take care

Carlos