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! :)
Tuesday, 12 November 2013
Sudden fatal issues with .NET Framework 4 - "Faulting module name: clr.dll" - FIXED
Posted by Phil Reid 0 comments
Labels: .net framework, asp.net, hotfix KB 2640103, iis, tech problems
Wednesday, 27 January 2010
ASP.NET Error: System.Web.HttpException: Maximum request length exceeded
On several applications I have developed, the users need to be able to upload binary documents (discussed in other posts).
After a while, I kept getting the error:
System.Web.HttpException: Maximum request length exceeded
Easy fix. The problem is that by default, the maximum request size is 4mb. So when a user tries to upload a file which is larger than that, an exception occurs. The resolution is to increase the maximum size of the request, so add the attribute below to web.config (you can use a maxRequestLength up to "2097151" (2 GB) for the .NET Framework 2.0):
<configuration>
<system.web>
<httpruntime maxrequestlength="10240">
This is also explained quite nicely but without much background in a Knowledge Base article on the Microsoft Support site.
Remember, if you are imposing a maximum file size for upload you should notify the user of this restriction and handle any attempt to upload a larger file, or they might see errors again.
Posted by Phil Reid 0 comments
Labels: .net framework, asp.net, error handling, tech problems, web design, web.config
Friday, 20 November 2009
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!
Posted by Phil Reid 0 comments
Labels: .net framework, 403 forbidden, iis, sql server reporting services
Existing SSIS Packages Generating New Errors (.NET Framework)
I had been using an SSIS package to load in data from a remote database using the Sybase Adaptive Server Enterprise driver on my own machine and on two 64 bit servers.
The load was working fine, but then it stopped working suddenly complaining of error code 0x80131937:
* Error 0xc0209029: Data Flow Task: The "component "Source - Query" (1)" failed because error code 0x80131937 occurred, and the error row disposition on "output column "WhseCode" (12)" specifies failure on error. An error occurred on the specified object of the specified component.
(SQL Server Import and Export Wizard)
But the weird thing was that the exact same DTSX package stopped working on my PC and on only one of the two servers - it kept working on one of them.
So I tried everything:
- Stopping the package from failing on error to see what rows would be loaded into the database - every row loaded but every column was set to NULL.
- Rolled Sybase driver back to ASE ODBC 12.5 - this actually worked, but I could not roll the drivers back on the server machines so I had to find another answer.
- I tried several different query formats, but it failed every time.
Then, I stumbled across this thread and the good advice on the .NET framework versions proved to be the answer.
On my local workstation machine and the server which stopped working, I had .NET 3.5 SP1 installed. But on the server which was still working, the .NET framework was 3.5 without SP1.
Basically, I removed all versions of the .NET Framework, reapplied .NET 2.0, 2.0 SP1, 3.0 and 3.5 in order and tested the package between each installation.
Now it's working and the data is loading in just as it should.
I can't believe that .NET 3.5 SP1 would just break ADO like this. I don't have a problem with compatibility issues between versions of .NET, but some explanation or notification would be useful.
Oh well, the things you learn.
Posted by Phil Reid 1 comments
Labels: .net framework, sql server, sql server integration services, ssis, tech problems
Friday, 23 October 2009
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.
Posted by Phil Reid 0 comments
Labels: .net framework, iis, tech problems