ASP.NET - IIS Troubleshooting

Tag Causes Local Automatic ASP.NET debugging not to work in Visual Studio

amitsh — Mon, 02 Feb 2009 23:33:00 GMT

This week I got an interesting issue altogether. One of my customers was unable to debug ASP.NET 3.5 application locally using Visual Studio 2008. The application was created using Web Application Project. When we started the application using "Start Debugging (F5)", page came up fine but debugger was not getting attached to process. In Visual Studio we could still see the "Play" button for starting debugging. We didn't get any errors either in Visual Studio or in Event Logs. At the same time when we try attaching the Visual Studio debugger manually then it worked fine.

We confirmed the current user has all the required permissions and is admin on the machine. We went through all the possibilities as per KB - "INFO: Common Errors When You Debug ASP.NET Applications in Visual Studio .NET" but no luck.

When we checked configuration carefully found that the <compilation debug="true" /> Tag was encapsulated within <location path="." allowOverride="true">, like below code snippet -

<?xml version="1.0"?>
<configuration>
    <appSettings/>
    <connectionStrings/>
    <location path="." allowOverride="true" >
      <system.web>
          <compilation debug="true">
          </compilation>
          <authentication mode="Windows" />
      </system.web>
    </location>
</configuration>

We tried removing location tag as that was the only thing suspicious here and it started working!!!

So I did some research and found that this is something consistent across all the Visual Studio Versions Supported (2003, 2005 and 2008) when we use the Web Application Project. Basically placing a <system.web><compilation debug="true" /></system.web> setting inside a <location path="."> tag is correctly interpreted by ASP.NET, but Visual Studio thinks that the web.config isn't set up for debugging.

When we try the same web.config with Web Site in Visual Studio 2005 or 2008 it gives up dialogue -

So to get around this situation we need to remove the location tag from web.config.

I hope this help!

Issue with publishing web-site as non-updatable with "Use Fixed Naming and Single Page Assembly" and assembly versioning

amitsh — Sat, 15 Nov 2008 01:13:00 GMT

Few days back I came across an issue with Publish Web Site and assembly versioning. One of my customers was trying to publish a web site as non-updatable with "Use Fixed Naming and Single Page Assembly" option. Also at the same time they are setting the assembly version to the assemblies as well. In this scenario once publish was completed, few assemblies were missing the version information (all those pages had huge HTML strings in the aspx source).

So I tried reproducing the issue and it was pretty simple to reproduce.

Below are the steps for it -

Add the below code in the ASPX Page -

<%@ Page Language="C#" %>

<script runat="server"></script>

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>Untitled Page</title>

</head>

<body>

<form id="form1" runat="server">

<div>

<table>

<tr><td></td><td></td><td></td></tr>

</table>

</div>

</form>

</body>

</html>

Add below code in web.config -

<?xml version="1.0"?>

<configuration>

<appSettings/>

<connectionStrings/>

<system.web>

<compilation debug="false"> </compilation>

<authentication mode="Windows"/>

</system.web>

<system.codedom>

<compilers>

<compiler language="c#;cs;csharp" extension=".cs"

type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b77a5c561934e089" compilerOptions="{physicalpath}\VersionInfo.cs">

</compiler>

</compilers>

</system.codedom>

</configuration>

And the VersionInfo.cs should have below code -

using System;

using System.Reflection;

using System.Runtime.CompilerServices;

using System.Runtime.InteropServices;

[assembly: AssemblyVersion("1000.00.00.0001")]

[assembly: AssemblyFileVersion("1000.00.00.0001")]

Now try to publish web-site as non-updatable with "Use Fixed Naming and Single Page Assembly" you will not see the version in the explorer for the assembly created for this particular page.

After digging in further around this issue I found out that when a page has string literals (html or text that is not part of a control) of length equal or longer to 256, ASP.NET stores those strings into a win32 resource file before embedding it into the assembly (using csc.exe /win32res:file.res).

