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...
Related
Running Lucee server 5.2.1.9 (hosted at Vivio), and I'm unable to get it to show any run-time errors.
I have debugging enabled
I have enabled all debug info types
I've set a debug template (for all IPs); currently set to "Classic", but I've tried "Comment" and "Modern" as well.
When an error occurs, I get an empty page. If a debug template set, I get dumps of all the appropriate scopes and DB activity, as well as execution times... but no error message/details or stack trace.
Is there a setting I'm missing?
How do I insure Lucee displays my run-time errors during development?
I'm not sure if you every figured this out (kind of a necro). If you are in Dev disect your application.cfc. I had an issue in my onRequest section. Someone threw a cftry around the target page include. This ran Lucee into the catch and it showed a blank page.
If that doesn't help try removing your OnError function in there. There might be something in there that is trying to serve up a friendly error page which could prevent error output.
Also, look in Lucee server administrator and check that it is pointing to the native error.cfm that comes with the Lucee package.
I have to add it even though it isn't likely the cause. Search your code for any abort. It could be someone was testing a routine and was aborting to see how far Lucee was processing.
Hope these suggestions help.
We have some logic for displaying custom error pages in our ASP.NET application through overriding Page.OnError. Now, when an error occurs within that error handling routine I can redirect somewhere else using the in web.config.
This works for most errors. Yet, I cannot find how to display a custom error page (or anything at all!) when getting e.g. a StackOverflowException. Obviously I cannot do any more processing insode ASP in such a case as practically anything will result in some allocation on the stack. The same is probably true for OutOfMemory, though I have not found any sensible way to test this. Is there any possibility I could still display something (possibly static) to the user, e.g. directly from IIS instead from ASP?
When I purposefully throw a php error from within embedded php code in the php filter module, Drupal displays the message The website encountered an unexpected error. Please try again later.
We like to send users with unanticipated programmer errors to an error handling page so that they don't land on a dead error page without us getting notified, so I'm trying to find out how to intercept this in Drupal. I've tried searching within Drupal for where this error string gets outputted, with no luck.
How exactly does Drupal handle errors occurring within embedded php code, or more directly: how can I make it redirect to another page or catch the error in another way?
Thanks
That specific error comes as a result of Drupal explicitly setting the PHP exception handler to a custom function (done in _drupal_bootstrap_configuration()).
The exception handler itself is _drupal_exception_handler(), which invokes _drupal_log_error(), and that's where the error page is generated.
I've never tried it, but I reckon you'd get away with implementing hook_boot() and using set_exception_handler() to provide your own implementation of the core Drupal functions to theme that error page differently.
It might seem a bit of a long way round but since _drupal_error_log() doesn't invoke any hooks (it probably happens too early on for that anyway) I can't see any other way to do it without editing the core files.
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 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