Hello,

i have the problem that my ULS log is flooded with the following messages:

• 10/25/2013 09:01:03.10    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_0_Portal_Content)\Transactions Completed. instanceHandle: 3.  
  
• 10/25/2013 09:01:03.10    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_0_Portal_Content)\Transactions In Progress. instanceHandle: 3.  
  
• 10/25/2013 09:01:03.10    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_0_Portal_Content)\Transactions in filters. instanceHandle: 3.    
  
• 10/25/2013 09:01:03.10    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_0_Portal_Content)\Transactions Started. instanceHandle: 3.    
  
• 10/25/2013 09:01:03.10    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_0_Portal_Content)\Transactions Delayed. instanceHandle: 3.    
  
• 10/25/2013 09:01:03.11    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Content Plugin - SharePointServerSearch(7f5f5ba0-1d59-4e20-aad6-e1a4fdc96b35-crawl-0 -Regular Crawl)\Items Ready. instanceHandle: 4.    
  
• 10/25/2013 09:01:03.11    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Content Plugin - SharePointServerSearch(7f5f5ba0-1d59-4e20-aad6-e1a4fdc96b35-crawl-0 -Continuous Crawl)\Items Ready. instanceHandle: 5.    
  
• 10/25/2013 09:01:03.11    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Content Plugin - SharePointServerSearch(7f5f5ba0-1d59-4e20-aad6-e1a4fdc96b35-crawl-0 -Regular Crawl)\Items Submitted. instanceHandle: 4.    
  
• 10/25/2013 09:01:03.11    mssearch.exe (0x07B4)    0x0A54    SharePoint Server    Unified Logging Service    9saa    Unexpected    OpenQuery Failed with status ID: 0xc0000bb8. QueryPath: \Search Gatherer Content Plugin - SharePointServerSearch(7f5f5ba0-1d59-4e20-aad6-e1a4fdc96b35-crawl-0 -Continuous Crawl)\Items Submitted. instanceHandle: 5.    
  

I'm getting around 10 to 50 events per second. Despite that the search seems to work fine.

Any advise how to solve this issue is highly appreciated!

Regards 

Daniel

• Edited by Daniel Stölzner Friday, October 25, 2013 2:59 AM

I'm having this problem as well! If I manage to figure it out, I'll post my solution

Alright, so here are the steps I took to get those errors from appearing: 

Check to see if the WSS_UsageApplication (or Usage and Health Data Collection Service) Proxy is started.

If it's stopped (which was my problem) follow the steps below..

1. Open up the SharePoint Management Shell and Run as Administrator

2. Run this code

$sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq Usage and Health Data Collection Proxy}
$sap.Provision()

3. Run the iisreset command - can be done in the same SharePoint Management Shell

4. Nagivate to your Search Service Application from Central Administration.

a. On the left, click on Index Reset and click Reset Now (not recommended during high volume usage hours)

OR

b. Click on Content Sources and click Start All Crawls

This'll give ULS a nice kick ;)

5. Check the logs to ensure the error is gone.

Hope this worked for you!

Reference: http://tristanwatkins.com/fixing-the-usage-and-health-data-collection-sa/

• Proposed as answer by MigratingCub1 Monday, October 28, 2013 4:07 PM
• Edited by MigratingCub1 Monday, October 28, 2013 4:08 PM added reference

Hi MigratingCub1,

this solution didn't do for me. My WSS_UsageApplication was up and running. Yet,  I did the steps you proposed but the messages still appear.I think i'll have to look further for a solution. At least there are no bad side effects as far as I can tell.

But thanks nonetheless (:

Daniel

Daniel,

I apologize for that. Soon after I wrote my response the logs began filling with the same error. I've yet to figure it out, but it's my #1 priority at the moment.

There's not much documentation I can find on this particular issue unfortunately.

As soon as I REALLY figure this out I'll post what I did! :)

Daniel,

After four days of tearing apart the error logs and searching to the ends of the internet for answers, I was finally able to resolve the issue.

Your system is most likely a lot different than mine, so I advise you to proceed with caution and always, always, always backup your data before you any reconfiguration.

I found that my problem was in the configuration of the indices.  Assuming this was something with permissions, I deleted and recreated the Search Service Application using an elevated PowerShell.

I used the script that can be found here: http://melcher.it/2012/07/sharepoint-2013-create-a-search-service-application-and-topology-with-powershell/ However, after the Service was created, the errors immediately appeared in the logs. I knew then it was definitely something with the initial configuration.

Taking a few steps back, I ran the following code

Get-SPServiceApplicationProxy

It returned the default application proxy list, which contained two invalid Search Service Application Proxies (leftover from previous configurations). 

Welp, better just start with an absolutely fresh configuration of it...

Here's what I did that resolved it...

1. Completely removed the Search Service Application by using the following documentation

- Remove SSA association with web apps http://technet.microsoft.com/en-us/library/ee704550.aspx

- Delete the SSA http://technet.microsoft.com/en-us/library/ee704553.aspx#ProcWPS

- Verify any traces are gone:

#The following command shouldn't give back any Search Service Application references...if it does,
#it hasn't been removed.
Get-SPServiceApplication 
#Now for the proxies...
Get-SPServiceApplicationProxy
Remove-SPServiceApplicationProxy -Identity <GUID of any Search Service Application returned>

I had two proxies that I had to remove.

2. On the server that will be hosting the index directory, verify your Default Content Access Account (mine was SP_Crawl) and your OSEARCH15 User Account (SP_Search in my case) are in the local administrator's group.

3. Run Windows PowerShell (or ISE version) as an administrator and run the code found here: http://melcher.it/2012/07/sharepoint-2013-create-a-search-service-application-and-topology-with-powershell/ 

(after setting the variables to what you need them to be. NOTE:  The variable $SearchAppPoolAccountName should be set to your Default Content Access Account)

The code will throw an error when the line $InitialSearchTopology.Synchronize() is run, but it can be ignored.

4. At this point, everything was working better for me than it previously had. The logs actually looked quite pretty (after staring at exceptions for so long I was so happy to see real things happening).

If you successfully got to this point without the errors reappearing, perform a full crawl to complete the setup.

That's it! I truly hoped this worked for you as this is the most frustrating issue I've dealt with in the SharePoint 2013 environment.

• Proposed as answer by MigratingCub1 Friday, November 01, 2013 7:22 PM
• Marked as answer by JasonGuoMicrosoft contingent staff, Moderator Thursday, November 07, 2013 12:34 PM

MigratingCub1's answer worked for me. Other blogs and posts talk about adding the search service/crawl account to the local Performance Monitor Users group which didn't work in my case.

I didn't use the scripts posted above, rather my own set. What I did differently this time is I followed step 2: Make the search service and crawl account local administrators on the server(s) with the index component(s).

This is similar to making the farm account, c2wts, and distributed cache service accounts local administrators when configuring the farm and these components. This suggests to me then that the search and crawl accounts need to be local administrators during configuration so they can go setup whatever permissions they need.

Unfortunately, this did not work for me. I'm still getting the errors. It's baffling the hell out of me and driving me to drink.