We had a patching window this past weekend and I noticed that beginning Sunday morning, the Timer Service Recycle job was failing.  Its scheduled to run at the default 6:00 am and has failed every day since.  The error that accompanies the failed job is that the recycle couldnt run due to a running instance of the Microsoft SharePoint Foundation Usage Data Import (see below).

The Execute method of job definition Microsoft.SharePoint.Administration.SPTimerRecycleJobDefinition (ID 20fea14e-75db-4e86-a1af-d780fd87eb01) threw an exception. More information is included below.

The timer service was not recycled because the following jobs were still running: Microsoft SharePoint Foundation Usage Data Import

Ive since observed the Usage Data Import job and noticed that its taking unusually long to run.  Checking the ULS, the following jumped out at me:

Deleting usage log file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\***-*******-20130502-1600.usage' after data import.

Failed to delete usage log file 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\***-*******-20130502-1600.usage' after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process.   

 at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)   

 at System.IO.FileInfo.MoveTo(String destFileName)   

 at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath)   

 at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi)   

 at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)

It appears that file is marked for deletion but then fails as the file is locked by another process.  I enabled verbose logging but didnt see anything beyond the above error.  I even tried to manually delete one of the usage files while the job was running and it appears to be locked up by the SharePoint timer.  Also thought that this may be related to the patching that was done and uninstalled all patches from test but the problem still exists.

My other thought was that perhaps some real-time virus scanning was locking the folders. However, McAfee is not installed in my test environment so I know this also isn't the issue.

Any thoughts or suggestions would be greatly appreciated.

Hi,

Thank you for your post.
I'm trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

Thanks ,
Entan Ming

Hi Juan TF,

regarding your issue, perhaps you may try to clean up the cache,

http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx

Hi Aries,

I cleared the cache on all servers in my test farm (1 WFE and 2 app servers), restarted the timer and re-ran the data usage import job but still the same result.  The job eventually does complete but takes a long time and still errors in the ULS regarding unable to delete usage log files due to it being locked by another process.

Thanks for the suggestion but it does not appear to help.

Hi Juan TF,

thank you for the clarification,

if the process was completed but slow, perhaps it got some issue with the performance.

Microsoft sharepoint foundation usage data import job description is to imports usage log files into the logging database, and by default it is set for every 30 minutes.

importing some data to database, it will lock the resource and make sure there are no changes when the process is triggered. if for example that the process of import is still on going, then there is other process to delete the usage file, it will show the information that delete usage file is failed.

perhaps, this is what happened at your environment.

there are workarounds for this issue for you to check:

1. change the timer service recycle schedule or Microsoft sharepoint foundation usage data import schedule.

2. change the usage and health log configuration at central admin

3. some other deeper concern, there is performance issue, maybe bottle neck issue, such as there are some components that included in data import job is slow. then we need to capture the memory dump files using adplus or debugdiag, to check the thread ID that causing the issue.

Hi Juan TF,

Please check if the following Windows KB is installed on your SharePoint Server: 2775511 (https://support.microsoft.com/kb/2775511). If yes, please try to uninstall it and check if the issue happens again. Seems like we experience this behavior when that KB is installed.

Best regards,
Vlad

• Marked as answer by Juan TF Thursday, May 23, 2013 12:00 AM

Hi Vlad,

That did the trick!  I uninstalled KB2775511 and the job now runs in under 30 seconds on all of my servers.  Thanks so much for the advice; been banging my head about this one for a while now.

Will Microsoft be updating the information for this KB advising that it can cause issues with data usage import job?

Thanks,
Juan

I am having this very same problem, and started happening right after applying the latest OS Updates (new ones in August, 2013).  However, KB2775511 was never advertised nor installed on my servers. 

I'm in the process of uninstalling the recent updates one by one, and if I figure out which one was the culprit in My case, I'll update this thread.

• Proposed as answer by MartyBrownChicago Thursday, August 29, 2013 6:18 PM
• Unproposed as answer by MartyBrownChicago Thursday, August 29, 2013 6:18 PM

OK, an update:

I found that by Un-installing KB2682011, I was able to remove the issue with the SP Usage Import timer job taking longer and longer each time it ran.   I Hope this fix works for others!

• Proposed as answer by MartyBrownChicago Thursday, August 29, 2013 6:20 PM

An update - Subsequent rounds of OS patching showed that a new patch also causes this very same issue with the Microsoft SharePoint Foundation Usage Data Import Timer Job:

KB2882822

• Proposed as answer by MartyBrownChicago Thursday, October 24, 2013 7:12 PM

Correction to my previous post...

After further investigation, found that KB2775511 was not correctly hidden and was re-installed during last patching window.  Removing this one and KB2882822 has corrected the issue.

Hey,

Spoke to Microsoft about this issue, and several have reported that uninstalling the mentioned update will fix the problem, but the update is quite big with a lot of updates, so this might not be a good fit for everyone.

The fix for this issue will be come in the 2013 desember CU and meanwhile you can get away from this issue by creating a windows task running the restart sharepoint 2010 Timer service every night or uninstalling kb2775511 :-)

Official message:

"

Cause

We found that the OWSTIMER was not properly releasing handles from the trace logs and after installing Windows Roll-Up KB2775511, the file handles on the usage logs remained opened. <u5:p>

Resolution

A fix for this issue will be included in the next CU / Hotfix released, which is currently slated for December 2013.  To mitigate the symptoms of this problem (until the hotfix is released) you can restart the timer service manually. This will release the handles to the .usage files and allow them to be deleted the next time the usage import timer job runs. You can schedule this to run every day by creating a scheduled task that runs this PowerShell: restart-service -Name SPTimerV4

Recommendation

Hence, the recommendation would be to uninstall that kb for the time being, and install it again after the problem is fixed with the incoming CU. Once it is released you should install it in your test environment to verify that if does indeed solve the problem.
Please keep in mind that there is always a possibility that the hotfix release may be delayed for whatever the reason.

"

br

Bjorn

• Proposed as answer by Bjørn Roalkvam Tuesday, December 03, 2013 7:19 AM
• Edited by Bjørn Roalkvam Tuesday, December 03, 2013 7:45 AM

Hello Everyone,

this issue was fixed with December CU 2013. Please see the following KB: http://support.microsoft.com/kb/2849981.

For the SharePoint Foundation 2010 Dec Cu 2013 : http://support.microsoft.com/kb/2849990/en-us

For the SharePoint Server 2010 Dec Cu 2013 : http://support.microsoft.com/kb/2849971/en-us

Please test it in your test env first.

HTH,

Vlad

Thanks for the feedback Vlad

From checking, we can see that these KBs are included in the SharePoint 2010 Service Pack 2. However, the problem is not fixed for me.

Same error as in the first post here.

Any updates on this from any of the Microsoft folks?  We are experiencing this problem in several environments, and seems to be related to patches we installed.  For our Staging and Production environments, it was crystal clear that we did not have the problem before the updates, and did have the problem immediately after. 

In our case, we do not have KB2775511 or KB2682011 installed.  But I am finding KB2882822 installed at different times on the different systems, so I'm starting to roll that back off of some of them to see if that makes a difference.  Based on the timing of installation of that patch specifically tho, I suspect it's actually not the cuprit. 

We are currently on SharePoint 2010 SP1, CU updates from April 2013. 

This issue has been solved since the December 2013 Cumulative Update of SharePoint 2010:

https://support.microsoft.com/en-us/kb/2916922