I'm having a few issues with my site where certain pieces of script were failing within the application that involved checks on things such as the cgi.script_name. I've managed to trace this back to an issue which is caused by my web.config file. I ran a cfdump inside a cfsavecontent file within the application.cfm and then wrote the file into my stucture and loaded up the HTML page.
I found that at the time the dump was performed, the cgi.script_name value was /errorpages/404.cfm yet the page loaded normally and the cgi.script_name reads /cart.cfm? I'm very confused. I've currently disabled ANY error setup and it works fine, but within Error Pages on IIS7, i had originally set up the 404 to execute /errorpages/404.cfm and under the error feature settings to throw a custom error page when it encountered an error. Does anybody know where the hell i am going wrong?
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.
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 am currently migrating from Tridion R5.3 to Tridion 2011. I am having issues with serving some pages through the presentation server. For reference all of my web pages are classic ASP and I am running them on IIS7.5.
I have have a page located at http://www.example.com/widget/index.asp. When I first access the page I get a The page cannot be displayed because an internal server error has occurred., if I then refresh the page it loads fine, if I refresh the page a third time it comes up with the error. The page works every other request.
I have enabled Failed Request Tracing on my website and I am getting the error
ASP_LOG_ERROR
LineNumber: 87
ErrorCode: 800706be
Description:
Note there is no description.
The code being called is
85: Dim objTranslationPageLink
86: Set objTranslationPageLink = Server.createObject("cd_link.PageLink")
87: strTranslatedPageLink = objTranslationPageLink.GetLinkAsString("tcm:0-12-1", "tcm:12-123456-64", "", "", "TranslationFound", False)
88: Set objTranslationPageLink = Nothing
It looks like there is no problems creating the cd_link.PageLink object, just when calling the GetLinkAsString(...) function.
I use the cd_link.PageLink object in lot of other pages with no problems but it seems with pages that use this specific piece of code experience the problems.
I was thinking it could be something to do with caching pages however I turned off caching of ASP pages (IIS7 > ASP > Services > Caching Properties) and still had the problem.
Any ideas?
edit1
The code worked fine on Windows Server 2003 IIS6. I am trying to make it work on Windows Server 2008 IIS7.
edit2
It appears that the page is creating a lot of cd_link.ComponentLink and cd_link.PageLink objects. I have a test page in which I create 10 ComponentLink objects I get the error (every other page) but if I reduce this to 5 ComponentLink objects it works every time.
edit3
My cd_core.xxxx.xx.xx.log has the following errors
2012-11-02 11:55:34,027 ERROR XMLConfigurationReader - Error while validating file 'cd_link_conf.xml' with schema 'schemas/cd_link_conf.xsd'. cvc-complex-type.3.2.2: Attribute 'DefaultRootLocation' is not allowed to appear in element 'Publications'.
edit4
Thanks for bearing with me. The problem I was having with my cd_link_config is fixed and doesn't appear to have been be related. I now have no errors in my any of the four log files (cd_core, cd_deployer, cd_monitor, cd_transport) but the original issue persists.
Looks like you are running the CD Link windows service and the following hotfix might help to resolve your issue. I have not tried this hotfix but the description says Page link fails on second attempt of accessing the page, so that means it might work sproadically depending on the logger memory resources.
Anyway worth looking at this hotfix : CD_2011.1.0.78355
Description: The Linking windows service was not correctly cleaning up a logger memory resource on certain windows platforms
It is a long time since I worked with Classic ASP and SDL Tridion, but double check the following
Is the linking service running on the server?
Check your cd_licenses.xml file is in place
Validate that you have a correct cd_link_conf.xml and cd_storage_conf.xml (these changed from 5.3 I believe)
Look in the Application and Tridion event logs for clues
The Tridion linking log files
That error code seems to imply that the Linking DLL is not registered properly.
That is all I can think of for now.
I didn't realise that 2011 actually schema-validates the config files, but in any case, now the error is clear. I'd suggest doing the validation yourself in an XML editor such as XML Spy. That should point out exactly what's wrong with the configuration file.
To routinely check your configurations, you may find it interesting to script it as described here.
I've got a ASP.NET web application which contains the Winnovative HTML to PDF Converter.
This has been running for over a year successfully generating PDFs
However, this is no longer working, and the error being returned is:
Could not render the url. Could not get image from url.Navigation timeout..
I've checked the Winnovative FAQ and they suggest adding a NavigationTimeout to the instance of the PdfConverter. I've added the following:
PdfConverter.NavigationTimeout = 500
However, this has not fixed the error. Furthermore, the page being converted only takes a fraction of a second to load when loading directly in the browser, so I don't believe its a performance issue with the page being rendered.
Has anyone experienced this problem before? Are there any known solutions/causes for this?
In the end I found out this error was occuring because we were trying to request a PDF from a HTTPS file.
I weren't able to solve why though.
Please see this question if you have an answer:
Generating PDF from HTTPS causes error
If anyone else gets this error: In our case, running on IIS 8.5, changing the application pool from ApplicationPoolIdentity to Network Service fixed it. So it seems it is a folder permission problem. Network service isn't ideal and really the actual folder permissions should be set.
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.