NullReferenceException in Microsoft.TeamFoundation.Framework.Server.FileCacheService.RetrieveFile causing TF30063 error

Question

I've just migrated a whole load of content from subversion into TFS (using the Timely Migration tool, which I would recommend) and I've been left in with an apparently corrupt TFS repository.

When I tried to get the latest version of one of our branches I got a TF30063 error. It turns out that it's actually a single changeset that is broken; If I try and get any content from that changeset I get the same error.

Looking in the App Tier event log it seems that what actually happens is an unhandled NullReferenceException in Microsoft.TeamFoundation.Framework.Server.FileCacheService.RetrieveFile.

Has anyone seen that before? I'm a bit worried that there may be more corrupt changesets in the history.

I'm running TFS 2012 Beta (not had a chance to upgrade to RC, yet; hopefully next week).

I've logged the issue in Connect, too: http://connect.microsoft.com/VisualStudio/feedback/details/752388/

Answer 1

Hi James,

My understanding is that this issue affects TFS 2012 Beta and RC. It is an issue with the garbage collector for the file service tables in the database. I believe we have released a hotfix for RC that corrects this issue.

Since there is potential data loss, I'm going to ask someone from the framework team to follow up with you on this issue directly.

Thanks,
P. Kelley

Answer 2

Hey James,

This looks indeed like a bug we had in the beta version of TFS 2012 - it is fixed in RC but until you can upgrade, you should disable the file cleanup job by running this query in your collection database(s).

The best workaround for this issue is to figure out which file is corrupt and re-upload it (or in your case the whole changeset). If you cannot figure it out, please call Microsoft Customer Service and we will help you out. I am very sorry you've hit this issue, and one way or another we will help you get your data back.

UPDATE 
tbl_JobDefinition 
SET    
EnabledState = 2 
WHERE   JobId = '7A3E559E-8EB7-4E90-A4F7-B7A2515D52B9'

Answer 3

Thanks, Remi. I'm glad to hear that it's fixed in RC.

Just to be clear, are the following three statements correct?

1. The file content for that changeset is already gone
2. If I disable that job I won't lose any more files
3. There are no other side effects of this bug
   

If so, then I can live with it. We have not "gone live" with TFS yet, so our primary source control server is still subversion. The actual missing changeset in question was in a temporary project that I always intended to delete anyway (after I've got the configuration of the svn->TFS migration tool finalised).

I'll just turn the file cleanup job off until we've upgraded to RC, and then do the "proper" final import of the sources.

Two more questions:

1. How would I turn the job back on again? Set the EnabledState to 0?
2. Is this a rare bug? I've got ~40000 revisions of history. I'm hoping I'm not likely to have lost more than this one.

Answer 4

1. Yes, You can re-enable the job by setting EnabledState to 0

2. The bug is somewhat rare as you have to upload and cleanup at the same time, the history is not lost, only the file content. Again this is fixed in RC and beyond. (RC is out so you can upgrade anytime :-))

Answer 5

Thanks, Remi. I'm happy with that.