IIS 7 & IIS 8
Application pool crash on startup - possibly bug in .net Framework's ...
Last post Apr 15, 2011 09:44 AM by eddieyanez
Jan 31, 2011 10:25 AM|LINK
Just been looking at a weird problem where a .net 4 application pool was crashing on startup in the static constructor of the Framework class System.Web.MimeMapping.
Looking at the reflected code in that class, it's adding a bunch of MIME types to a hashtable:
_extensionToMimeMappingTable = new Hashtable(190, StringComparer.CurrentCultureIgnoreCase);
It turns out the issue was that the machine's culture is set to cy-gb, and in the (incorrect) implemementation of this culture, G and F are considered to be equal. So when it comes to adding in the .GIF type, it complains that the item already exists -
because .FIF is already in the hashtable. This is some code which may help clarify the comparisons:
So, my issue with this is (apart from the bug in the LIP which says f==g is true!) that I'm pretty sure that this MimeMapping constructor should be using an _InvariantCulture_ string comparer when adding these types into the HashTable. I
can't think for a minute why the mime types would be loaded in from a hard-coded list and compared using a culture at all, and who knows what else it could be (mis)interpreting due to this.
Is this a bug, or have I missed something fundamental here, and the MIME types really should take the local culture into account when populating the hashtable?! The situation as it is means that nobody using this culture can use my app :-(
Feb 01, 2011 11:37 AM|LINK
Get a crash dump, and use Visual Studio 2010 to debug it. You should be able to see how easy it is on .NET 4/Visual Studio.
Feb 01, 2011 12:58 PM|LINK
I've already debugged it - hopefully the details were in the post above :-)
The bug is in the static constructor of of the .net Framework MimeMapping class - it never got to any of my code. It's using a culture-specific string comparer when adding a load of hard-coded items to a hashtable which contains the mime types. If that string
comparer finds that any of the keys to the hash are identical for that culture (in this case .GIF and .FIF), the application pool crashes on startup because of duplicate keys being added to the collection.
The point I was trying to ask/make was whether I'm right in thinking that this class should be using an Invariant Culture string comparer here! Hope this makes sense :-)
Feb 02, 2011 02:01 AM|LINK
Well, if you detect a possible bug, you may report to Microsoft Connect, which is the official place that Microsoft collects feedback,
Not here :)
Apr 15, 2011 08:52 AM|LINK
Apr 15, 2011 09:06 AM|LINK
The only solution was to change the culture of the machine :-(
Bug has been sumbitted at:
Apr 15, 2011 09:44 AM|LINK