This is a fairly common and non-descriptive error that continues to surface more and more as the SharePoint developer community continues to grow. Surprisingly, I’ve found very little information in the web regarding what I believe to the most common cause and solution (hence this blog post).
Many things can trigger this error, and as you might expect by the description the error is security/permissions related. I’ve seen it most often, when browsing the Site Features and Site Collection Feature pages… but it has been known to take down a whole site; although mostly (and luckily) in dev environments.
So why do I keep referring back to development? And more importantly, what is this “most common” cause/solution? Its mostly tied to “drag and drop”; when you drag and drop files, permissions usually go with them (albeit there are a few exceptions.) With development rarely taking place directly in the 12 hive features, or layouts folder; its shouldn’t be surprising to see developers (and administrators alike) deploying and often testing changes to features by dragging and dropping files from their Desktop, My Documents, or project folders. Naturally this approach doesn’t follow best practices, but I wont deny having made the mistake while testing a quick change to a feature or elements xml file in a development environment. All updates to production environments should be done via WSPs.
So how do you solve the problem? Finding the culprit shouldn’t be too difficult, think of any items that have been recently deployed/updated. Cant think of any, search for any recently updated files of folders. If you do think of or find any; check the permissions and make any required modifications; also consider redeploying them via a WSP.
Have you ever noticed your WFE server crawling, and then ran Task Manager to find the Memory Usage of some of your w3wp.exe process through the roof. You need to know which process is tied to which application pool to begin troubleshooting. How do you get this information? OK, so this is nothing new, and definitely not specific to SharePoint. But it does come in handy, and I never seem to remember exactly how:
1. From Task Manager, select View > Select Columns
2. Put a check mark next to “PID (Process Identifier)” and click “OK”
3. Open the command prompt
4. Run the following command:
The above should result in an output similar to the following:
Notice how each w3wp process is tied to a specific application pool. If you’ve properly labeled your Application Pools and are not using the same Application Pool for all of your IIS sites, this should give you a good place to start looking for problems. If responsiveness is severely hampered you may choose to recycle the the offending Application Pool without having to do an IIS Reset which would impact all of your other sites.