Jump to content
Welcome to our new Citrix community!
  • 0

Windows Search Corruption - Windows 10x1709


Craig Heading

Question

Wondering if others are seeing windows search corruption in windows 10x1709.

 

If I add a new version to the OS layer, it sometimes (but not always) shows errors in the event log showing the search service has detected corrupt files in the index. I rebuild the index, reboot the errors are gone it works well, finalise. Add a new version or a new layer based on this layer, it sometimes (but not always) shows this corruption. Furthermore, after detecting the corruption, it rebuilds the index but is unable to write to the c:\programdata folder to fix it.

 

The below events came from a desktop using persistent user layer.

 

 

The search service has detected corrupted data files in the index {id=4810 - onecoreuap\base\appmodel\search\search\ytrip\common\util\jetutil.cpp (249)}. The service will attempt to automatically correct this problem by rebuilding the index.

The Windows Search Service is being stopped because there is a problem with the indexer: The catalog is corrupt.

The plug-in manager <Search.TripoliIndexer> cannot be initialized. - (HRESULT : 0x8e5e0713) (0x8e5e0713)
The plug-in in <Search.TripoliIndexer> cannot be initialized - The specified object cannot be found. Specify the name of an existing object.  (HRESULT : 0x80040d06) (0x80040d06)

The gatherer object cannot be initialized. The content index catalog is corrupt.  (HRESULT : 0xc0041801) (0xc0041801)
The search service has detected corrupted data files in the index {id=4400}. The service will attempt to automatically correct this problem by rebuilding the index.

The Windows Search Service is being stopped because there is a problem with the indexer: The catalog is corrupt.

Windows Search Service stopped normally.

The Windows Search Service is starting up and attempting to remove the old search index {Reason: Index Corruption}. 

The Windows Search Service has successfully removed the old search index. 

The Windows Search service is creating the new search index {Reason: Index Corruption}. 

The Windows Search Service has successfully created the new search index. 
SearchIndexer (8872,D,0) Windows: An attempt to move the file "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\edb.jtx" to "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\edb00001.jtx" failed with system error 3 (0x00000003): "The system cannot find the path specified. ".  The move file operation will fail with error -1023 (0xfffffc01).

SearchIndexer (8872,D,0) Windows: Unable to create a new logfile because the database cannot write to the log drive. The drive may be read-only, out of disk space, misconfigured, or corrupted. Error -1023.

SearchIndexer (8872,D,0) Windows: The logfile sequence in "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\" has been halted due to a fatal error.  No further updates are possible for the databases that use this logfile sequence.  Please correct the problem and restart or restore from backup.

SearchIndexer (8872,D,0) Windows: Unable to rollback operation #2795 on database C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb. Error: -510. All future database updates will be rejected.

Link to comment

8 answers to this question

Recommended Posts

  • 1
On 09/07/2018 at 5:13 PM, andrew webber1709153696 said:

I am seeing this in a recent build with App Layering and Windows Server 2016. We have enabled the Search Service to support FSlogix O365 Containers. Has anyone got these errors resolved or can confirm if deleting the Data folder on all layers solves the issue?

 

