IIS

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

Tim Huffam — Tue, 05 Sep 2006 00:07:00 GMT

The following error occured because a web.config file existed, in a directory beneath my main app root dir, should not have been there:

It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS. C:\Dev\SVN\authenticationservice\authenticationservice\aspnet_webadmin\2_0_50110\web.config

It is actually valid to have a web.config in a dir beneath your app root dir, but you need to make sure allowDefinition is configured correctly. In my case, however, this file should not have been there - so to fix the problem I just deleted it.

HTH
Tim

Remote debugging with ASP.NET 2.0 - finding the process id (PID) of the worker process.

Tim Huffam — Mon, 07 Aug 2006 22:56:00 GMT

To start remote debugging an ASP.NET 2.0 app (assuming the app is up and running on the remote server):

On the remote server start the Visual Studio 2005 Remote Debugger. For this you need to have the VS2005 Tools installed (not necessarily the full VS2005).
On your local machine, within VS2005 select Debug - Attach to Process...
In the Qualifier field (in the Attach to Process screen) enter the name of the remote server and press ENTER.
Select the IIS worker process (w3wp.exe) that is running your web app* and click Attach.

* This is the tricky part - as there is nothing on this screen that helps us identify which of the w3wp.exe process is the one we want. To determine this:

Log on the the remote server and start a command prompt session.
Run the following script: c:\windows\system32\iisapp.vbs. This script will list all the currently running w3wp.exe processes, listing their PID and application pool id.
The application pool id is the only relation between the pid and your app.
Use the apprioriate PID to identify the correct w3wp.exe on the Attach to Process screen.

HTH

Tim

Manually configure a web app dir for a specific version of the .NET framework

Tim Huffam — Fri, 04 Aug 2006 00:24:00 GMT

In some cases you may want or need to change the version of .NET that a particular web application directory uses. Normally this is done via the ASP.NET tab on the IIS properties page for the web app, however it can also be done manually at the command line...

CD into the dir containing the version of .NET that you require eg: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
Run aspnet_regiis.exe specifying the name of the dir you want this set against.
eg aspnet_regiis.exe -s W3SVC/nnn/ROOT/xxx (where nnn is the web site identifier and xxx is the dir name)
eg aspnet_regiis.exe -s W3SVC/1/ROOT/MySampleApp

It's that simple.

Error using client certs: The page requires a valid client certificate (403.13). How to turn off CRL checks in IIS.

Tim Huffam — Sun, 11 Jun 2006 21:57:00 GMT

The following error may occur when trying to use a client cert for the first time (this error is from IIS 5):

The page requires a valid client certificate

The page you are trying to view requires the use of a valid client certificate. Your client certificate was revoked, or the revocation status could not be determined. The certificate is used for authenticating you as a valid user of the resource.

HTTP 403.13 - Forbidden: Client certificate revoked

The cause of this is usually "the revocation status could not be determined.". This is because CRL (certificate revocation list) checking has not been setup on the server.

The simple solution for this (for development), is to just disable CRL checking.

You can do this using an IIS metabase tool (eg IIS Metabase Explorer) or adsutil, or, if you dont have these tools installed, you can run some VBScript to disable it - and this is how:

Create a VBScript file with the following code:

Set oWeb = GetObject("IIS://localhost/W3SVC")
oWeb.CertCheckMode = 1
oWeb.SetInfo
Set oWeb = Nothing
Save it to a .vbs file eg c:\turnoffcrlcheck.vbs
Execute the script at the command prompt eg:

cscript.exe turnoffcrlcheck.vbs

And that's it. You should not need to restart IIS.

HTH

Tim

Error (m_safeCertContext is an invalid handle.) when accessing a client certificate using .NET 2.0/VS2005

Tim Huffam — Tue, 18 Apr 2006 01:58:00 GMT

This error (m_safeCertContext is an invalid handle.) occurs when you try to access a client cert (or a member of the cert) from a ASP.NET 2.0 application developed using VS2005 eg:

X509Certificate cert = new X509Certificate(Request.ClientCertificate.Certificate);
string certSerial = cert.GetSerialNumberString();

The error is thrown because no valid certificate is found. This can be caused by either:

A problem with the cert. A common reason for this in a development environment is one of the cert properties differing from that of the environment eg cert common name does not match the site name. I guess this would also occur if the cert had expired.
The cert did not get passed to the request.

If the cert has not been passed to the request. Then it's probably because you've not setup the website to be able to accept certs. To do this you need to do the following:

Host the project from IIS - not the thin web server that is bundled with VS2005.

From within VS2005 select File - New Web Site.
Select the Location of HTTP then enter the path eg: http://localhost/MyWebSite. Note that you don't have to use HTTPS just yet (I find it easier for development to use HTTP then when deploying to UAT or Production to use HTTPS).

Code up a test form.
Go into IIS Admin - right click on the new app (MyWebSite) and select Properties.
On the Directory Security tab, click Edit... under 'Secure communications'.
Make sure 'Accept client certificates' is checked.
When you run your app - make sure you use HTTPS in the url eg: https://localhost/MyWebSite

Here's another article about this.

HTH

Tim

Error: The underlying connection was closed: The remote name could not be resolved. When doing HttpRequest from ASP.NET.

Tim Huffam — Wed, 08 Feb 2006 20:20:00 GMT

The following error occured when trying to open a web page (ASP.NET) that was doing an HttpRequest.

"The underlying connection was closed: The remote name could not be resolved."

This is usually caused because the ASP.NET app is on a network that is using a proxy server - and as ASP.NET does not run as a user account, it does not have access to the proxy settings in the registry.

To resolve add the following section to your web.config file.

Note that this must be placed within a <system.net> section (not system.web!).

MS have a kb article on it here.

HTH

Tim

IE bug: HTTP POST with zero content-length (content-length = 0) (even though there is data in the post request)

Tim Huffam — Thu, 26 Jan 2006 01:35:00 GMT

This little gem comes to us courtesy of MS's IE, whereby it resets the connection and sets content-length to 0 (zero), even though there is data in the post request, when the keep-alive timeout expires.

Fortunately this only occurs when using HTTPS, and apparently it's limited to a particular version of IE (although I'm not 100% convinced about this).

This bug is documented very well here and by ibm here, and an typically difficult to understand MS solution here.

Another solution I think may work (if you're using ASP.NET), is to flush the response manually (Response.Flush())- my understanding is that this will disable the keep-alive header that ASP.NET sends out. Basically should allow you to still have the keep-alive setting switched on on your IIS server and by manually inserting the Flush() method you can restrict where this occurs to individual pages or apps (eg Global.asax). Although I've not tried this and could be completely wrong ;-)

HTH

Tim

IIS error: The parameter is incorrect

Tim Huffam — Fri, 18 Nov 2005 00:20:00 GMT

This error occurs within IIS 6 when you try to start your web site and it has not been assigned to a valid application pool.

This usually happens when the default app pool has been deleted.

HTH

Tim

Uninstall IE 7

Tim Huffam — Fri, 16 Sep 2005 00:14:00 GMT

Those of you wanting to know how to remove this annoying version on IE - click here.

However, if you are as unfortunate as myself, and have had another user has install it (IE 7 beta) on your PC, then you will get this error:

"Internet Explorer 7 Beta 1 cannot be uninstalled from this user account. Please log on to the same user account from which it was installed and try again."

Even if you belong to the local administrators group. Brilliant!

*** Update: For those of you wanting a far superior browser that has none of the IE problems - I strongly recommend FireFox - which I now use all the time.