A friend of mine, Dudu Shmaya, with help from Eyal Post wrote a cool tool called Terminals.

Terminals
is a multi-tab terminal/remote desktop utility that enables you to manage multiple remote servers from the same window (without opening multiple Remote Desktop Connection windows).

While it is not a debugging utility, it is a useful tool when trying to debug on multiple remote servers.

I find it a lot better than using multiple RDC (Remote Desktop Connection) windows and a lot better than the multi terminal/remote desktop utility called (Remote Desktops) which comes with Windows 2003.

The project is hosted at CodePlex and its source code is also available.
For updates and more information about Terminals read here and 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!

UPDATE: After I moved to the Beta version of Blogger it seems that when viewing this post directly through its permalink, the widgets does not appear and Blogger didn’t take my site changes per specific post (for some reason) as it did before.
So, you’ll probably going to have to go to main page to see it. Sorry. I’ll look into this issue with Blogger.

UPDATE: I’m on my own WordPress running on my own server now, so it shouldn’t be an issue anymore 🙂
This is going to be an administration post about some of the layout changes I have made to this blog. I’m not going to lie to you, there is a bit of shameless promotion in this, so if you don’t want to continue reading, come back to the next post of this blog (which will be technical. I promise 🙂 ).
You probably noticed the changes on the right side bar of this blog these. Two little yellowish-orangeish boxes appeared. These boxes are Widgets of my day job (Yedda, if you haven’t figured that out yet 😉 ).

These widgets allows you to interact with Yedda.com, a web site that connects people with questions with people with answers, so that the next time you have a debugging, .NET or something of this sort question, just ask it on the Ask widget (the first one) and other people on Yedda (including me) that have knowledge in debugging will automagically be invited to answer your question.

The second box shows frequently asked questions about topics covered in this blog (debugging, asp.net, c#, etc). Go in, see if you can answer some of the people, or just read and learn from the experience of others.

If you have a blog or Web site, feel free to go to the widgets page on Yedda, configure and place your own widget in your blog or Web site. If people will ask questions through your blog or Web site, the question will contain a link back to your blog or Web site.

All in all, this post is also good for you, you’ll be able to have a place where you can ask your questions and people (me included) will answer you :-).

OK, back to the normal schedule. Next post will be technical. I promise!

While I don’t normally repost links and try to avoid it as much as possible, I’ve stumbled upon this post by Jeff Atwood (he works on CPU-based parallelism in the .NET CLR team sorry I mixed things up a bit. Jeff Atwood doesn’t work on the CLR team and not for Microsoft. David, thanks for pointing that out to me. I guess I just mixed things up a bit, since I also wanted to place a link to Joe Duffy’s post about thread priorities) about Thread Priorities.

Read it carefully and think twice before writing:

thread.Priority = ThreadPriority.BelowNormal

While the sample Jeff gives is for CPU starvation and the problem he is illustrating will likely be caused on machines with a single CPU, it IS important to understand that thread priorities WILL affect your application, sometimes in the worst possible way.

While I’m at it (“it” being doing a links post 🙂 ), Maoni (which got a GREAT blog about .NET and its internals) has a philosophical post about performance work. This post really highlights the fact that general fundemental knowledge is always useful when trying to understand a problem.

If pre-optimization is the root of all evil, fixing things that are not there or are not the problem is the fertizlier that makes the root of all evil grow and grow and grow, consuming your code!

While I know its been quite here due to my “other job” (which I highly recommend you check 😉 ), I have a few things down the pipe that will, hopefully, be of use to all of you.

A couple of days ago a friend asked me a question about a problem he had with Windows Authentication and I thought I’d share some of the information about it.

They have an ASP.NET web application that have Windows authentication enabled. That application is accessing another server using an API. So far so good.

When they logged into the web application using Windows authentication, the credentials were automatically transfered and validated through IIS and the thread executing the current request was automatically impersonating using the credentials that were passed from the browser, but the call to the API within the application that accesses the other server failed.

This happens due to the fact that NTLM, the protocol that is used be default in Windows Authentication (and even used by default when installing a new domain server) does not support, due to various reasons, credentials delegation.

This means, that only the hop from the browser to the web server is supported and the credentials are not being transfered again from the web server to the other server through the API.

This will happen in every ASP.NET web application or web service that uses Windows authentication.