As a result, the AssemblyVersion and AssemblyFileVersion attribute in the assembly is masked by the win32 resource. If you try using System.Diagnostics.FileVersionInfo or AssemblyName.GetAssemblyName, you won’t get any file or assembly version from the assembly. If you view the assembly in Explorer, you don’t see any version information either. But if you open the assembly in ILDASM it shows the version correctly.

The workarounds for this situation would be –

1. Insert dummy controls into pages with long string literals. This will break up the strings to avoid generating the win32 resource. (That means we have to make sure we are encapsulating all the html or Text within dummy server controls to make sure that there are no string equal or greater than 256 outside controls).

As per above repro if we replace the code in the ASPX with below code, it won’t fail for versioning –

<%@ Page Language="C#" %>

<script runat="server"></script>

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>Untitled Page</title>

</head>

<body>

<form id="form1" runat="server">

<div>

<asp:Literal runat="server" ID="Test">

<table>

<tr><td></td><td></td><td></td></tr>

</table>

</asp:Literal>

</div>

</form>

</body>

</html>

2. Use web deployment projects, and use the “Version output assemblies” option.

(Note that you will be unable use this option if you choose “Create a separate assembly for each page and control output”, because that option is equivalent to running aspnet_compiler with - fixednames, and does not go through aspnet_merge.)

I hope this helps!

Issue with ActiveDirectoryMembershipProvider and account lock policy

amitsh — Fri, 05 Sep 2008 18:23:00 GMT

Recently I was working on issue with ActiveDirectoryMembershipProvider of ASP.NET 2.0 and I came across interesting finding which I thought of sharing.

The scenario which I had was a little tricky. One of my customers was using ActiveDirectoryMembershipProvider along with the maxInvalidPasswordAttempts for locking the Active Directory User after 4 invalid attempts.

(Note - As per the information documentation around maxInvalidPasswordAttempts, this property does not control the number of failed logon attempts a user can make before being locked out. The Active Directory server handles failed logon attempts and is not affected by the value of this property.)

In the Active Directory configuration for account lock policy we had “Account lockout threshold” set to 4. So we set the value of maxInvalidPasswordAttempts to 4 to be in sync with the Active Directory configuration. But interestingly, when we try doing it… just after 2 invalid attempts the user’s account gets locked. That means if we set the “Account lockout threshold” to X then while using ActiveDirectoryMembershipProvider in ASP.NET 2.0 application, the account will get locked after just X/2 attempts.

I have confirmed that this behavior is by design. The reason behind that is internally ActiveDirectoryMembershipProvider uses IADsOpenDsObject::OpenDsObject method or the ADsOpenObject function. This function is supposed to validate the user via Kerberos first and if it fails then it tries with NTLM and in turn increments the BadPwdCount count by 2.

So in case if one is willing to use ActiveDirectoryMembershipProvider with account lock policy in place, then we have to make sure that we double the value for “Account lockout threshold” than required.

I hope this helps!

Why cacheRolesinCookie does not work well with the Ajax Extensions 1.0 and RoleManager of .NET Framework 2.0?

amitsh — Sat, 24 Nov 2007 03:37:00 GMT

One of my customers ran into this issue couple of months ago. I wanted to blog it earlier but I was waiting for the Fix to come out.

The typical scenario is - you are using the System.Web.RoleManager of .NET Framework 2.0 along with Ajax Extensions. When you do a callback you might run into exception as below (changed the names as required) -

Event Type: Warning

Event Source: ASP.NET 2.0.50727.0

Event Category: Web Event

Event ID: 1309

Date: 10/16/2007

Time: 11:24:13 PM

User: N/A

Computer: ABCD

Description:

Event code: 3005

Event message: An unhandled exception has occurred.

Event time: 10/16/2007 11:24:12 PM

Event time (UTC): 10/17/2007 5:24:12 AM

Event ID: 3984df620d5148d58cfddc59a2c64559

Event sequence: 17219

Event occurrence: 95

Event detail code: 0

Application information:

Application domain: /LM/W3SVC/12345/Root/Client-11-128370461828028786

Trust level: Full

Application Virtual Path: /Client

Application Path: C:\Inetpub\wwwroot\Test\

