Hi Phil

Could you give a bit more information about how you did the upgrade? Did you follow the steps as described on the codeplex page? (copy over the /bin, /umbraco and /umbraco_client folder) - or did you copy over more files and folders?

Is it only webpages you can't access or is it also the umbraco backoffice?

/Jan

I have the same issue only on a website page, I didn't find what's different on that page. I works fine with ver 4.7.0

Jan,

I'll try to add to this myself because I just upgraded from version 4.7.1.1 to 4.7.2 and have the same issue.

In my case:

Affected page: Home or Default page only. All other pages work just fine from what I can tell. (default.aspx or default or slash only /)

Installation and Progression:

Errors during installation: Rewrite rules needed to be removed to run /install/default.aspx my system detected an invalid header content type but this was corrected by removing all rewrite rules. (could have been just one but it was faster. )

Upgraded: Bin, Umbraco, Umbraco_client files.

Replaced: (New to Old) /umbraco/config/UI.xml

Error:

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:

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an object.]
   umbraco.cms.businesslogic.macro.MacroModel..ctor(Macro m) +13
   umbraco.macro..ctor(String alias) +164
   umbraco.presentation.templateControls.Macro.CreateChildControls() +1285
   System.Web.UI.Control.EnsureChildControls() +102
   umbraco.presentation.templateControls.Macro.OnInit(EventArgs e) +34
   System.Web.UI.Control.InitRecursive(Control namingContainer) +140
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Control.InitRecursive(Control namingContainer) +311
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +480

Addtional:

My Notes:

Everything seemed to update and fall into place just fine.

I've recycled and restarted.

I have uploaded and cleared cache.

This is only associated with the home /slash page as if it were NULL it causes this error. The 301 redirects work the 404 page works as long as you have a character after the trailing slash in the domain it appears to work just fine.

Remove everything after the .com/ and this is the results.

Packages are as follows:

Koiak Standard Site
HTML5Video
Cultiv Search Engine SItemap
301 URL Tracker
MySnippets for TinyMCE
Desktop Media Uploader
Gecko Uploadify

From the backend I can preview all pages but the HOME page or DEFAULT page.

The issue is going to be something simple I know it. But if you can speed the troubleshooting along.

Murray

@Murray, the issue appears to be in the loading of a macro. Can you remove the macros from the page and add them back one at a time to find out which Macro is causing the problem?

@Tim

That was a good idea, seemed like the logical path to take.
I removed every macro like you suggested with no change.

I'm not seeing this issue on my Dev station with the build 4.7.2.

I guess this would be a good time to setup a fresh build on top of a good core.

If I see the issue show it's face later this week I'll publish the "Duh!" moment.

I'm sure it's one of my macro's or controls.

Thanks for the help.

Tim, Murray and Jan,

Sorry for the delay in getting back to this upgrade issue (out of town last week).  Anyway, I have downgraded to 4.7.1 and everything works fine again.  As soon as I upgrade to 4.7.2, I receive no errors, the Umbraco upgrade wizard goes through it's process and I have access to the Umbraco UI.  However I cannot load any pages without the dreaded error message described above by both Murray and I.  I upgraded using the exact process described in the PDF document.  I have my project hooked into VS2010 as I need access to code behind but this has not been a problem for any previous upgrades.  Running the debugger in VS2010 yields the same error (more or less).  Last week I also removed all macros and also the content pages attempting to load just the master.  Still get the error.  

Would be happy to share anything with you that could help.  I have seen other posts where the upgrade has given the same error.  My site is fairly busy with several packages...uCommerce as well.  But I've upgraded before without this issue.

I had this happen and it was due to a template with a macro in it that didn't exist. So check your templates for macros too and remove them to diagnose.

I got to this weird position by flipping the umbracoDbDSN in web.config to a different umbraco database that didn't have the macro that was in one of the templates.

Thanks Justin- Worked for me!

@Phil Looks like the solution if you can mark it as such ( if you find fixes the issue ;)

@Murray, worth a go! I had a similar issue after the 4.7.1 upgrade where some macro's were throwing the same error because the code for passing in page/session/cookie values into macros had been changed and wasn't checking for nulls like it had in earlier versions!

Thanks Justin! (Josh and Tim as well)  I'll certainly give this a try later today and barring any issues mark this one as solved.  Murray have you had a chance to try this?  It will be a few hours before I have a chance to work on this again.

@Phil, I just finished the upgrade and it works just fine. I'm not sure your issue is going to be the same but it might give you additional places to look.
@Tim, I wish I can say it was a Macro, but I can't. I removed every macro, html line, to the point of having a blank page. (Still errored only on homepage)
But, your direction was on track and did lead me to the fix which was to add the code back but into a new Homepage.Master page.

1. Renamed Homepage.Master to Homepage1.Master
2. Copied Homepage.Master from default package template (Koiak Standard Site)
3. Tested page, loaded fine.
4. Copied html, scripts, macro's and code from Homepage1.Master and pasted into new Homepage.Master
5. Refreshed and all is well. 
Update: Step 4 I started with only HTML code, Added Scripts then ended with Macros. Testing the pages after each change.

 I'm thinking this was a test for us new .Net people.
In any case, thank you all for the direction and that little short "Umbraco Debugging Made Easy" 2008 post. I did find the break point which pointed toward the Homepage.Master Template. (which was suspect from day one but not sure how to debug it.)

Why did this happened? Only the .Net Masters know.
As for me, it works and I'm good to go.

@Phil, Tocca a te, (Your turn) Don't be shy, that virtual cliff you asked me to walk off of wasn't so high after all. (Referencing your line, "have you had the a chance to try this?") Too funny. I tried 5 times before I finally got the results I needed. Try steps 1, 2, 3, 4 and tell me if 5 has a good feel)

Thanks again all, Tim, Jan, Phil, Justin.

 Update: 5-22-2012:

I just finished setting up a clone of the site but building from the 4.7.2 codeplex build.

Same results, same error. Reworking only macros corrected the issue and I was able to just copy over the templates.

I'm learning those macros are about as touchy as the old access macros.

I've logged this in CodePlex to be fixed asap hopefully.

http://umbraco.codeplex.com/workitem/30836

I had to remove this line from umbMaster.master (from a clean install with Simple starter kit) to make it work

 <umbraco:macro id="Macro1" alias="BlogRssFeedLink" runat="server"></umbraco:macro>

I had the same issue.

BlogRssFeedLink was the cause. There was no such macro.

I can confirm as per I think some of the other reports that the issue is to do with a reference in the template to a non-existent macro. I encountered this issue in an pgrade from > 4.5.2 > 4.7.1 and through a process of elimination tracked down the offending macro tag. Not sure if a YSOD is appropriate in this situation.

is working on a reply...