Sometimes in ASP.NET when you are trying to access a certain page you might get the following error:

External component has thrown an exception

In some other situations in .NET you might get this error as well (not directly related to ASP.NET, but sometimes to Interoping code or COM code), but this is beyond the scope of this post.

In the cases that I’ve stumbled upon, the reason is usually related to on-the-fly compilations ASP.NET performs when first accessing a certain page on an application.

The main problem with this exception that it is less than informative 🙂 . The only way of actually figuring out what is wrong (if this is indeed a case related to compilation error like I’m talking about) is to dig deep using WinDbg.

Luckily, every compilation that runs inside ASP.NET uses an API that upon encountering an error will create an object in the heap called CompilerError.

To debug this issue perform the following steps:

  1. Attach WinDbg to the ASP.NET worker process (w3wp.exe in Windows 2003, aspnet_wp.exe in Windows XP/2000)
  2. Make sure you have CLR exceptions enabled (see this previous post about how to enable CLR exceptions in WinDbg).
  3. Try to access the page that is not working, it should throw an exception and WinDbg should break in.
  4. Run the following command:

    !dumpheap -type CompilerError

    This should produce a list of all CompilerError objects which should allow us to inspect them and see the exact compilation error.

  5. Now dump each of the objects using the following command:

    !dumpobject 0xXXXX

    Where 0xXXXX is the address of the objects listed in the list you got from the !dumpheap command.

  6. At that point you should see the CompilerError object itself and you can dump its errorMessageText member (it’s address is near its name) using !dumpobject which should show you the exact compilation error.

In my case, the problem was that in the web.config file under the <compilation> / <assemblies> element there was no reference to one of the AJAX.NET assemblies (System.Web.Extensions) which caused the page to fail during on-the-fly compilation.

Do remember that this exception sometimes has nothing to do with compilation. If you don’t have any object of type CompilerError or there are a few but they make no sense in regards to the page you are accessing it might be something else.

It is often overlooked, but Response.Redirect has an overloaded method which has two parameters.

The first is like the overloaded version which gets only one parameter – the URL to redirect to.
The second is whether to end the request now or let it complete and only then redirect.

By default when calling the first version:


It will actually call the following code:

Response.Redirect(“”, true);

This means that the request will end right after the execution of the Response.Redirect function and no other code that is hooked to events that occur after the place in which you called Response.Redirect will execute.

For example, if you have a certain code at the Page_PreRender event and you are calling Response.Redirect in the Page_Load event (either on the page or in a control on the page), without using the overload version of Response.Redirect that gets two arguments and setting the second argument to “false”, the code in the Page_PreRender event will never get called.

While this seems very trivial, there are a lot of bugs that sometimes occur because people forget the Response.Redirect with one parameter stops the execution of the request.

Every time you call Response.Redirect, stop for a second and think if you really want to end the request at that point or let it continue to process until it finishes.

If you want it to continue processing the page and perform the redirection after the processing is done use the following code:

Response.Redirect(“”, false);

Thinking 2 seconds before writing a Reponse.Redirect code can save a lot of minutes debugging and figuring out that you never reach the other code because the request ended at the Response.Redirect call.

UPDATE: Fixed the last sample, thanks to Eber Irigoyen

Perhaps its just another case of RTFM but I might have a point here. Really.

I was using AJAX.NET and wanted to attach some silly handler to the “onmousedown” event of a link (“<a href”). I used the nice little $addHandler method in the following syntax:

$addHandler(myElement, “onmousedown”, myHandler);

And to my surprise it didn’t hook up anything.

I did what any developer would do, plunged back to the documentation and after a bit of a careful reading I saw the following line:

“The eventName parameter should not include the “on” prefix. For example, specify “click” instead of “onclick”.”

Now why should I care if I’m writing “onclick” or “click”. The convention used in browsers is “onclick”, after all that’s what you put on an element if you want to add an “onclick” handler in HTML.

Why would anyone want to break this convention. And even if you do decide to break it, adding a simple “if” or checking for the characters “on” at the start of the string and removing them would be nice.

Anyhow, I quickly changed the code to:

$addHandler(myElement, “mousedown”, myHandler);

and everything started to work wonderfully.

At least I’ve learned something new, that the eventName passed to the $addHandler function should not contain the “on” prefix. I also re-learned again that I should always RTFM, even the fine prints in the “Remarks” section.

When working with a complex environment such as the ones being created by most (if not all) AJAX applications nowadays, one needs a set of tools in his/her arsenal to overcome any obstacle.

FireBug, a web development and debugging extension for Firefox is one such tool that you must keep close.

As it site says:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

If you are not already using it go quickly, download and start working with it.

There are two major benefits of using FireBug when developing ASP.NET and AJAX.NET application:

  1. HTML Inspection – FireBug allows you during runtime and on any site, to inspect how the HTML looks. This includes direct references to the various stylesheets being used an element (including the casecading parts and from which .css file they came from). It also includes the ability to visualize the unvisible styling elements of padding and visualize so that you’ll visually see where the styling problem is as well as change the various style settings on the fly and immediately see the results.
  2. JavaScript Debugger – The JavaScript debugger and expression evaluator in FireBug are a lot easier to use and are a lot more powerful than the ones supplied by Internet Explorer combined with Visual Studio (or what is actually Active Scripting Debugging from the happy old COM days 🙂 ). Visual Studio is a very heavy debugger and sometimes lacks the ability to debug even sites and JavaScript that you just want to know how they work, without having the actual code of the site.

In the early days of AJAX.NET (or should I say in the “Atlas” days), FireBug was my main weapon of understanding the AJAX.NET framework and stepping line by line to understand how to use and work with AJAX.NET.

