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:
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 :-(
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 :-)
Hi there. Based on the info you provided I changed the code on our application to force en-GB instead of cy-GB when fetching the culture info for GB. Also had a look on Connect, found out a few people have reported the same thing, and will keep an eye on it
to see when it's fixed so that I can remove the workaround from code. Thanks for posting this online, it really helped understand what was happening!
dafad_dew
3 Posts
Application pool crash on startup - possibly bug in .net Framework's System.Web.MimeMapping class...
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:
static MimeMapping()
{
_extensionToMimeMappingTable = new Hashtable(190, StringComparer.CurrentCultureIgnoreCase);
AddMimeMapping(".323", "text/h323");
AddMimeMapping(".asx", "video/x-ms-asf");
etc...
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:
StringComparer.CurrentCultureIgnoreCase.Equals(".g", ".f")true
StringComparer.CurrentCultureIgnoreCase.Equals(".gif", ".fif")
true
StringComparer.CurrentCultureIgnoreCase.Equals(".gif", ".fig")
true
StringComparer.CurrentCultureIgnoreCase.Equals(".g", ".h")
false
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 :-(
Dafad.
lextm
4484 Posts
Re: System.Web.MimeMapping - application crash on startup bug.
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.
Regards,
http://lextm.com
---------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
dafad_dew
3 Posts
Re: System.Web.MimeMapping - application crash on startup bug.
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 :-)
Dafad
lextm
4484 Posts
Re: System.Web.MimeMapping - application crash on startup bug.
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,
http://connect.microsoft.com/VisualStudio
Not here :)
http://lextm.com
---------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
eddieyanez
2 Posts
Re: Application pool crash on startup - possibly bug in .net Framework's System.Web.MimeMapping c...
Apr 15, 2011 08:52 AM|LINK
MimeMapping
dafad_dew
3 Posts
Re: Application pool crash on startup - possibly bug in .net Framework's System.Web.MimeMapping c...
Apr 15, 2011 09:06 AM|LINK
The only solution was to change the culture of the machine :-(
Bug has been sumbitted at:
https://connect.microsoft.com/VisualStudio/feedback/details/661862/system-web-mimemapping-static-constructor-crash-due-to-incorrect-string-comparer-use
eddieyanez
2 Posts
Re: Application pool crash on startup - possibly bug in .net Framework's System.Web.MimeMapping c...
Apr 15, 2011 09:44 AM|LINK