Sudden fatal issues with .NET Framework 4 - "Faulting module name: clr.dll" - FIXED

One of the applications I built and deployed some time ago had been ticking over nicely for months, when suddenly the users reported that they were no longer able to access the application.

When trying to access it, they were getting 'Page cannot be displayed' errors - which meant their request was not even getting as far as starting their session in the application.

After rooting around, trying various things in IIS to no avail, I finally identified a Microsoft Hotfix which did the trick. Having cleared out the application logs in Event Viewer, I could see that the .NET framework was throwing errors in clr.dll.

Information on the Hotfix (and details of the specific errors which showed in the Event Viewer) available from this link:
http://support.microsoft.com/kb/2640103

However, you can't actually download the hotfix directly from there - I think because Microsoft are trying to encourage you to carefully review your situation versus their described issue, and for you to be extra cautious about installing it.

I decided that this hotfix had to be the only option I could take, other than trying to get some tailored (and expensive) support from Microsoft by supplying them with a dump of the logs etc, and I eventually found that the hotfix can be directly requested using this URL (for some reason I had to access the site using Google Chrome since IE was throwing JavaScript errors):
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2640103

Within 5 minutes, the link to the hotfix had arrived in my email and I was able to download and install it.

It's worth noting that I stopped IIS (net stop w3svc) before applying the hotfix, which meant that I did not need to restart the remote server.

Now, the application seems to be back to normal. Well, let's see what the users tell me tomorrow.

Note: As usual, I have to declare myself free of blame if you install this hotfix and it doesn't work or causes any issues for you! :)

ASP.NET: Failed to access IIS metabase (IIS)

When installing everything on my new machine, came across a problem in IIS when publishing my projects there. I got the error:

Failed to access IIS metabase
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code

The error directs you to a Microsoft KB which isn't particularly helpful.

I had seen this error before when using SQL Server Reporting Services but the method I used last time works for SSRS, but not in this case. After a bit of Googling I found that this is a problem with the account permissions that ASP.NET runs under in IIS, as well as a method to solve it.

1. Gave permissions to the ASPNET account using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ga machinename\ASPNET".
2. Reset IIS (iisreset on command line) and that resolved the issue for ASP.NET 2.0.
3. We registered ASP.NET 1.1 with IIS as well using command "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis –i".
4. Reset IIS again.

That did the job for me. Some other people had to go to greater lengths such as uninstalling .NET and reinstalling it, but the above steps resolved the problem in my case.

After Upgrading to .NET Framework 3.5: ASP.NET Reconfiguration and Reporting Services 403 error

Due to the issues I had with the .NET Framework and SQL Server Integration Services, I had to roll back the version to 3.5 instead of 3.5 SP1.

When the upgrade from 3.0 to 3.5 was completed, I had to do a few things to get IIS working again (I was getting errors when attempting to browse to my ASP.NET web sites, and a 403 forbidden error when browsing to a Reporting Services page):

- Re-register ASP.NET (aspnet_regiis -i from the .NET Framework directory).
- Enable ASP.NET in the Web Service Extensions section of IIS Manager.
- Check that each application was set to use the correct version of ASP.NET
- Check that each application was still set to the correct Directory Security settings.

At this point, the ASP.NET web sites started working again but Reporting Services was still giving me a 403 forbidden error.

To get this resolved, I had to delete the ReportServer Virtual Directory in IIS, and then recreate it using the Reporting Services Configuration manager.

All working again!

IIS, ASP.NET: Could not load file or assembly 'System.Core, Version=3.5.0.0, Culture=neutral' or one of its dependencies'

If you receive this error when trying to access a newly deployed application on IIS:

"Could not load file or assembly 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified"

Then check that you have the .NET framework version 3.5 installed. This was the LAST thing I checked after about a million other things - I wish I had checked that first!

I'll know for the next time though!

IIS: "Page cannot be found" error when browsing aspx pages in Windows Server 2003 with IIS 6.0

I was configuring a new application, and had re-registered the .NET framework.

I kept getting a page cannot be found message when I tried to browse aspx pages on Windows Server 2003 with IIS version 6.0 and .NET framework 3.5.

Apparently it's because in Windows 2003, all the webservice extensions are "Prohibited" by default to ensure security. These settings were restored to default when I re-registered the .NET framework.

To resolve this, I did the following:

1. Opened IIS Manager (from a command shell, type inetmgr and press enter).
2. Expanded the appropriate nodes in the IIS to locate the "Webservice Extensions" Node
3. There was a list of "prohibited" extensions in the right.
4. Clicked on ASP.NET and "allow" it

Worked! Well, I was now back to where I was before I started mucking about with .NET.

This article applies to Windows Server 2003, IIS 6.0 environment.

ASP.NET: "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level"

You may get this error when trying to browse an asp.net application.

The debug information shows that "This error can be caused by a virtual directory not being configured as an application in IIS."

When you create an new web application using visual studio.net, it automatically creates the virtual directory and configures it as an application. However, if you manually create the virtual directory and it is not configured as an application, then you will not be able to browse the application and may get the above error. The debug information you get as mentioned above, is applicable to this scenario.

To resolve it, Right Click on the virtual directory - select properties and then click on "Create" next to the "Application" Label and the textbox. It will automatically create the "application" using the virtual directory's name. Now the application can be accessed.

This solution 'borrowed' from this blog.

IIS 5.1: "MMC has detected an error in a snap-in"

When using IIS Manager on a Windows Server Enterprise Edition box, the error message "MMC has detected an error in a snap-in. It is recommended that you shut down and restart MMC." sometimes appears.

Googled around for a bit, and this seems like a bug that Microsoft know about, but don't care about. Odd! Suppose that's nothing new though:

http://support.microsoft.com/kb/915519

Solution: IIS - You Are Not Authorised To View This Page

If you're setting up a new site on IIS, and occasionally (usually after you lock your workstation and log back in, or if you leave it for a long period of time) when you attempt to view a site on your localhost or on another remote machine using IIS - you might see the page displayed which says:

"You are not authorized to view this page (Error 401.1)"

If you're allowing anonymous access to your site using the IIS account, a temporary workaround is to run an iisreset at the command line. But a longer term (and less irritating) solution is to go into the Directory Security properties of your Virtual Directory in IIS configuration and uncheck the box which says "Allow IIS to control password".

Then do an iisreset and the error shouldn't appear again, unless there are deeper problems with your security set up.