Umbraco 3.0.6 site for a customer of mine, and it has been running fine for a couple of years. Last week they reported yellow pages of death on clicking nodes in the content tree. Restart of IIS solved it. Then it started to happen about everysecond day and now two days in a row.
IIS restart does it every time but that is no solution. Everything works fine except getting to edit nodes. Except 1 node type. Redirect nodes use a template with url redirect. This node type opens normally for editing. Document type has a couple of tabs and properties so I don't really understand what makes it different.
This is really annoying. Pretty nondescript error shown below. Anyone have a clue to the reason for this?
[quote]Server Error in '/' Application.
--------------------------------------------------------------------------------
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
umbraco.controls.ContentControl.addControlNew(Property p, TabPage tp, String Caption) +54
umbraco.controls.ContentControl..ctor(Content c, publishModes CanPublish, String Id) +714
umbraco.cms.presentation.editContent.OnInit(EventArgs e) +353
System.Web.UI.Control.InitRecursive(Control namingContainer) +333
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +378
--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082 [/quote]
Firstly is the website running in its own app pool (IIS reset fixing the problem seems to indicate website is not in own app pool)? Secondly on the doc type are you using any custom built data types? Thirdly on a problem document try doing roll back see if that fixes the issue.
I have had this with a site where I had custom datatype and periodically my document would error. However I would then roll back to a previous version and it would be fine.
Thanks for quick response, Ismail. I have no access to the webserver except FTP, but I'm told the site runs in its own pool. There are a couple of doc types with customer data types, the lates was added medio January this year. Those are only used on a handfull of the hundreds of nodes on the site.
I had my ISP restart IIS again, since the customer is not happy with the situation. But I'll keep close watch this weekend and try out the rollback option when it happens again.
Do you have an explanation for the behaviour - if it has to do with data types? I'm no web server expert and was thinking along the lines of caching problems, simply because the behaviour indicated some sort of resource congestion (wrong word?). But what do I know :-#
Its got to be the custom datatype. I would try and get a back up of the website and restore it locally on your pc/laptop. Determine from the node that is erroring which custom data type it is using. Then get source for that datatype open source in visual studio add break point somewhere suitable then do an attach to process. Then hit the document that fails and see if you can determine via debugger what is going on.
I think you are right with caching issue its erroring and that is then in the cache and each time you come back to the node you get error from the object in cache. Rolling back will also fix the problem becuase you are not getting object then from cache. Anyhow try the debug to try and determine what is causing the issue.
I don't think rollback is my solution. There are no custom datatypes newer than January and the yellow death messages started popping up in the middle of March, suddenly and almost every day.
I touch the web.config every so often in order to refresh cache. That always help. But the site is updated on a daily basis, so this is a hassle.
There have been troublesome datatypes in the past, connected to an old custom dll. The dll is deleted. The datatypes still exist in the datatype table, but I'm unable to find any references to them. It would be in old versions of property data though, so it's not easy to locate. I don't dare to delete the datatypes in case they still are referenced somewhere. I imagine that would only worsen the situation? Instead I've changed they're oject type to that of a regular integer.
Regarding Ismails last post. Only 1 in 100 nodes do not get the error, and only 1 in 100 of the nodes that do fail are connected to custom datatypes. We have tried to debug locally but didn't really catch anything. I suspect we would see other things in the live web environment, but I really don't know what to think...
null object error in Content Tree - need help!
Umbraco 3.0.6 site for a customer of mine, and it has been running fine for a couple of years. Last week they reported yellow pages of death on clicking nodes in the content tree. Restart of IIS solved it. Then it started to happen about everysecond day and now two days in a row.
IIS restart does it every time but that is no solution. Everything works fine except getting to edit nodes. Except 1 node type. Redirect nodes use a template with url redirect. This node type opens normally for editing. Document type has a couple of tabs and properties so I don't really understand what makes it different.
This is really annoying. Pretty nondescript error shown below. Anyone have a clue to the reason for this?
[quote]Server Error in '/' Application.
--------------------------------------------------------------------------------
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[NullReferenceException: Object reference not set to an instance of an object.]
umbraco.controls.ContentControl.addControlNew(Property p, TabPage tp, String Caption) +54
umbraco.controls.ContentControl..ctor(Content c, publishModes CanPublish, String Id) +714
umbraco.cms.presentation.editContent.OnInit(EventArgs e) +353
System.Web.UI.Control.InitRecursive(Control namingContainer) +333
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +378
--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082 [/quote]
siw,
Firstly is the website running in its own app pool (IIS reset fixing the problem seems to indicate website is not in own app pool)? Secondly on the doc type are you using any custom built data types? Thirdly on a problem document try doing roll back see if that fixes the issue.
I have had this with a site where I had custom datatype and periodically my document would error. However I would then roll back to a previous version and it would be fine.
Regards
Ismail
Thanks for quick response, Ismail. I have no access to the webserver except FTP, but I'm told the site runs in its own pool. There are a couple of doc types with customer data types, the lates was added medio January this year. Those are only used on a handfull of the hundreds of nodes on the site.
I had my ISP restart IIS again, since the customer is not happy with the situation. But I'll keep close watch this weekend and try out the rollback option when it happens again.
Do you have an explanation for the behaviour - if it has to do with data types? I'm no web server expert and was thinking along the lines of caching problems, simply because the behaviour indicated some sort of resource congestion (wrong word?). But what do I know :-#
siw,
Its got to be the custom datatype. I would try and get a back up of the website and restore it locally on your pc/laptop. Determine from the node that is erroring which custom data type it is using. Then get source for that datatype open source in visual studio add break point somewhere suitable then do an attach to process. Then hit the document that fails and see if you can determine via debugger what is going on.
I think you are right with caching issue its erroring and that is then in the cache and each time you come back to the node you get error from the object in cache. Rolling back will also fix the problem becuase you are not getting object then from cache. Anyhow try the debug to try and determine what is causing the issue.
Regards
Ismail
I don't think rollback is my solution. There are no custom datatypes newer than January and the yellow death messages started popping up in the middle of March, suddenly and almost every day.
I touch the web.config every so often in order to refresh cache. That always help. But the site is updated on a daily basis, so this is a hassle.
There have been troublesome datatypes in the past, connected to an old custom dll. The dll is deleted. The datatypes still exist in the datatype table, but I'm unable to find any references to them. It would be in old versions of property data though, so it's not easy to locate. I don't dare to delete the datatypes in case they still are referenced somewhere. I imagine that would only worsen the situation? Instead I've changed they're oject type to that of a regular integer.
I'm at a loss here.
Regarding Ismails last post. Only 1 in 100 nodes do not get the error, and only 1 in 100 of the nodes that do fail are connected to custom datatypes. We have tried to debug locally but didn't really catch anything. I suspect we would see other things in the live web environment, but I really don't know what to think...
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.