This post will deal with all of the following fantastic error messages:

Access to the path C:\ProgramData\Microsoft\SharePoint\Config\<guid>\<guid>.xml is denied.

File system cache monitor encountered error, flushing in memory cache: System.IO.InternalBufferOverflowException: Too many changes at once in directory:C:\ProgramData\Microsoft\SharePoint\Config\

It all began for me when attempting to do a routine clearing of the SharePoint configuration cache in the manner that is well documented by Microsoft and various bloggers.  All went well, so I thought, but there were two oddities left behind:

1. the cache.ini file never updated with a new value after resetting it to 1
2. there was an odd file with an xml.tmp extension on it that would never go away

I tried repeating the steps to clear the cache, but every time, those two results would occur.  Meanwhile, my ULS logs were getting flooded with the 888k File system cache monitor encountered error entries, and the CPU utilization on that server would spike to 100% about every 5 minutes.

Every other article discussing the configuration cache suggests that just clearing it will resolve these issues.  But not for me.

The next clue that something was not right was when I tried to issue a Powershell command to update a Web Application object.  There was a nervous pause, then the ‘Access denied’ error would be displayed.  Interestingly, the file that was indicated in the error had the same Guid filename (but without the .tmp extension) as the file that wouldn’t go away.

Thinking I could just delete this file manually, I opened Windows explorer and tried to delete it.  Nope, Access Denied.

I then looked a the properties of the file, and was told ‘You don’t have permissions to view the security information.’  What?  I’m an administrator.  Don’t tell me I don’t have permissions.

Googling…googling….googling.

After finally going down the ‘how to delete a locked file’ route, I came to this post on Serverfault, which introduced me to Lockhunter.

Download, install, browse to C:\ProgramData\Microsoft\SharePoint\Config\GUID.

Lockhunter showed about a half-dozen locked files, including the one I was getting the Access Denied error on.  The owner of the file?  miiserver.exe

This process is none other than the Microsoft Forefront Identity Manager service used by the SharePoint User Profile Synchronization feature.

After stopping the SharePoint Timer service and the SharePoint Administration service, I opened Central Admin, browsed to Services on server, found the User Profile Synchronization Service entry, and clicked Stop!

Ever so slowly the service stopped, and when I refreshed Lockhunter, the entry for miiserver.exe was gone.

A quick browse back to the Config directory showed that the xml.tmp file was gone, and the value in the cache.ini file had been restored back up to a value that wasn’t 1.

I definitely hope this helps others who find themselves in similar situations, at least offering a process to find out the culprit.