In this post, I’ll explain a problem/”solution” that I recently went through with a customer in their SharePoint 2010
environment.

The Problem

The customer was experiencing an issue when trying to navigate to a particular list.  For the record, this was a list that
was created from the built-in "Links” list template.  The list had been added to the site’s home page as a web part and
the web part itself worked fine!  However, when clicking on the list in navigation or the title of the web part (same thing),
we’d received the ever-classic “An unexpected error has occurred.”  A similar message would occur when trying to
expand the site node in the “Manage Content and Structure” tool.

This was only happening to one list in one site; all other lists in all other sites were working fine.  After reviewing
SharePoint’s log files…

DelegateControl: Exception thrown while adding control 'ASP._controltemplates_metadatanavtree_ascx'
: Value does not fall within the expected range.

CreatePageFromUrlNoUpperCase failed with ArgumentException. Url = '/SomeUrlWasHere'.

Leaving Monitored Scope (CachedObjectFactory: Caching Page at: /SomeUrlWasHere).

CreatePageFromUrlNoUpperCase failed with ArgumentException. Url = '/SomeUrlWasHere'.

Unable to get a cached list with id 'LIST-GUID-WAS-HERE' from web '/SomeUrlWasHere'

Unexpected    ...t System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint,
  Boolean includeStagesAfterAsyncPoint)    

…, I was able to find the list’s GUID and discovered that I was able to get to the list settings page for this list (http://SiteUrl/_layouts/listedit.aspx?list=GUID).  This told me that the list and its data were still in place and available. 
So what’s with the error messages?  Is there a problem with a view?  Is there a problem with a column; did someone
delete one?  What about those pesky calculated columns or even workflows?  These are the thoughts that ran through
my mind and I looked into all of them, to no avail.  During our troubleshooting, we also came across a couple of links
in the forums that helped guide us a little bit: 

http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/e2448468-837c-4923-a5f2-0f1b82f516fb http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/f25abc84-3e0b-466f-8d1c-885cf04b8c51

After looking into everything that I thought was obvious, it came down to architecture.  The list was being displayed on the home page of the top-level site even though the list itself was physically located in a subsite.

The Solution

1. I saved the list as a template and made sure to include the data.  Remember that we did have access to the list settings page, so this was completely possible. 

2. I deleted the list’s web part from the web part gallery.

3. I deleted the web part on the home page of the top-level site that was displaying the list’s data.

4. I recreated the list in the top-level site (from the template in the list template gallery that resulted from step 1 above).

5. I added the web part back to the home page of the top-level site (now the list and the page are in the same site).

6. I deleted the list template from the list template gallery.  This was not necessary and was only done to keep the list template gallery clean.

7. After the customer and I verified that the list and the “Manage Content and Structure” pages were all working and back to normal, I then deleted the list from the subsite.  This was deemed appropriate after discussing the customer’s needs.

It turned out that there was no particular reason for having the list exist in the subsite in the first place.  The customer just needed a list and put it somewhere.  The customer was not aware of the implications of this; the idea that SharePoint’s hierarchical structure can affect how data can be displayed and effectively organized.

To me, this is just one more example of how some early planning can really go a long way to save you some grief in the long run.