Machine name: ABCD

Process information:

Process ID: 4448

Process name: w3wp.exe

Account name: ABCD\ABCD

Exception information:

Exception type: HttpException

Exception message: Server cannot modify cookies after HTTP headers have been sent.

Request information:

Request URL: <http://Test/App_Themes/Default/Styles/Base.css>

Request path: /App_Themes/Default/Styles/Base.css

User host address: 71.123.134.143

User: ABCD@ABCD.com

Is authenticated: True

Authentication Type: Forms

Thread account name: ABCD\ABCD

Thread information:

Thread ID: 18

Thread account name: ABCD\ABCD

Is impersonating: False

Stack trace: at System.Web.HttpCookieCollection.Add(HttpCookie cookie)

at System.Web.Security.RoleManagerModule.OnLeave(Object source, EventArgs eventArgs)

at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Custom event details:

For more information, see Help and Support Center at <http://go.microsoft.com/fwlink/events.asp>.

This comes up because you can’t send a set-cookie header after anything has been sent to the client.

Now the OnLeave event of RoleManager is set to be executed on App.EndRequest (Code taken from Reflector) –

public void Init(HttpApplication app)

{

if (Roles.Enabled)

{

app.PostAuthenticateRequest += new EventHandler(this.OnEnter);

app.EndRequest += new EventHandler(this.OnLeave);

}

And when you use Ajax, HTTP Headers are sent back to client before Application_End and this OnLeave event will try to modify the cookie if CacheRolesInCookie is true –

private void OnLeave(object source, EventArgs eventArgs)

{

if (Roles.Enabled && Roles.CacheRolesInCookie)

{

.......

}

Since the content is flushed by the time that code runs and the code does not check if something is sent to client already, the exception comes up.

This issue has been fixed in the .NET Framework 3.5 release. It still doesn’t send the cookie, but you won’t throw an exception. The code looks like below -

private void OnLeave(object source, EventArgs eventArgs)

{

HttpApplication application = (HttpApplication) source;

HttpContext context = application.Context;

if (((Roles.Enabled && Roles.CacheRolesInCookie) && !context.Response.HeadersWritten) && (((context.User != null) && (context.User is RolePrincipal)) && context.User.Identity.IsAuthenticated))

{

.....

}

There is no workaround for this issue in .NET Framework other than not using CacheRolesInCookie itself by setting it to false.

I hope this help!

Why I am not able Turn Off CustomErrors?

amitsh — Fri, 02 Nov 2007 01:50:00 GMT

This week I got an interesting issue altogether. One of my customers was unable to turn off the CustomErrors at all. We checked all the web.config files in hierarchy including the web.config and machine.config in C:\WINNT\Microsoft.NET\Framework\v2.0.50727\CONFIG. All files had an entry <customErrors mode="Off"/>, purposefully added to avoid this behavior. But we were still getting below message whenever any exception comes up –

Server Error in '/Test' Application.

--------------------------------------------------------------------------------

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.

Details: To enable the details of this specific error message to be viewable on the local server machine, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".

<configuration>

<system.web>

<customErrors mode="RemoteOnly"/>

</system.web>

</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<configuration>

<system.web>

<customErrors mode="On" defaultRedirect="mycustompage.htm"/>

</system.web>

</configuration>

This message was common while browsing the application on both client and server. So one thing was for sure that some setting in some config file is turning on the CustomErrors with mode = “on”.

Now customer wanted to see the exception which was coming up. Though ASP.NET 2.0 by default logs it in the event logs, it is not possible for all of the developers to log onto the server and check the event logs.

So while troubleshooting this issue we found the machine.config on the server is bigger than usual size (19KB).

So when I checked the machine.config file, we found it was having <deployment retail="true"/> added in it. This entry reminded me of Praveen’s Blog entry around debugging issue when retail is set to true. We removed it and we were spot on.

The use of the <deployment retail="true"/> switch in the machine.config file turns off the ability to show detailed ASP.NET error messages both to remote clients and locally. So effectively it acts as <customErrors mode="On"/> is set.

This deployment retail switch should still be your primary method of turning off these error messages (detailed errors on browsers) if you are running ASP.NET 2.0. (To get detailed information regarding ASP.NET exceptions, use the Application Event Log.)

The only resolution for this to remove the <deployment retail="true"/> switch by either commenting it out or setting retail= false.

Alternatively you can show the custom error pages itself as the messages suggest.

For more information on Retail member check http://msdn2.microsoft.com/en-us/library/system.web.configuration.deploymentsection.retail(VS.80).aspx.

I hope this help!

Global.asa of 0 KB acts funny on Windows 2003 after installing SP2.

amitsh — Tue, 14 Aug 2007 02:30:00 GMT

Few days’ back one funny issue came to me. All of a sudden on one of the Windows 2003 server my customer was getting “HTTP/1.1 500 Server Error” for any .asp pages in the application. It stopped working since last couple days and used to work earlier. So here the obvious question would be - What was changed two days ago?

Customer confirmed that nothing but the installation of Service Pack 2(SP2) of Windows 2003 was done.

This sounded funny to me but when I tested the universal Time.asp (script showing the current time using <%=now()%>) in the same application, interestingly even that gave “HTTP/1.1 500 Server Error” too! No extra filters nothing and still this behavior and I was confused.

I started thinking about this issue and checked the entire IIS pipeline which can interfere with the request – ISAPI, Extension mapping etc. but no luck. So the only thing which remains is the “Global.asa” which comes in the pipeline before the page execution starts. And bingo found an empty (0 KB) Global.asa in the application. Renaming it to Global.asa.old and everything worked.

So I tried this on my own test machine and got to conclusion that having empty (0 KB) Global.asa breaks the .asp page request execution after SP2 is installed on Windows 2003 Server and you will start getting “HTTP/1.1 500 Server Error”. Resolution to this would be not to leave this unwanted creature to live in the application :)

So if you have installed SP2 and simple test page is throwing an error “HTTP/1.1 500 Server Error”, make sure that you don’t have any Global.asa of 0 KB size in the application (possibilities are endless and it's one of them).

We do have a Knowledge Base article published for this - http://support.microsoft.com/default.aspx?scid=kb;EN-US;936476

I hope this help!

What Vista Firewall settings are required for enabling remote debugging?

amitsh — Sun, 12 Aug 2007 23:02:00 GMT

This a bit of a tricky thing. We all know the famous KB for “How to turn on remote debugging in Windows XP with Service Pack 2, in Windows Server 2003 Service Pack 1, or in Windows Vista” and we do all these settings on the Vista box to turn on debugging.

But this is not quite enough some times and in one of the issues I came across we were getting below error message –

Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'server-computer name'. The Microsoft Visual Studio Remote Debugging Monitor on the remote computer cannot connect to the local computer. A firewall may be preventing communication via DCOM to the local computer. Please see Help for assistance.

This was a quite a puzzle for me as I was able to see that RDM was running and was showing the user as connected.

I was luckily able to repro the issue on my machine as well and started looking for options. From the error message I thought the Windows Server 2003 server firewall might be blocking it. I tried turning off the firewalls completely on the server but still no luck for me at all.

So finally we were in the situation where the Vista Firewall was causing this, but which setting did we need to change?. Here are the steps which I followed to figure it out–

- Opened “Control Panel -> Administrative Tools -> Local Security policy”.

- In the section "Windows Firewall with Advanced Security" I found "Windows Firewall with Advanced Security - Local Group Policy Object". When I clicked on this, on the right hand side I found "Windows Firewall Properties"

- I clicked on that, it opened the "Windows Firewall with Advanced Security - Local Group Policy Object" dialog box.

- In this dialog box, we have different tabs to configure for various scenarios like "Domain Profile", "Private Profile" etc..

- For my scenario "Domain Profile" is the one as both my machines are in same domain. Under this tab, we have "Firewall State" which was set to "Not configured".

We also have Inbound connections and Outbound connections set to "Not configured".

- I set the options as follows:

1. Firewall State = "On (recommended)"

2. Inbound connections = "Allow"

3. Outbound connections = "Allow (default)"

This solved the problem. I was able to manually attach to the remote machine. I could see the process in the list and I could attach to remote W3WP process and successfully debug and hit the break points.

The similar settings I think we can do via command line as well as per the thread on discussion group.

I hope this help!

Need a Hotfix.. Get it online

amitsh — Sat, 11 Aug 2007 05:17:00 GMT

At Microsoft PSS, we get a lot of Hotfix requests. Till few days ago we always required customers to call into Microsoft Product Support to get a Hotfix. But since few days we have made many, if not all, Hotfixes available on web. So now on getting Hotfix is as simple as filling up a simple online form and receive the Hotfix by email.

You can get detailed information about it here. And the link for the Hotfix form is this.

I hope this helps and makes you happy!

Why can’t I execute two requests from the same session simultaneously for an ASP.NET application?

amitsh — Wed, 01 Aug 2007 02:08:00 GMT

Many times we need pop-up windows to appear in our Web Applications. In such a scenario we have the same user session used by the two instances of the web browser. So for N number of pop-ups we open, we have N instances of browsers using the same user session.

So the question which will come to mind is, will these requests using the same user session be executed concurrently?

The answer to the question would be - maybe.

The request execution will work fine concurrently until the time we are not accessing session data at all. If we would have accessed the session data anywhere in the request then the requests won’t be served concurrently. Requests will be executed one at a time.

We can check this behavior with a simple demo –

Have 2 pages in an ASP.NET application as Default.aspx and LongRunningPage.aspx as below –

Default.aspx

<%@ Page Language="C#" %>
<html>
<head runat="server">
    <title>Default Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
     <a href="LongRunningPage.aspx?interval=50000" mce_href="LongRunningPage.aspx?interval=50000" target="_blank">Interval 50000</a>
     <br /><br />
     <a href="LongRunningPage.aspx?interval=1000" mce_href="LongRunningPage.aspx?interval=1000" target="_blank">Interval 1000</a>
    </div>
    </form>
</body>
</html>

LongRunningPage.aspx

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Now when you click on the link “Interval 50000” on Default.aspx the first page will come up and will wait for 50000ms. Meanwhile if you click on the link “Interval 1000” it will come up after waiting for 1000ms.

Now clear the browser cache and change the Page_Load for LongRunningPage.aspx as below –

protected void Page_Load(object sender, EventArgs e)
{
        int interval = Convert.ToInt32(Request.QueryString["interval"].ToString());
        Session["Test"] = "Test";
        System.Threading.Thread.Sleep(interval);
}

Now when you click on the link “Interval 50000” on Default.aspx the first page will come up and will keep waiting for 50000ms. Meanwhile if you click on the link “Interval 1000” it won’t come up until the first page comes up (opened by clicking on the link “Interval 50000”) and then it will wait for 1000ms and then it will be rendered.

This is expected behavior. The reason behind this is session state implements a reader/writer locking mechanism:

- A page (or frame) that has session state write access (e.g. <%@ Page EnableSessionState="True" %>) will by default hold a writer lock on the session until the request finishes.

- A page (or frame) that has session state read access (e.g. <%@ Page EnableSessionState="ReadOnly" %>) will hold only a reader lock on the session until the request finishes.

- As we can understand based on concepts of locks – a Reader lock will block a writer lock; a Reader lock will NOT block a reader lock; a Writer lock will block all reader and writer locks.

This lock is acquired within the event AcquireRequestState and released in the event ReleaseRequestState of a request. That's why if two frames/pages both have session state write access (the default option unless you use EnableSessionState="ReadOnly" ), one frame/page has to wait for the other to finish.

So the work around for your problem would be to use the ReadOnly Session access mode (for example using EnableSessionState="ReadOnly" ) if you have the requirement of only reading the session state, or else you have to make sure the requests are NOT long running.

Additionally you will see similar behavior when you have a Global.asax in the application. By default if you do not have a Global.asax file in an ASP.Net application, and there is no access to any session reading/writing, then effectively no session exists from an ASP.Net perspective. One trigger to make ASP.net create session infrastructure is to have a Global.asax file and have events in it regarding Session start, end etc. This will trigger the sessions to be created and the request ultimately accesses the session via session events. We will see similar behavior when there is a Global.asax in the application and you fire a next request for this same session: it will be put on hold until the first request completes.

I hope this help. Happy Reading!!!

Why do I get "Invalid postback or callback argument" Errors?

amitsh — Tue, 31 Jul 2007 23:28:00 GMT

Introduction:

This is the first post of mine so thought of starting with a simple but tricky issue which I came across in few support incidents I have handled. I had a scenario where one of my customers was getting an error message like -

Invalid Postback or callback argument . Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to Postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the Postback or callback data for validation.

Many of us get this error message often, either in the event viewer or on the page itself. But what does it signify? When does it come up? What we can do to eliminate this exception due to coding mistakes?

What does it signify?

In ASP.NET 2.0 we have added a feature called event validation. Event validation checks the incoming POST request to ensure that the event causing the Postback / callback is valid and the event which triggered the Postback /callback is expected by the Runtime. If the runtime finds a Postback / callback by an event which is not registered for validation, it throws an exception. This has been added in ASP.NET 2.0 explicitly to prevent the attack to the application by spoofing a Postback. Event validation can help prevent injection attacks from malicious users who are trying to POST data by an event which does not come up from the controls registered to the page.

You can enable or disable this feature by simply setting up Property EnableEventValidation = true in the web.config or on the page level. By default it is enabled. You can find more information about this property in the MSDN link.

So this is about all the “good” which event validation signifies. Agreed that this is a very good security feature which helps preventing script injection attacks but if it is coming during the normal execution of an application, the exception is not expected and does not hold “good” anymore. That is where we need to troubleshoot and find out the problem area.

When does it come up? What we can do to eliminate this exception due coding mistakes?

As I have already spoken about the script injection attack can cause this exception, we should not bother about why it is coming up. Rather in that case we can track down the client who is trying to inject the attack and take appropriate action. So I will rather focus upon the scenarios when it comes up due some coding mistakes.

These mistakes are many in number so I would rather cover just a couple of them in this Post:

1. You have migrated an ASP.NET application from version 1.1 to version 2.0. In 1.1 we had to manipulate the "Select" button column for selecting the record and we normally set the visible property of this button column to FALSE.

The button column has "LinkButton" /”Button” for selecting records and we manually do a Postback using the __dopostback() method.

Agreed that the "LinkButton" /”Button” should register this method for event validation by internally calling the ClientScript.RegisterForEventValidation(). But with the “Visible” property set to FALSE, the control is not rendered and therefore control is not registered for EventValidation by ASP.NET 2.0. However, the DataGrid still utilizes this event. Since the event is not registered, it results in the above error.

In this scenario manually registering the client script for each DataGrid rows will help.

You can simply loop through the rows as mentioned in below code.

protected override void Render(HtmlTextWriter writer)

{

foreach (DataGridItem row in DataGrid1.Items)

ClientScript.RegisterForEventValidation(row.UniqueID.ToString() +":_ctl0");

base.Render(writer);

}

So this signifies that if you are not rendering the control then it is not registered for the validation internally. You need to do that manually using the RegisterForEventValidation function.

2. You have an ASP.NET 2.0 application which has a page with a lot of Javacript adding dynamic controls. On the POST of this particular page you will get the above mentioned exception for Invalid Postback or callback argument. This happens if Javascript is adding a FORM tag as well as adding dynamic controls resulting in the nested form Tags.

This can be reproduced quite easily as well –

In Default.aspx have the below code -

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"

Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<title>Untitled Page</title>

</head>

<body>

<div>

<asp:Button ID="Button1" runat="server" Text="Button" />

</div>

</form>

</body>

</html>

So this signifies that if you have nested form tags the above mentioned error message will come up.

So with these two scenarios I will stop at this point. I hope this first post of mine might help you and happy reading.