There is a nice post in this blog, that describes the problem as well as the possible solutions which includes (in a very short list):

  • Basic Authentication – An IIS feature that uses clear text over the wire to authenticate, which is not secure so consider using HTTPS to perform that.
  • Kerberos – a security protocol that is supported in Active Directory (Windows domains start are based on Windows 2000 and above). Kerberos is a bit annoying to configure, so it might not be the best possible solution (and sometimes your IT guys won’t even support it anyway).
  • Specify explicit credentials – This means that the second hop to the other server from the web server will always use the same predetermined fixed credentials. Sometimes you simply cannot do that, but that solely depends on your implementation.

The blog post also contains some links to knowledge base articles that can help you configure Kerberos as well as how to use explicit credentials.

There is a new WinDbg version (6.6.7.5) available here (it was released yesterday – July 18th).
You can check out some of the new stuff here.

Be careful though, the previous version had more than a few bugs and problems. Hopefully, this version fixed some (if not all) of them.

I still haven’t had much time to check it more thoroughly, but you are more then welcome to try it out, just don’t forget to report back! 🙂

Update: I’ve checked whether there is a new verison of SOS for .NET Framework and there isn’t any. There is only a new SOS version for .NET Framework 1.1 (which was compiled about 11 days ago).
Anyhow, this is kind of annoying. I’m really looking forward to get a new version of the .NET 2.0 SOS with at least all the features that were in the 1.1 version and are missing in the 2.0 version.

On my previous post about the dubious “Ambiguous match found” exception, I talked about the fact that the ASP.NET runtime is case sensitive and if you are writing in C# you better be careful about how you name your private, protected and public variables.

Not so long ago, I’ve encountered another problem which is relatively similar. It manifests itself in the runtime but it is actually related to the ASP.NET compiler.

When first accessing an ASPX page in an application after the server was started, the ASP.NET runtime will try to compile that page. One of the first steps in doing so is to parse the ASPX page and figure out what controls were placed on it. It will then create these controls and the Page object behind the page and render the page outputting the result back to the client.

When the ASP.NET runtime tries to create the various controls placed on the ASPX page, it will use the GetType function, but for some reason, it will only pass the name of the control and not its full namespace.

In my case, we had a custom user control named HtmlAnchor which was suppose to overcome a few quirks with HTML anchors in some browsers. ASP.NET already contains a control named HtmlAnchor which its full namespace is System.Web.UI.HtmlControls.HtmlAnchor.
Our control, had no namespace, since we simply created a user control in our application.

Even though we didn’t use even a single System.Web.UI.HtmlControls.HtmlAnchor, but only our custom HtmlAnchor control we got a strange error about not being able to load a certain .NET assembly which was suppose to be generated when the page first renders to produce the page’s code cache.

I fired up WinDbg and when the exception occurs, search for objects of type CompilerError by issuing:

!dumpheap -type CompilerError

This will list all CompilerError objects in the heap. After that I issued:

!do 0xXXXXXX
Where 0xXXXX is the address of the CompilerError object that I’m inspecting (!do = !dumpobject)

And inside there is a private member that contains the error text which I also dumped (using !do).

The error that I saw was that .NET cannot cast HtmlAnchor (my HtmlAnchor) to System.Web.UI.HtmlControls.HtmlAnchor.

I issued “!clrstack -p” to see the call stack and the parameters that were passed to each function and along the way there was call to GetType with the name parameter that was equal to “HtmlAnchor”.

This was the problem. For some reason .NET figured out that my HtmlAnchor is suppose to be the HtmlAnchor the resides in System.UI.HtmlControls.

As it turns out, the namespace System.UI.HtmlControls is ALWAYS included when the ASP.NET compiler compiles an ASPX page and, for some reason, request the type of the object WITHOUT its full namespace and find the wrong HtmlAnchor even though I have a different TagPrefix for my HtmlAnchor in the ASPX page.

The is a combination of a number of problems.
First, when adding a user control to an ASP.NET web application, there is no specific namespace in the file. It will eventually get the namespace of ASP.XXXX when compiled using the ASP.NET compiler like the rest of the ASCX and ASPX pages.

I haven’t checked it for user controls that are not ASCX, meaning, someone wrote a control in some DLL and does get a namespace. The difference is that when including that control on an ASPX page we do provide the exact namespace and assembly, so it might works without a problem.

Second, if the user control has the same name as any of the control that are in the System.Web.UI.HtmlControls and System.Web.UI.WebControls namespaces, they will, for some reason, get loaded in GetType instead of your controls.

