I was running both a SharePoint 2013 and a SharePoint 2016 standard edition installation with stock, out of the box setups. Seemingly randomly, and on the same day, both started generating Critical Event 6398 Errors once every hour that looked like the error below:
By the way, also check out part #2 of this solution to check out what to do next after this.
The Execute method of job definition Microsoft.Office.Server.UserProfiles.LMTRepopulationJob (ID ...) threw an exception. More information is included below. Unexpected exception in FeedCacheService.IsRepopulationNeeded: Connection to the server terminated,check if the cache host(s) is running .. (Correlation=...)
I was able to resolve these using the steps below. To summarize, what I did was first to:
- check that the Distributed Cache was in fact fine
- then to remove and re-instantiate the Distributed Cache
Step #1: Check that your Distributed Cache is up and running:
First open up your SharePoint Management Shell (don’t forget to right-click to run this as an administrator)
Once the command shell prompt appears, you can query the cache to make sure it is actually up and running. To do so, first enter:
Use-cachecluster
Then enter:
Get-cachehost
Hopefully you’ll see that the AppFabricCachingService is Up. What this means (as far as I can tell) is that you just need to remove and then re-add the cache service instance.
By the way, if you want to find out what local groups the caching service is running under, you can enter this command into the Management Shell (of course after you enter Use-cachecluster):
Get-CacheAllowedClientAccounts
This should return:
WSS_ADMIN_WPG WSS_WPG
Step #2: Remove and Re-Add the Distributed Cache Service Instance
You can do this simply by removing it in the SharePoint Management Shell using this commandlet:
Remove-SPDistributedCacheServiceInstance
Then give it a minute or so and start the cache service back up again using this commandlet:
Add-SPDistributedCacheServiceInstance
The steps above should do the trick. Here is a link to the TechNet article where you can find out more details: https://technet.microsoft.com/en-us/library/jj219613.aspx
By the way, after restarting the cache, you’ll at first probably see a few Critical timeout errors (for now still the same Event 6398) in the Application Event logs, but these will go away as the application syncs itself to the newly instantiated distributed cache.
I can’t guarantee that this will work for you, since your situation may be different, but this is what worked for me in debugging the dreaded Event 6398 :)
Justin Cooney 
1 thought on “SharePoint: Addressing Seemingly Random Critical Error Event 6398”