Edited - I have just updated both the OS and Platform layer and made sure the Windows Search Service was disabled and stopped. I then deleted the Application folder where the .edb files and finalized the image. I created an image with just the OS and Platform layer and set a GPO to start the Search service. Same errors come up :(

 

Cheers

I resolved this issue by applying this registry key before shutting down the OS Layer:-

 

HKLM\Software\Microsoft\Windows Search SetupCompletedSuccessfully REG_DWORD 0

 

No errors at all with search after doing that

  • Like 1
Link to comment
  • 0

We are seeing similar errors on our 2016 App Layered Desktop Experience enabled server/s.

  • SearchIndexer (15928) Windows: Unable to create a new logfile because the database cannot write to the log drive. The drive may be read-only, out of disk space, misconfigured, or corrupted. Error -528.
  • SearchIndexer (15928) Windows: An attempt to move the file "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\edbtmp.jtx" to "C:\ProgramData\Microsoft\Search\Data\Applications\Windows\edb.jtx" failed with system error 2 (0x00000002): "The system cannot find the file specified. ". The move file operation will fail with error -1811 (0xfffff8ed).

We are getting these errors about every second and it is having an affect on the resources on the server.   We seem to be maxing out the CPU with 5 or 6 people on these servers (test) with 8 vCPU and 40GB Ram where on our 2008R2 boxes with the same specs can get over 20 per server and not max it out.

 

This seems to be our last major hurdle before we start rolling out 2016 to a wider audience.  Any tips to get this resolved would be appreciated.

Link to comment
  • 0

I am seeing this in a recent build with App Layering and Windows Server 2016. We have enabled the Search Service to support FSlogix O365 Containers. Has anyone got these errors resolved or can confirm if deleting the Data folder on all layers solves the issue?

 

Edited - I have just updated both the OS and Platform layer and made sure the Windows Search Service was disabled and stopped. I then deleted the Application folder where the .edb files and finalized the image. I created an image with just the OS and Platform layer and set a GPO to start the Search service. Same errors come up :(

 

Cheers

Link to comment
  • 0

Hi Guys,

 

i am have similar issues to this, just wondering if that registry key was the fix?

 

i have had a case open with Citrix for a very long time, and they still haven't been able to fix this.

 

we get these type of messages all the time

 

The Citrix Profile management could not mount search database 'S-1-5-21-3812149332-585470059-3488107514-2485' from 'C:\Users\Username\Appdata\Roaming\Citrix\Search\'.

  Error code: '0x80040d06': 

 

The application cannot be initialized.

Context: S-1-5-21-3812149332-585470059-3488107514-2485 Application

Details:
    The specified object cannot be found. Specify the name of an existing object.  (HRESULT : 0x80040d06) (0x80040d06)
 

The gatherer object cannot be initialized.

Context: S-1-5-21-3812149332-585470059-3488107514-2485 Application, SystemIndex Catalog

Details:
    The specified object cannot be found. Specify the name of an existing object.  (HRESULT : 0x80040d06) (0x80040d06)
 

The plug-in in <Search.TripoliIndexer> cannot be initialized.

Context: S-1-5-21-3812149332-585470059-3488107514-2485 Application, SystemIndex Catalog

Details:
    The specified object cannot be found. Specify the name of an existing object.  (HRESULT : 0x80040d06) (0x80040d06)
 

The plug-in manager <Search.TripoliIndexer> cannot be initialized.

Context: S-1-5-21-3812149332-585470059-3488107514-2485 Application

Details:
    (HRESULT : 0x8e5e04be) (0x8e5e04be)
 

anymore information on the process to fix this,

 

do i need to disable windows search in the OS Layer and Platform layer, then enable it after the image is deployed?

 

Thanks,


Cam

 

Link to comment
  • 0

We are also getting the exact same issue running CVAD 1906.1 on Windows 2016 servers with published app Outlook 2016 32-bit. Rebuilding the Windows Search Index on the VDA resolves the issue, but it shouldn't happen in the first place and we are worried it will reoccur unless we can find the cause. We have only just started to roll this out so we would very much like to know what is going on before we roll it out the our larger client base. 

 

We are using VHDX-based Outlook cache and Outlook search index on a per user bases in a UPM environment with Cached Exchange mode turned on.

Link to comment
  • 0
On 8/7/2019 at 6:59 AM, Michael Southwell said:

We are also getting the exact same issue running CVAD 1906.1 on Windows 2016 servers with published app Outlook 2016 32-bit. Rebuilding the Windows Search Index on the VDA resolves the issue, but it shouldn't happen in the first place and we are worried it will reoccur unless we can find the cause. We have only just started to roll this out so we would very much like to know what is going on before we roll it out the our larger client base. 

 

We are using VHDX-based Outlook cache and Outlook search index on a per user bases in a UPM environment with Cached Exchange mode turned on.

Did you find an solution to this? 

We have started to test this and we get corrupt search index often. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...