Third, in the @Register tag at the top of the page, where we declare and include our user control (we include the ASCX file), there is no additional information such as namespace to help the ASP.NET compiler resolve this issue.

Conclusion:

Be careful when you name your User Controls (ASCX controls) and make sure they do not have the same name as other controls in System.Web.UI.*.

Sometimes when you have a big DataSet with elaborated relationships you might get the following error when trying to add or load data into the dataset:
Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints

Some of the causes for this error are usually “regular” violations of the foreign-key constraints, which means you are referencing a certain key that does not exist in the parent table. If that is the case, you can check this article on MSDN that explains a bit on how to resolve these issues.

If you are still having problems with your dataset and ADO.NET code, you might just want to try this little trick.
It appears that inside a DataRow there is a property called RowError.

RowError is a string value that can be set or read in numerous other occasions, but the situation in which I encountered was due to a bad relationship that was added on a table which caused the code to throw an exception at runtime. In that case the RowError property hold the exact name of the troublesome relationship.

So, how do you access it?
When you code at runtime throws an exception and you are with a debugger attached, check the following thing using the “immediate window” or Quickwatch:

myDataSet.Tables[“YourTableName”].Rows[0].RowError

Don’t forget to replace “myDataSet” with the variable name of your dataset and “YourTableName” with the table that is (probably) causing the problems.

In the case I’ve described above, this property told me exactly what is the problematic foreign-key that I had and from there I figured out what is the problematic relationship.

A friend of mine asked me a question which reminded me a very important issue regarding STA (Single Threaded Apartment) COM objects in ASP.NET Web applications. STA COM objects were created so that most people won’t have to deal with threading issues. The COM framework itself will make sure that each call to any method in an STA COM object will be blocked so that other requests from other threads won’t be able to get into that certain method until a previous call exited it (they will be queued).

My friend tried to create an STA COM object within the web application. The COM object was suppose to access a network share on some other machine in the network.

The ASP.NET process was configured to use the default IUSR_XXX (where XXX is your machine name) user, which has little access to anything.

In order to access the network share we had to change the context of the calling thread, so my friend used the <identity> tag in the web.config to make sure each request to the page running this code will impersonate to the user specified in the <identity> tag.

The problem starts with the threading model of ASP.NET. ASP.NET threads which executes the various request it receives are MTA (Multi Threaded Apartment). When an STA COM object is created on an MTA thread, to actually being able to perform the synchronization that STA COM objects give, we will have to context switch to the default STA thread of the process (which is a dedicated thread for that purpose) and the COM object will be created there.

Here our problem starts. The <identity> tag makes sure that the thread executing the request (the MTA thread) will impersonate its security context to the user specified in the <identity> tag but our STA COM object eventually was created on the default STA thread which was not impersonate, causing it to get the security context of the process (which was IUSR_XXX – the least powerful user of all). This meant that when the STA COM object tried to access the network share it failed since it didn’t get the right credentials.

So, how can we solve this issue? There are a number of ways.

The easiest way of all is to change the user running the ASP.NET application. To do that in Windows XP or Windows 2000 you need to go to the machine.config file and change the username and password in the processModel section. It is not recommended to put your password in clear text in the machine.config. That is why Microsoft released this utility which will encrypt your username and password in the registry.

In Windows 2003, you’ll need to create a new Application Pool and make sure the identity of that pool is the needed user that can do all the necessary things, security wise, that your application needs to do.

Another option, is to use the identity flag as specified in MSDN but to add the ASPCompat attribute to the your page class (or enable it in the ASPX page as described here). This will make sure that each of your requests to that page will actually run in an STA thread instead of an MTA thread, so when creating an STA object from within this page, the object will be created on the calling thread (since we are already in an STA thread) which will have the correct identity (we are using the <identity> configuration in the web.config).

And the last option, which works in .NET Framework 1.1 SP1 and above and in .NET Framework 2.0 (though I haven’t tested it in .NET 2.0), is to add a special flag called “apartmentThreading” which essentially changes all of your page to work the same way as adding the ASPCompat attribute.

In any case, in order not to hurt performance and scalability too much, use as little STA COM objects as you can and specifically mark the pages calling these STA objects using the ASPCompat attribute. When you have to use an STA COM object, create it, use it and released it as soon as you can, preferably using Marshal.ReleaseCOMObject (which will force it to die as soon as you call this method instead of waiting for the next garbage collection. To get more information about what Marshal.ReleaseCOMObject does see my previous post).