I have a HttpModule in C# 2.0 which handles exceptions thrown. Whenever the exception is thrown, an error page (aspx) with some querystring will be called. It is done through Server.Transfer().
But when the control tries to execute Server.Transfer(), the following exception is thrown:
Error executing child request for [pagename].aspx.
Whereas Request.Redirect() works fine.
I tried setting EnableViewStateMac="false" in Page directive of the page to which request is transferred. Still problem persists.
Here is the code I tried:
string errorPage = "errorpage.aspx?id=" + someErrorId
HttpContext.Current.Server.Transfer(errorPage,true);
Any idea how this can be resolved?
I found an alternative to Server.Transfer()
I used
HttpContext.Current.RewritePath("somefile.aspx");
This solved the issue.
I was hooking into the request pipeline in the OnPreRequestHandlerExecute event, and found I couldn't use Server.Transfer because it threw the same error as yours about executing a child request.
Using HttpContext.Current.RewritePath didn't work because it seemed to be ignored and I wasn't redirected anywhere.
If you're using IIS 7 and up, you can use Server.TransferRequest instead which did the trick for me.
The differences between the two methods are covered in this answer: TransferRequest vs Transfer in ASP.Net
My fix was different:
An online query produced this Microsoft Knowledge Base article which stated the resolution would be to use Response.Redirect instead of Server.Transfer.
I changed the command and got a more accurate "404 Error Message" instead of the cryptic "Error executing child request" message.
That led me to inspect the redirect string and I noticed my path was off.
I fixed the Transfer String from "ErrorPage.aspx" to "../ErrorPage.aspx" (notice the path change) and Server.Transfer worked just fine.
If you happen to see this exception occur in the VS.NET IDE during debug, go ahead at least once and press F5 to continue debugging. In my case, the actual page did render with the ASP.NET exception that was really causing the issue. In my case I had an incorrectly formatted asp:ChangePassword control that was actually causing the "Error executing child request" exception.
I changed Server.Transfer for Server.TransferRequest, then I've got the real exception behind. It was a problem with a reference to an incorrect ReportViewer version.
Server.Transfer("mywebpage.aspx") seems to work only when a session already exists.
If there is no Session started it throws this error so you must use Response.Redirect or another method.
I had this same problem, and discovered it was to do with the relative paths of where the Server.Transfer is running and where you are redirecting to. In my case, this was executing in a sub-directory, so #ray's answer (adding ../ to the start of the URL) worked. However, when I then executed in the directory above, the same thing happened. Therefore, I changed to using a rooted path:
Server.Transfer("~/errorpage.aspx")
It isn't a bug, it is by design. See http://support.microsoft.com/kb/320439
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...
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?
Hey I found a weird temperamental page which randomly gives me the following error
XML Parsing Error: no element found
Location: http://kj2011/site_2011/nonprofit-database/overview.aspx
Line Number 1, Column 1:
This page was fine for like 2 weeks but as of yesterday I randomly get the above error. I was to delete the pages and recreate the error is gone but would come back again few hours later. I have some other templates
i.e http://kj2011/site_2011/nonprofit-database/financial.aspx
Which has the same Master File and User Controls but never gets the error just the overview.aspx page.
Any Ideas ?
That sounds like the Firefox error page that's returned when FF expects HTML and gets an empty document instead. Try looking at it with Firebug enabled and see what the Net tab says - perhaps you have a good header, but no html.
Usually that kind of thing is not due to an ASP.NET error (since with those you still have a document body for the Yellow Screen of Death page), but is more along the lines of a networking error...
Would it be possible to try looking at it from another computer to see if that's the problem?
To find the issue you are having with this problem.
In your global.asax file add:
void Application_Error(object sender, EventArgs e)
{
Exception objErr = Server.GetLastError().GetBaseException();
string err = "Error caught in Application_Error event" +
"\n \nError Message: " + objErr.Message.ToString()+
"\n \nStack Trace: " + objErr.StackTrace.ToString();
System.Diagnostics.EventLog.WriteEntry("MYApplication", err, System.Diagnostics.EventLogEntryType.Error);
Server.ClearError();
}
You can set a break point here or log this message into an EventLog.
The most likely cause for such problem is security, if the problem occurs! check file security and make sure its accessible by asp.net process. (ASP.NET Required Access Control Lists (ACLs)), also does this occur with local calls on the same server?
Another thing is to check your page and make sure you don't have one or more unclosed tags in your markup.
I just debugged this issue on my website. In my case, the cause was a call to Response.End() . You can recreate the error by dropping Response.End() as the first line of Page_Load.
From MSDN ms524629:
The Response.End method causes the Web server to stop processing the script and return the current result. The remaining contents of the file are not processed.
In my case, Response.End() was being called before any content was written to the buffer. Also, there was no Content-Type in the response header (see attached Firebug screen grabs). My guess is because of these two factors, Firefox didn't know what to make of it and by default it tried to process it as a an XML file.
In your situation, my guess is the extra View.aspx file caused an exception that was interrupting page rendering cycle.
Just for the future reference, in case people come here from google
According to this thread, there are many different reasons to get this error.
In my case this caused by overriding
override void Render(System.Web.UI.HtmlTextWriter writer)
and I have not called base.Render(writer); at the end of overridden function.
This was an issue with an external DLL, which created a page called view.aspx in the same folder which caused an issue with our overview.aspx. We just renamed the page and the issue went away.
When the rewrite of the url in web.config has a problem - the browser send 404 error. Try to comment all the rules and check again if the 404 error arise.
Just to cover all the possibilities. Today I got the same error, no matter the page I was trying to access, but it was a completelly unrelated issue.
For some reason, Skype loaded before IIS on Windows startup and took control of port 80, instead of the usual 17112. Whenever I tried to access a page Skype returned an empty response.
You can simply shut down Skype and reset IIS, but to make sure it never happens again do the following:
Go to:
Skype > Tools > Options > Advanced > Connection
And uncheck Use port 80 and 443 as alternative for incomming connections
some time This type of error occurs when you have app_offline.html file in your directory.When ASP.Net found a file names app_offline.htm in the root of a web application directory, it shut-down the application, unload the application domain from the server, and stop processing any new incoming requests for that application. ASP.NET also then respond to all requests for dynamic pages in the application by sending back the content of the app_offline.htm file. The default content is an error message.
In my case it was the AjaxControlToolkit.dll that was missing from the bin folder. Adding a breakpoint in the Application_Error method in global.asax as suggested above allowed me to find this out.
I met the same problem, in my case, I lost a ';' in a syntax.
App_Themes folder was missing when I got this.
I am having this strange case, at first time when the page loades, everything goes fine. But as soon as I click on any link which makes any ajax request, after that, I get this error while trying to read the configuration.
"System.Configuration.ConfigurationManager.ConnectionStrings' threw an exception of type 'System.Web.HttpException"
I am using asp.net mvc 1.0
Please help.
Thanks in advance.
The problem was coming because of an ajax request which was having one of the route data parameter with space eg. www.domain.com/account/index/%20routedata. In this case, the firebug was showing 404 not found error while as debugging was enabled on the machine, it was throwing the above mentioned exception.
You need to use WebConfigurationManager and not ConfigurationManager in a web project.
I enabled tracing in IIS7.
I set those properties to true in the ASP tab of the IIS management tool:
appAllowClientDebug,
appAllowDebugging,
errorsToNTLog,
scriptErrorSentToBrowser;
To test it, I wrote a small classic ASP test page in wich I voluntary include a bug (bad activeX name).
My asp test page is rendered until the bug line is reached. The rest of the page is not rendered. I was expecting a 500 error code, but code is always 200. There is no error file in the FailedReqLogFiles folder.
Any idea someone?
OK, i think the issue is actually with Enable Server Side Debugging. You may have it enabled, but you should disable it instead.
The server thinks it should start debugging and tries to fire up a debugger, and then doesn't find one and just gives up! I'm sure this never happened prior to IIS7.
Glood Morning,
This problem was slowing our development significantly, because sql server errors were not displayed on the browser. Our Application Service Provider tried some settings, but couldn't get it to work. They sent me the settings and I accidentally did just two at once and our problem was fixed. They told me that asp was giving return code 200 instead of the error code.
Here is what worked for us:
The combination of "Send to Browser = True" and "Enable Server Side Debugging" = False" works.
I hope that helps others.
Tom Armstrong
Look at this and see if this is stopping you from getting the 500 error. Also, If the bug is handled through an exception handler in the activeX then you might not be seeing an error on the asp response.
http://classicasp.aspfaq.com/general/why-do-i-get-a-500-internal-server-error-for-all-asp-errors.html
200 OK is a Standard response for successful HTTP requests. The status code indicates that the client's request was successfully received, understood, and accepted.
We had this same IIS7 error happening. It was not returning any kind of error. There was no error message on the screen and no 500. The page just stopped rendering.
Is that what you are seeing? I can't remember what it was unfortunately, i think it was like something was handling the error. (If this is what you are seeing, i will keep trying to remember!)
I don't think this is it but it might be: go into Error Pages > Edit Feature Settings (hidden on the right panel) and select Detailed Error? That setting is also required and you didn't mention it.