It’s an invaluable tool in your arsenal and with the usage of AJAX.NET increasing on a daily basis you just have to have it.

You know I don’t like to be an echo blog, but I couldn’t give up on such a fine piece of code.
This is really one of the things I said to myself “How didn’t I think of that before?” 🙂

Mike Stall has a great post and a piece of code that he wrote about using P/Invoke to access unmanaged Windows API code.

He has written a rather generic wrapper that does all the dirty LoadLibrary, GetProcAddress code and you can generically get a function and execute it without thinking twice.
It uses SafeHandles and make all the necessary releases (if you use it correctly) without you having to worry about it.

Check it out (don’t forget to read the disclaimer he wrote there) and have lots of P/Invoke fun.

I bet one of you (or maybe even me if I’ll find some time) can write a code generation utility that will use this code to create a wrapper for most of the unmanaged Windows API code that goes around making it even more type-safe in the sense if not having to pass around strings to get function names and having to deal with a generics deceleration of the function you are using.

In my previous post about problems with wrongful escaping of the query part in the uri in Request.QueryString, I’ve received a comment from a reader named DuncanS saying that he encountered a similar behavior with the Uri class.

It seems Uri.ToString() function will perform unnecessary unescaping of the different parts of the Url that were escaped (like the query part) to be unescaped.

His solution to the problem is to use Uri.AbosluteUri instead which does not exhibit this behavior.

Thanks for the tip Duncan!

I’ve got a request from a reader, JasonL, to post the function I’ve written to overcome the query string problem that I’ve talked about in the previous post.

You can take a look at my solution here.

My implementation is to take the query part of the current URL, split it and only then perform URL decode on the values (only) of each parameter.

I know that some of you will probably implement the function’s prototype a bit differently by passing the URL to it instead of the function extracting the URL directly from the current request, but to make things simpler that the route I’ve chosen.

The main “problem” with my implementation is that I use a SortedDictionary (the generic one) which will not return null when a key does not exists, instead, it will throw an exception (so be sure to use the ContainsKey function).

I probably did that mainly from a lazy point of view and I just love generics 🙂

Anyhow, enjoy.

Sometimes its the little bugs that really get to you. They are so small that you spend quite a lot of time figuring out what’s wrong and then it hits you.

In my case, the problem was simple. I had a parameter being passed to me on the URL.
The URL looked something like this:

param1 has a URL encoded value which translates into (without the double quotes):
text1, text2&text3

Yeap, it has a “&” character as the value, but its URL encoded so it suppose to be OK.

When I went to get the value of param1 by using:

var string a = Request.QueryString[“param1”];

The value I got was:

text1, text2

No text3 for some reason.

It seems that in certain cases there is a bug. I suspect that it URL decodes the query string before it cuts it up and fill in the Request.QueryString collection.
I didn’t fill like going through all the massive amounts of code of HttpRequest and friends using Reflector, so I just wrote a function that handles the URL decode and splitting issues correctly.

If you wish, I can post it as a link here.

Mike Taulty (which, by the way, has a great blog) wrote a short tutorial on how to figure out what the .NET Framework code does when you suddenly get an exception and you don’t really know why it is being thrown from the framework.

He also shows how to load our favorite WinDbg Extension – SOS – into Visual Studio and use it while debugging as well as use Reflector to disassemble the framework’s code into readable C# or VB.NET code.
I also briefly talked about loading SOS into Visual Studio a while back and mentioned the use of Reflector all over the place (because its such a great and useful utility!).

Mike, if you are reading this – Yes, I also do what you do and I suppose almost everyone who actually wants to know what is happening under the hood in the .NET framework 🙂

First of all, let me apologize for the lack of activity in the blog. I’ve been abroad for about a month and that’s why I was slow on responding to comments (which I did for most of them, so go back and check it out) as well as posting here.

OK… Now that the sorry execuse is behind us, let’s get back to business from now on…. 😉

A reader named Kipp left some comments on my “Ambiguous match found” post. He had some problems making WinDbg break on CLR exceptions (like the ones generated by the compiler during the ASP.NET compilation of the page that eventually causes the “Ambiguous match found” error).

Kipp also asked the question on Yedda (disclosure: Yedda is my day time job) and I answered him.

I think this is an important piece of information that should be shared with everyone, so here it goes – How to enable and disable CLR exceptions breaking in WinDbg.

First, a little background about Structured Exception Handling (SEH) in Windows and the CLR.

CLR Exceptions in SEH World
In the regular world of Structured Exception Handling (SEH) each exception has its own specific exception code. All CLR exceptions are seen in the regular Windows world as the same type of exception since they all have the same error code.

The additional information of the exception is stored in the managed world and that is why you need the SOS extension to print it our, read it and see it.

WinDbg has a built in ability to filter in or out various exception codes and sometimes, the CLR exception code is not enabled causing CLR exception not to break in WinDbg.

Enabling/Disabling CLR exceptions in WinDbg

  1. Open WinDbg and make sure you are breaked into a program that you attached or run (if you need to break when attached simply press Ctrl-Break).
  2. Go to the “Debug” menu and select “Event Filters…”.
  3. Select “CLR exception” and click on the “Enabled” radio button in the “Exception” area.

UPDATE: Dan McKinley was kind enough to remind me that there are shortcuts that you can type in the WinDbg prompt to do what I’ve written above. To enable CLR exceptions type “sxe clr” and to disable type “sxd clr“. To view the list of exception types and their current status type “sx“. Thanks Dan!

That’s all, you are now good to go and any .NET exception that will be thrown (even ones that are caught eventually in the code) will break in WinDbg.
To disable, simply selected “Disabled” instead of “Enabled”.

I hope it will help you all!