Using PowerShell to Help Debug Third Party Dependencies

I hate when an application has a third party dependency (web service, url, ftp, etc.) mainly because it’s hard to test or even see what data you’re getting back. However, this is one awesome reason to love PowerShell. PowerShell can be used to make those calls manually so you can see what comes back and, if needed, use that data further while doing tests. For example, you have a call that gives XML has a response and use PowerShell to traverse the response using the new Invoke-WebRequest cmdlet in PowerShell v3. I’ll use the MSDN blog RSS feed as a small example here.

However, PowerShell makes it easier for us to traverse the XML by putting all the nodes into properties. For that, we need to put the results into an XML typed variable.

And with the above we get these results:

image

And from there you can use the results anyway you need to to help test and/or debug that part of your application. This recently just helped me out of a bit of a bind.

A Thought on Legacy Code

I’m quite sure that during one’s career as a software developer they may have the pleasure of maintaining legacy code. Of course, I personally define legacy code as a project that has absolutely no tests. Most of the time, though, this may be a fairly old project. If that developer has been in the career at least a couple of years, then one of the first things they may say to themselves about this type of project is how bad the code and/or the design is. I, myself, have also done this quite a few times.

However, something has occurred to me while I was updating, not one, but three of these types of projects. Indeed, there’s code in these that I still wonder who in their right mind would have written. At this point I had a sort of an epiphany: this wasn’t a bad thing, this is what helps to make me a better developer. The main reason I believe this is that, since I actually enjoy writing unit tests, I concentrate on making the code testable and write as many tests as I can. Only then will I proceed to make the requested enhancement or fix. The project is actually better for that and you just did something that someone else deemed or was just flat out told that they didn’t have time or the energy to do.

In conclusion to this small rant, don’t always hate on having to update legacy code. It can be to your best benefit as a developer and what you learn from that can last quite a while in your development career.

Debugger Display using ToString()

One of the things as a .NET developer that I tend to do most while debugging is to traverse through objects and their properties to see what values they have. Of course, the Base Class Library has something to help us do this even faster and more efficient – DebuggerDisplay attribute. Let’s say you’re tasked to help an insurance company write an updated application to determine the rate based off certain attributes on the car, such as age and number of collisions. It may look something like the following:

View fullsize

Showing regular object debugging.

And while debugging you want to see the properties, Visual Studio will show you something similar to the below.  Not bad, but we can do a bit better with the DebuggerDisplay attribute. Let’s see how this gets used. With the same class definition that we had earlier, we just add the DebuggerDisplay attribute to the class. To access any of the properties, just enclose them in “{ }”.

And our result is the below. Note that you can still expand out the object for other properties as well.

View fullsize

Debugging the object with DebuggerDisplay

Now, this alone can help out, but we can also run methods in the DebuggerDisplay attribute. Let’s override our ToString method of our class and use that. Note that the “nq” in the attribute is for “no quote” which will remove the quotes from the resulting string.

And, as you can see, we get the ToString() result in our debugger tool tip.

View fullsize

Debugging object using DebuggerDisplay with ToString()

Of course, there are other reasons why you would want to override the ToString method in your own classes, but hopefully now you know just one more way you can use it. Have fun debugging, everyone!

WinDBG Beginner Sessions: Part 1 - Hang

We got through the exhibition post, but now it’s time to get serious. I figured the quickest way to get going here is to go through Tess Ferrandez’s series of debugging labs. I’ve heard that these are actually some of the best tutorials and hands-on experience you can get with WinDBG, so I’m excited to get started.

Of course, one of the reasons I’ve waited so long to do this is due to the labs having the demo site setup in IIS. I’m definitely not the best at deploying and configuring IIS, so instead here I used IIS Express. This seems to work quite well so I’ll be sticking with that throughout the labs. So let’s get started with lab 1 – the hang.

The first part of the lab was to recreate the issue. Since TinyGet appears to be dead, I just manually hit refresh on the browser windows. While that was going I ran the following command to get a dump file while going to the page in question:

.\procdump.exe -n 2 iisexpress.exe

Unfortunately, I forgot to generate the dump using the -ma switch, so no memory information will be available. I swear to remember to use this from now on!

Based on the suggestion of the lab, running the ~* kb 2000 command. Ok, so after some searches, I'm still not exactly sure what this command is saying, but here's a shot in the dark:

• ~* will execute the following command towards all threads.
• kb will print out the native (non-.NET) call stack.
• 2000…well, here’s where I'm lost. If anyone out there happens to know, please let me know.

And the results of this is the below. Let's see, it appears that most of these threads are just in a waiting state.

Oh, but after some scrolling, thread 28 has something interesting.

Let's take a closer look at this thread and switch the debugger to it with the ~28s command. Then, we'll check out the managed call stack with the !ClrStack command.

See anything here? Talk about interesting, this thread is sleeping! Well, that's about all the commands I can think to run for this. Tess' lab suggests to run the !syncblk command, however, when I ran it I get the below.

Perhaps that's due to the fact that it isn't a full dump? Regardless, I think we have more than enough information from our dump here. Now, let's check the code that the !ClrStack command has given us. It's telling us to check out the DataLayer.GetFeaturedProducts() method, so let's take a look.

And look what we have.

Of course, looking back at the actual walkthrough of the lab, I missed a bit without the !synblk command. I’m definitely going to redo this with an actual full dump to see if I can find the thread that is being blocked and the thread that’s doing the blocking. I got a bit lucky on this one, I think.

WinDBG Beginner Sessions: Part 0

In an earlier post where I mentioned I took a very informative training course from Wintellect, I thought I’d use this blog to help keep track of what I’ve been studying and to kind of have a bit of a “peer review” of this stuff that I’m trying to learn. Although, before beginning, we still need to set up our environment. Personally, I prefer to have a dark background with a green text, a la the old terminal days. It just seems the easiest on my eyes and easiest to read. Below is a small list of the color changes I made to my base workstation. I leave the prompt command text white so I can differentiate when I set in a command vs. any output from WinDBG.

Setting Name	Color
Background	Black
Text	Green
Normal Level Command Window Text	Green
Normal Level Command Window Background	Black
Prompt Level Command Window Text	White
Prompt Level Command Window Background	Black

And here is a small sample screenshot of it in action:

On Better Developer Testing

I read an interesting post by Phil Haack a little while ago on having developers do better testing themselves instead of relying solely on their QA team to test. While it’s definitely a great read in itself, I felt I had to add my opinion to it.

Don’t get me wrong with this, though. I think the more experience and skill a developer has on testing their own code, the more valuable they actually are. Also, it’ll mean their code is that much more reliable and stable upon initial release all the way through to production. No developer wants to find that their code somehow broke in production the morning after it was deployed and spend that whole day fixing it.

While I definitely agree with Phil on most of his arguments, there was one thought about the whole thing that kept coming to mind about myself, personally, when testing stuff that I’ve written. I know I don’t have the experience to think of a good amount of scenarios the code will be hit at. Now, this may not be an issue for the more experienced developers out there, but I know it’s a weak point of mine. I’ve definitely been bit by not doing more of this in the past and, indeed, it wasn’t fun admitting it was my fault when the manager is asking what happened. In fact, when this happened to me it gave me a very real benefit of using unit tests. Of course, unit tests can’t test everything that a user would do as input or processes on a screen. While Phil notes that Test Driven Design is mainly for the initial design of the code we’re ultimately testing, it definitely helps to make sure any refactorings for readability, maintainability, performance, etc. didn’t break anything we’ve already shown and trust to be correct.