We are using RDLC's in a Asp.net web application. For reasons beyond our understanding, the first call to the database server fails with the following error:
An error has occurred during report processing.
Cannot open database "TryParkingIt2" requested by the login. The login failed. Login failed for user 'EXTRANET\OurServerNameHere$'.
Run the report again, it works.
Huh?
Update Click the button the first time, it fails. Click the button again, it works. The account being impersonated is a domain account. Also, this error occurs on all five different report pages, which is why I didn't include any code.
Look for static constructors or global.asax code that is failing. Those are run only once when the application starts up (actually for static constructors are run when the class is first accessed), so often they will cause a failure the first time, and then everything seems to work fine after that (even though something is really busted up in the background).
BTW, this is a GREAT reason to avoid static constructors.
Related
I had some custom error handling code in Application_Error, which was doing some logging and then handing off to my Error controller action/view. I had a bizarre issue where sometimes - and only on my production server, not on my development machine - the error page would appear, but no error details were recorded in the log.
I spent several hours trying to figure this out, and it turns out that my error page was being invoked directly, without going through Application_Error!
I saw a throwaway comment on another SO post that implied that this might happen with the HandleError attribute - i.e. that it would look for a view called Error, and simply render that, bypassing Application_Error.
I was using Elmah.MVC, and so did not explicitly use the HandleError attribute, because Elmah does this for you. However, it turns out that Elmah also does the straight-to-error-view thing too, because when I renamed my view (and controller action) to something else, everything started working as expected.
Just posting this in case it helps someone else...
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 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?
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.
I am trying to debug some code using Response.Write, but when I run the code it skips over that statement and errors out at some point further in the code.
How can I get my Response.Write statements to show without the other errors coming up?
I quite frequently use Response.End when I have to see a status in a certain place on a page.
We utilize Visual Studio 2008 to debug classic asp pages. You can attach to the IIS process and "step through" the page. Its very sweet. Here are the steps:
Get latest of the classic ASP from source control.
Install IIS (if not already). FYI... I am using IIS 5.1.
Create a virtual directory called "classicDebug" pointing to your local directory (C:\Websites\ClassicWebSite).
View the virtual directory properties, Virtual Directory tab.
Enable the "Script source access" checkbox.
Configuration button, Options tab - check everything.
Debugging tab - check everything.
7a. In the ASP.NET tab, select 2.x
Load up (not run or debug or F5) the website in VS.NET 2008.
Edit your global.asa accordingly (data sources, and paths).
Find the .asp page you want to "step through" and set a break point at the top (or somewhere).
Open IE, and navigate to your page.
Go back to VS.NET and select Debug -> Attach to Process
Check "show processes from all users" and select the process. For me (IIS 5.1), the process name is dllhost.exe running with the IWAM_COMPUTERNAME account w/type "Script, T-SQL, Managed, x86".
Visit your page using IE... VS.NET should break.
Comment out the line which gives the error and see what the respnse.write is displaying is the only thing reasonable.
Don't use the on error resume next while you are developing your pages. You have to make sure that you building your pages correctly and that your are producing correct code. You wont see any errors if you use on error resume next.
on error resume next should only be used, in my opinion, in database actions and in delivered (non-developning) code. In that case you should use the
if Err.Number <> 0 then
construct to test any errors. You simply cannot do that after every line in asp if you have put the on error resume next statement at the top of your code, but it certainly makes sence in database handling code.
You will have to use "on error resume next" statement on top of your ASP page. This will solve your problem when an error occurs it will move to next line rather than throwing an error.
You can check this link http://www.powerasp.com/content/new/on-error-resume-next.asp for reference.
Happy Coding
Try a Response.Flush after your debugging statments, or setting Response.Buffer to false.
This might help as an alternative to response.write.
I put together this ASP include class which works with Firebug+FirePHP. It allows you to log values (including strings, multi-dimensional arrays and even objects created with json.asp) to the firebug console and view ASP's built in collection objects which can help (particularly with Ajax where you can't output debug data without breaking the json response.) Ajax script load times and errors are automatically logged for quick viewing.
https://github.com/dmeagor/ClassicASP-FirePHP
Just include the file and use log(somevalue) to send formatted variables to the firebug console.
Released under MIT open source license
Speaking of alternate options, from David Meagor post, you can also write traces to a file. Here is an example of how to write to files: https://web.archive.org/web/20210506122630/http://www.4guysfromrolla.com/webtech/040699-1.shtml
If you want, you can even put the trace subroutines in an include file and use that in all your pages when you need it.
Another solution that we are using is to put the tracing methods in a .Net assembly, register it as a COM then call it using CreateObject.
These options will let you keep your traces in a file that you can review later and share with other developers.
I personally use a mix of these approaches: I review log files, use breakpoints and even place from time to time a Response.Write.
One other thing: activate and review the IIS logs: they will often tell you on what line your page broke. You can read here how to enable or disable logs for classic ASP: https://technet.microsoft.com/en-us/library/hh831387.aspx.