We're having an issue with a .NET 3.5 WebForms site where occasionally our error logs start filling up with the following error message:
"Multiple controls with the same ID 'ctl09' were found. FindControl requires that controls have unique IDs."
I know very little about the exception as I have never seen it while debugging locally and have never caught it in the error logs soon enough to run a remote debugging session. I do know that an application pool recycle fixes the issue.
This only affects a single [high traffic] page in the site. The strange thing is that the site uses the pre-4.0 ID generation logic. So, when the page is working, there isn't an html element in the entire view source that isn't some autogenerated control ID prefix followed by a the 'actual' IDs (i.e. ctl09_someID_someOtherID).
So, 2 primary questions, though any ideas are welcome:
What would case a control to randomly stop being built correctly?
Other than the Global.asax, how can I trap this error and force the control to ... recompile? App pool to recycle?
I'm pretty much stumped.
Nothing as far as I'm aware, only an outside entity interferring with the page lifecycle or AJAX postback could potentially cause this, if each control is being generated, in turn, then you will not 'randomly' experience duplicate ids.
I don't think this is a viable option, app pool recycle? No way, there's got to be a valid reason for this.
Perhaps some more info/code would be useful? Is it a particular page? Are you using ViewState? There's lots of reasons for 'dodgy' control ids.
Related
Here is image of the error and the code segment where it is erroring out.
Project was originally developed in VS2010 but was "upgraded" to VS2012 cause client has that dev environment. Not sure if there are other things i need to do after the upgrade that would resolve this problem or not.
This error only occurs when i place the Me.MaintainScrollPositionOnPostBack = True in Page_Load, Page Directive, or Web.Config. I have tried using self reference and Page reference and same problem.
If i remove the line of code Me.MaintainScrollPositionOnPostBack = True from any of the 3 locations the WebDev.WebServer#### runs the application fine.
Ultimate goals is that i have an undefined length object being loaded into a table. It could be as little as 5 items in the table or up to 100. In either case each item has a RadioButtonList object associated with it. Each RBL when clicked then submits the choice selected back to the SQL server and ultimately refreshes the page. This setting was suppose to fix the problem of the refresh, or PostBack, from resetting the scroll back to the top.
Found out after removing the MaintainScrollPositionOnPostBack property but adding in AJAX controls, i received similar errors.
Question:
Any suggestion on fixing this problem, so it wont occur in VS2010 or VS2012?
Is there an alternate approach so i can sustain the scroll position on the page while still submitting the RBL selected index change event to the SQL server?
How do i fix this so the JavaScript is either installed on my computer or WebServer instance from VS2010/2012 will use Javascript?
Seems this is related to Ajax registration within the web.config even though i have it registered in the project. Anyone know what declaration i need in web.config so ajax is run from the server and doesnt require client interaction? (FYI, .Net 4)
We have been trying to figure this one out for a while now, without any luck.
The symptoms are as follows:
After some idle time of a specific ASP.NET 2.0 application (can be from several hours to days), one of the pages in my application stops working.
When viewing the source of the page I see many elements missing, elements that are usually there, such as: reference to WebResource.axd, the __doPostBack() function, all of the UserControls and more.
A reference to ScriptResource.axd, and the __VIEWSTATE are there.
After recycling the app pool, the application starts working correctly again and everything renders well.
This only happens on a specific server, when deploying the same application on a different server, this error does not occur.
The page that the error occurs on has only one UserControl which is not rendered when the error occurs. Nothing special happens when this page is loaded.
We tried doing periodic client refreshes, but that did not help either.
Thanks in advance.
It was a caching issue. There was a part in the code that hid specific controls when the cache was invalid. That explains the missing code parts.
I am still not sure why the cache was invalid on that specific server.
i am facing the dreaded:
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
Error.
Ok so i looking it up and found that it can be caused by two things, viewState which can not be verified by the page, and/or events that can not be validated.
I put
<pages enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never">
In my web.config to stop the problem, but that hardly seems like a fix to me.
The thing is, i never even used viewState in my application. I know that asp.net uses viewstate by default to store some things, but i doubt the default values stored here will cause any errors.
I noticed that the problem seems to happen when i postBack and the page has not finished loading yet.
Thanks
Edit: Please, can someone test my website www.vittoriosaStarsNursery.com and see if you get the error i got above? I dont get it locally but people keep telling me they are getting it.
Isnt this just a case of putting a one liner in your web.config
<machineKey decryptionKey="A4B12CCDD50E95F8GB9GFH6JKAT4Y0U0I2OF2DF2AAFE5AB46189C,IsolateApps" validation="AES" validationKey="480CDF2AS9S9AS5CFDGF0GHFH9JJH4KHKAKLJ2L9F3SAS82A6C16911A29EF48903783F94529C21570AACB72766FB38CD4CE7B85B0ACE3149DC5FC1CCF1AA1CECE3579659996593B06,IsolateApps"/>
One thing I have come across that causes this issue has to do with the recycling intervals of the app-pools on the webserver.
I found this by looking at the event information in Eventviewer/Application logs and the "Task Category" called "Web Event". Then for the time period that this event took place I looked to see if there were any recycled events that took place just before that (Eventviewer/System logs and the "Source" called "WAS".
By default an app-pool will recycle every 1740 minutes (29 hours). If this recycle happened while a user is busy on the site and send post back to the server, the server no longer recognizes the session/viewstate and rejects what is being posted back.
To overcome this from our perspective is to set the recycle event to happen at a specific time of the day when we don't expect activity on the site. In our case 3am in the morning.
Hope that helps someone out there.
You're not going to like my answer. This error is basically unavoidable in webforms. My solution was to leave webforms for MVC3 and razor.
I noticed that the problem seems to happen when i postBack and the
page has not finished loading yet.
this is one of the easiest ways to cause this error. In ASP.NET 3.5 (or 4.0) there's a setting that you can make sure viewstate gets loaded very early in the page to try to help diminish it. It still doesn't solve it.
Chunking the viewstate doesn't solve it.
There is just something inherently wrong to the way webforms works that this error will plague your application at random times forever.
At my site, this meta tag were causing the error:
<base href="http://www.SITEURL.COM" />
I have a dropdown, I update on another dropdowns changed selection. So when the postback happened (dropdown #2 changed index), I got the exception.
I've tried everything else from applying machinekey to web.config and setting theese attributes at the page
EnableViewState="false" EnableViewStateMac="false"
I am using VS 2010 against a Windows Web Server 2008 and what I eventually found was that I had two keys set for the same service in the appSettings section of webconfig. I went to IIS and checked the Application Settings on the virtual directory and got an error, fixed it in the WebConfig and the problem resolved. I did create a machine key but that did not fix the problem. Nor did the
pages (...) validateRequest="false" enableEventValidation="false"
enableViewStateMac="false" viewStateEncryptionMode ="Never"/
Settings. FWIW ...
I used this Microsoft article to create my own machineKey validationkey and decryptionKey. As others have stated, this can be placed within the system.web section of web.config, though there are security concerns if other people get hold of the key.
Well, yes i suppose disabling encrypted viewstate solves the problem but i have never tested it nor do I advise it. Viewstate stores the state of controls and is also very convenient for storing persistent variables.
Take for example you work for a garage and have a list of jobs. You go to a page that lists the jobs. Now you click a job which goes to another page appending the jobid (eg. job.aspx?id=1). On that page, there is a checkbox which marks the job as complete. Once you tick that checkbox, it posts data back to same page and writes to the database that the job is complete. But how does the server know which job to mark as complete because you have only posted back true or false from the checkbox. However, if the first time you load the job details page you record the job id in Viewstate, then when you post pack the checkbox, you can read in the jobid from the viewstate.
Why is it not good to use unencrypted viewstate?
Imagine what the server has to do to mark the job as complete. It probably has to run an sql command to update the database. Something like UPDATE jobs SET completed=GETDATE() WHERE id=1.
If your viewstate wasnt encrypted and i could add my own job id, I would put something like '; DELETE FROM jobs;' which would then cancel out the initial UPDATE command and delete ALL your jobs... not very good for the garage :)
I have an ASP.NET website that has been deployed since 2008 with plenty of users. From time to time, I've made updates to the site and uploaded those changes to the server without problems.
However, today, I'm trying to run the site on my development environment and I keep getting errors any time the code tries to access session state. It appears System.Web.HttpContext.Current.Session is always null!
Any suggestions on where to look? It's been a while since I worked on it and am not 100% sure if I've worked on it with the current version of ASP.NET (4.0).
Other than that, the code's been working fine and I haven't made any changes since it was last working.
More Information
I've spent all morning on this but I apparently have a larger issue.
If I step through the code, I see that my page Load handler executes. At this point, Session is not null. After that, my specialized master page executes. After that, my general master page executes. I then step through load events for a couple of controls. This all seems very normal.
Then, if I keep executing, suddenly I'm loading a specialized master page for another page and Session is now null!
If I hit F5, it the original page shows. But somehow it is causing the other page to load and without session state. If I turn off debug mode, it appears to run normally.
Obviously, I have something strange happening. I need to determine why the other page is being loaded.
Try to put a static page, something like Test.aspx and browse to that page. If it gets loaded, try to use Session property of the page in code behind. Do you still get the error? In that case, Session doesn't load. I suggest creating an HTTP Module and hooking into a method which is responsible for loading Session info. See what's wrong.
Just a guess - did you deactivate sessionState for any reason? Anything like this:
<sessionState mode="Off"/>
My apologies. The information I provided was completely misguided and was not sufficient to resolve the issue.
The problem was actually due to some custom error handling that redirected to an error page. This was configured in web.config. This error page was using the master page that my code was mysteriously executing.
Apparently, an error was occurring within the GridView control. This is ASP.NET code and not my own, so I was unable to step through it or catch it with a regular handler.
This was hard to understand. If I was executing the Load event handler of my error page, then it would've been obvious. But it appears to have skipped over that. Thus, my confusion.
Try checking the global.asax file or any other pre-load events and make sure the Session is not set to NULL explicitly.
Maybe your erring master page is calling code from some external class where the session object is not available?
I've had this intermittent issue when using asp.net. My site is dynamically compiled. Sometimes when I modify a user control my web site complains that it is defined in multiple places. It almost seems like the old control did not get removed from the asp.net temporary files and the updated control is compiled to the same directory so it's defined in multiple places. That would make sense to me except for the fact that I have no control over what is in the Temporary ASP.net Files folder.
I've read that having circular references will cause this. I've made sure that I don't have circular references. Even with the simplest site I've seen this happen.
I've noticed that when using Master Pages this error seems to come up a lot more frequently.
I've read that a hotfix tries to fix this issue but I've gotten this error after applying the hotfix.
If I get the file causing the issue and make an edit to it then the error goes away. Even if I just put a space in the file it will resolve the error.
I can also get the error to resolve sometimes by visiting other pages of the site that might not use the user control and hitting refresh. This does not always work.
If I set the site to debug the error never happens. If I set it so that it comiles on a page by page basis then the error does not happen as much but still happens.
Below is what the error looks like.
Compilation Error
Description: An error occurred during the compilation of a
resource required to service this request. Please review
the following specific error details and modify your
source code appropriately.
Compiler Error Message: CS1595: '_ASP.Header_ascx'
is defined in multiple places; using definition
from 'C:\WINNT\Microsoft.NET\Framework\v1.0.3705\Temporary
ASP.NET Files\root\afwew23d\asdfasd423\asdf23.dll'
Edit:
I'm using .net 2.0 (3.5) even though the error above says 1.0. I got that error from another source since I can't reproduce the issue every time. But the type of error is the same.
Edit 2:
Thanks gisresearch for your research. There was one statement in the link you provided:
One caution even if you have debug=false, is that if you go in and change something in one of your aspx pages, this page will have to be recompiled, but this doesn’t cause an appdomain reload so the whole application is not batch compiled again. This has the effect that the page will now get recompiled separately and get its own dll, so don’t change your aspx pages on a live server too often.
There is a setting in machine.config determining how many recompiles are allowed before the app domain restarts, by default it is set to 15, so after 15 recompilations the app domain will restart, just as it would if you touched the web.config or touched the bin directory.
This seems to say that when debug=false and the site has already been visited and compiled, if you change a page it will only compile that one page. That sounds like it could cause problems. I had thought changing a page or user control would cause the entire app to recompile.
Do you have two user controls with the same file name in diferent Folders of your Web App?
That sometimes will cause this issue.
If I set the site to debug the error
never happens.
when debug=true, the asp.net compiler don’t batch compile, when debug=false it does batch compile and may cause this issue.
The Read this post.
There is a conversation about the same issue.
re: ASP.NET Memory: If your application is in production… then why
is debug=true Monday, April 24, 2006
2:39 PM by Robbie Coleman We did get
an error for a UserControl that it
reported it could not load the
FileName_ascx class due to multiple
versions in the Temp ASP.NET folder.
We identified that we had two user
controls with the same file name in
diferent Folders of the same Web App.
The also had diferent namespaces and
never through this exception until we
set debug="false". We even wiped the
Temp ASP.NET directory clean on an
IISreset.
The only way we could fix the error,
was by renaming the ascx file of one
of the two.
Is this correct...? Was there a better
way to fix this?
BTW... [KissUpText] Tess, your posts
have been very helpfull to our
development team, and we really
appreciate all the information you
have given away. [/KissUpText]
re: ASP.NET Memory: If your application is in production… then why
is debug=true Tuesday, April 25, 2006
1:56 AM by Tess Hi Robbie,
Thanks for the nice comment:)
I am assuming that you are getting
"CS1595:
'UserControls.WebUserControl2' is
defined in multiple places; using
definition from
'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary
ASP.NET
Files\usercontrols\293a1a4b\dbb2d387\cisxatg3.dll'
" or similar.
The problem basically occurrs if you
are using src rather than CodeBehind
and your cs or vb files contain a
definition for exactly the same class
in exactly the same namespace. The
error is really the same as what you
would get if you tried to compile a
dll with another class defined twice
in the same namespace.
The reason i am saying it happens when
you use src is because if you would
use CodeBehind you would have gotten
an error at compile time.
If the usercontrols are really the
same I would avoid creating a copy,
and instead using the one from the
other folder. If they are different I
would either give the different names
if possible, and if not, make sure
that the source classes are in
different namespaces, such as
ProjectName.FolderName.MyUserControl
The reason you are seeing it now and
not before is because you are now
batch-compiling everything into one
dll.
Hope this helps.