Search Returns An Error: Object reference not set to an instance of an object
This post is going to talk about how to resolve the 'Object Reference not set to an instance of an object' message you may run into when you perform a search from a SharePoint site. This is something you may run into most often when setting up a small lab environment, and I'll explain why below, as I go through resolving the issue.
Background
One of the greatest things about SharePoint, is that even after years of using the product, it will continue to find new ways to break that you've never seen before. And this is what happened to me. I had just built a new SharePoint 2010 farm in order to test some scripts that I had been working on. One of my customers was setting up PDF search in their SharePoint 2010 environment and was having an issue getting PDF documents to return in their search results. My first instinct was to send over this document:
How to install and configure Adobe PDF iFilter 9 for SharePoint 2010
In response they indicated that they had been following this documentation and that it had in fact not worked. This documentation has always been solid for me, and has always done the trick – so I had to do some testing to make sure nothing changed, and that my guidance was still valid.
Issue
I had just created my new Search Service Application a few days prior, and I hadn't even performed a full crawl of the index yet. I followed the documentation, made my PDF icon appear and everything, uploaded some sample PDF documents and then kicked off a full crawl of my SharePoint sites content source. Everything looked great, and I had over 300 items in my index. Everything looked great until I did a search. Once I performed a search, I was greeted with an "Object reference not set to an instance of an object" message, and a correlation ID. Using Merge-SPLogFile, I passed in the correlation ID and got the following output (cleaned it up a little so that it's somewhat readable):
Videntityinfo::isFreshToken reported failure.
CoreResultsWebPart::OnInit: Exception initializing: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e)
Internal server error exception: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e) System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.SetPropertiesOnQueryReader() at Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart.OnInit(EventArgs e)
Watson bucket parameters: SharePoint Server 2010, ULSException14, 06175311 "sharepoint server search", 0e00178d "14.0.6029.0", 17853a8f "microsoft.office.server.search", 0e0017ee "14.0.6126.0", 5021bda3 "tue aug 07 18:15:15 2012", 000032a1 "000032a1", 0000002d "0000002d", 4a6d3421 "nullreferenceexception", 67316a39 "g1j9" ff503ece-c286-454b-a5f2-998ca970808f
What does this mean?
So here's what I understood from this: My Core Results Web Part needed access to something, and it wasn't available or did not exist. I just had no idea what could have been missing. I've set SharePoint search up hundreds of times. I walked through my configuration, made sure that all of the services were started, and made sure that everything looked like it was properly configured.
That Eureka moment
Looking at my configuration, and then mentally walking through the process, it had sort of donned on me. I had two servers in my farm. One for all web functions, and one for all application functions. My Search query and site setting service, and my SharePoint Enterprise Search Service Application Proxy both existed on the application server AND I was using my app server as my browser. I had forgotten to follow this document on my application server:
For anyone who is not familiar with this document – this is the famous 'DisableLoopbackCheck' document. Whenever my query web part tried to access the proxy (hosted on the same server the request was coming from), it was being denied access and couldn't determine where the query component was even hosted.
The solution
After figuring this much out, all I had to do was run through the documentation create the DisableLoopbackCheck registry key on my application server. Once I created this key and rebooted the server, the problem went away. This allowed me to validate that the documentation for configuring PDF indexing in SharePoint 2010 was still valid and worked perfectly.
Feedback
As always, any feedback is always welcome.
You can also follow me on Twitter:
Comments
- Anonymous
November 13, 2012
The comment has been removed - Anonymous
November 13, 2012
That's a good point Bob. If anybody is doing this for a production environment, and especially something externally routable, they should always take all precautions necessary to ensure that the actions taken have the least level of impact to the security of the environment. The last article that I mention is in fact that same KB article, and very clearly states that method 2 is preferred - hopefully everybody catches that AND reads your blog (especially now).