Debugging .NET applications

Recently I attended C2C conference in Warsaw. I signed up for the .NET track. The session I was really looking forward to was “Hardcore Production Debugging” by Ingo Rammer. I hoped to learn something that I could use right away in my every day work. Remote debugging may be very painful and it is not easy to find the best approach. I was keen to learn about new easy-to-use tools that would make my life much easier. Unfortunately, the word “Hardcore” in session’s title was there for a reason…

The biggest part of the session was dedicated to WinDBG tool. Its interface is very poor and user-unfriendly. However, Ingo demonstrated that once you learn how to use it, it can be very helpful in finding the reason for application failures.

At first Ingo simulated situation where the developer has access to production machine (with no Visual Studio installed) where they can run WinDBG. Once he started this tool he attached it to the process of sample application that was throwing unhandled exceptions. With a few commands he was able to find out the exception message and the reason for failure. With the same tool Ingo was able to find out the reason for unexpected application exit by attaching breakpoint at the end of app’s process.

Ingo showed us also that remote debugging can be achieved with the WinDBG installed on developers machine and its console version – CDB – on client’s machine. After you configure the port for CDB you can access it from outside using WinDBG (option “Connect to remote session”).

Next, Ingo explained what to do when WinDBG and CDB are also not available on the production machine. He proved that we can find the same error as in the first part by studying the memory dump created for that application. To get the memory dump we can ask the client to create it manually using a simple program (Adplus) or OS built-in functionality (only on Vista) immediately after the error occurs. Then, all we need to do is load the dump into WinDBG (option “Open crush dump”) on the developer’s machine and examine it using the same commands as in the first case.

Finally, Ingo presented simple program GFlags for Windows registry keys modifications that would allow launching CMD/WinDBG immediately after specified process is started and attaching the debugger to this process. This can be handy when an error does not occur regularly and it’s not easy to reproduce. He warned us that you have to be very careful when using that tool and change system’s default settings only if you’re absolutely sure what you’re doing. Registry modifications can cause a lot of damage to your OS if the are not done correctly.

To sum up - the pase of presentation was high so it was not possible to learn all the commands that Ingo was using. The goal of this session was to show to the audience what is possible if we use the presented tools and that it doesn't require much work once you learn how to use them.

The session itself came out to be the highlight of the conference. Mixture of Ingo’s knowledge and charm proved to be the formula for perfect presentation. I just wish Ingo had some more time so we could study the examples more carefully.

Some WinDBG commands used by Ingo:

.hh         Debugger Help
sxe clr     Break on all CLR Exceptions
sxi clr     Ignore CLR Exceptions
sxn clr     Notify on CLR Exception
 
.loadby sos mscorwks   
            Loads SOS Debugging Extension; 
            Enables use of following options:

  !help            
  !printexception (!pe)
  !clrstack
  
  ~            list threads
  !threads     list managed code threads

Some Useful links:
All presented debugg tools for Windows
Ingo's page at Thinktecture
Tess Fernandez blog “If broken it is, fix it you should”

Ingo also recommended book "Debugging .NET" by John Robins.

Syntax highlighter toolbar covers first code line

As mentioned in my previous post I'm using Syntax Highlighter now to display code snippets. Appart slow loading it's working fine and it's doing its job. The only thing that was annoying to me was that the highlighter's toolbar was covering part of the first code line if it was too long:


Solution:
Solution is quite simple: I decided to lift it up a bit by overwritting toolbar's style:

Place this style definition anywhere in <head> and the result should be similar to that:

To be honest, I would like the toolbar to be displayed below the code snippet, aligned to the bottom border but this would require bit more styling. Let me know if you achieve that!

Code snippets on blogger

I decided to adjust the way I display code snippets on my blog. The old way of displaying wasn't very good and required some additional formatting. I've found a perfect solution for that: Syntax Highlighter. This allows you to easily display code snippets in a nice and accessible way. The code is colorised according to its type: e.g.

Xml:

  sample

Java:

class HelloWorld
{  
   public static void main(String args[])
   {
      System.out.println("Hello World!");
   }
}

The usage is really simple. In addition all required CSS an JavaScript files are available online so you can refer them from your blogger page! Can't wait to submit some more code ;)

Quick Note: When using this on blogger you'll need to turn the bloggerMode on. You can do it in JS:

SyntaxHighlighter.config.bloggerMode = true;

.

PHP: Redirection fails after moving to new server

Recently one of my old php apps was moved to different server.
After the move it came out that some pages didn't work as expected i.e. some redirections were failing. The redirections were implemented using header function e.g.

header('Location: http://www.targetpage.com/');

When I checked the php logs I found common error "Headers already sent". Don't want to explain here what does it mean - there's plenty of answers here ;) The only thing that made me wonder was why it was working on the old server. When I compared the php.ini files from both servers I found out that the new one was configured not to useoutput buffering. The temporary fix was enabling this by setting in php.ini:

output_buffer=On

This is not the cleanest solution and may affect application's performance but works immediately. The long-term solution is to ensure that your app is not sending any output before calling the header method.