Unexpected errors from search in SharePoint

Today I had some issues with my SharePoint installation. So I had a look at the SharePoint ULS logs. Quite  a few Unexpected errors that can be ignored:

DisplayAuthorEvaluator : (IStringField)aliasField == null

This error is generated when search tries to go through an old format (.doc) word file. Search is trying to read the file assuming that it is a new Word format file and then oops it’s a different format file. Maybe it was too difficult to put an additional if (fileextension = .doc) into the code. 

First I got a Medium level message ( so no problem!)

DocParser – A parsing failure caused the partial processing of the document. The original error code was 300000 and the error message was ‘Error parsing document ‘https:/ /portal/subsite/subsite/subsite/Pages/My
Page.aspx’. Sandbox worker pool is closed.’.

Then after a while the following Warning will appear:

w3wp.exe: Query processing component ‘net.tcp://servername/937365/QueryProcessingComponent1/ImsQueryInternal’ changes its status to ‘Failed’.

Followed by this warning:

w3wp.exe: All query processing components are in ‘Failed’ status.

This sounds a bit more worrying we’re running out of something and all my search related web parts have stopped working.

In my case a server reboot solved the problem, but if this is a ‘running out of’ issue then I would expect that this might come back one day.

Solution

It took a while but now I’ve found the solution. In my case there was a Nintex workflow (but I believe this could also be something else causing the same problem) running state machine workflows. Inside one of the states sometimes there wouldn’t be a state change. resulting in the state machine circling through the same state forever. It isn’t easy to identify as the workflow history looks healthy at first sight. At least there isn’t an error. When there are a few more instances of these kind of badly configured workflows you will end up with a server getting stressed and then the search gives the above errors. This can even happen when you’re running in multiple server environments. In my case search has its own set of servers doing nothing else than search.

Fixing the workflows and ensuring that all states always end in a state change fixed my problem with search.

Pieter Veenstra

Is your business still running on paper trails, sprawling Excel files, or ageing Access databases? There's a better way — and I can show you exactly what it looks like. I'm the Technical Director of Vantage 365, a Microsoft solutions consultancy working with clients across the UK, the Netherlands, and worldwide. For over 30 years I've been turning messy, manual business processes into clean, automated systems that save time, reduce errors, and give teams the visibility they need to make better decisions. SharePains is not just any blog run by a Microsoft MVP. Have you ever used Try-Catch in Power Automate? The original post about Try-Catch in Power Automate can still be found on this site, https://sharepains.com/2018/02/07/try-catch-finally-in-power-automate-flow/ Or have you ever used the Pieter’s method to avoid variables and speed up your flows? https://sharepains.com/2020/03/11/pieters-method-for-advanced-in-flows/ You can contact me using contact@sharepains.com