Cannot pass a GCHandle across AppDomains

Question

While working on my Automaton framework for build automaton with Team Foundation Server I've come upon this rather cryptic exception. It seems to happen only once in a while, something I'm able to do successfull requests without this exception.

What I have is an .ashx which returns some HTML content to my .aspx, and the .ashx is called using Xml Http javascript call (AJAX).

The error occurs when I try to read the .WorkItems property on an instance of the Changeset class.

Full exception stack:

[ArgumentException: Cannot pass a GCHandle across AppDomains.
Parameter name: handle]
   System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle) +0
   System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value) +92
   CProdStudioObjectRoot.{dtor}(CProdStudioObjectRoot* ) +87
   CField.{dtor}(CField* ) +254
   ATL.CComObject<CField>.Release(CComObject<CField>* ) +208
   CProdStudioObjectRoot.ReleaseRegistered() +497
   Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DatastoreClass.set_CallingProcessIdentity(Int32 hCallingProcessIdentity) +335
   Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal() +706
   Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITeamFoundationServerObject.Initialize(TeamFoundationServer teamFoundationServer) +90
   Microsoft.TeamFoundation.Client.TeamFoundationServer.CreateITFSObjectInstance(Type serviceType) +137
   Microsoft.TeamFoundation.Client.TeamFoundationServer.GetService(Type serviceType) +241
   Microsoft.TeamFoundation.VersionControl.Client.Changeset.get_WorkItemStore() +31
   Microsoft.TeamFoundation.VersionControl.Client.Changeset.get_WorkItems() +24
   changeset.ProcessRequest(HttpContext context) in c:\Documents and Settings\sonbje\My Documents\Visual Studio 2005\Workspaces\Automaton\Automaton\changeset.ashx:77
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +154
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Answer 1

Here's a related post.

Answer 2

This is a known bug in the work item tracking object model that is fixed in SP1.  You either can or will be able to request a hotfix from customer support.

Buck

Answer 3

Buck Hodges wrote:

This is a known bug in the work item tracking object model that is fixed in SP1.  You either can or will be able to request a hotfix from customer support. Buck

Is there an ETA for the SP1? I guess I could get the hotfix for my own company, but I doubt I can redistribute this hotfix together with my build automation software? Not many that uses it yet so I guess we can all wait for SP1, as it's just a matter of refreshing the page a few times and it works again.

Thanks for the response!

Answer 4

I can't say when SP1 will ship. :(

I'm not sure what the policy is with regard to redistributing a hotfix.  I'd suggest asking Customer Support.

Buck

Answer 5

Is there a KB article associated w/ this problem.  We contacted Microsoft and they are not able to give out a hotfix w/o an associated KB article.

Thanks for any info.

Kel

Answer 6

Is there a contact or email address for who to get a hold of about acquiring the fix?

Thank you,

Aaron

Answer 7

Kel Koenig wrote:

Is there a KB article associated w/ this problem.  We contacted Microsoft and they are not able to give out a hotfix w/o an associated KB article. Thanks for any info. Kel

Same problem here.  I couldn't find a KB article associated to this.  Right now this issue prevents me from running any of my unit tests as part of the build process.  If I run each of them individually through the VS2005 environment, it works fine.  If I try to batch them all together (even inside of VS2005) I get this error.

Has anyone had any luck in getting this hotfix?

Thanks,
Shane

Answer 8

Unfortunately, the hotfix hasn't made it out yet.  It got hung up on a dependency.  Hopefully, it will go out in the next couple of weeks.

Buck

Answer 9

Okay, I'm tired of being wrong.  No more guesses on when it gets out. :-(

However, here's a bit of good news.  Naren (http://blogs.msdn.com/narend) posted a reference to the following blog post, http://www.goeleven.com/blog/entryDetail.aspx?entry=35.  In it, the author describes how to get around the GCHandle bug.  I haven't tried this, but it sounds promising.

Whenever you create an instance of the WorkItemStore class, a cache is create on the local disk. By default this local folder is located in the current users profile. This works fine whenever you use the API in a winforms application, but not for an ASP.NET application. ASP.NET applications run under the NETWORK SERVICE by default and that profile is inaccessible.

To change this default behaviour, you can set WorkItemTrackingCacheRoot property of the TeamFoundationServer instance in code or in your configuration file's appSettings section.

But, setting the cache on local disk incurs some risk to. Whenever you set the cache to a folder inside the website's virtual directory you will encounter the following error each second call to the workitem store: 'Cannot pass GCHandle across AppDomain'. This issue is caused by an unmanaged component called CProdStudio, which is cannot be reached for cleanup as it is defined in an other application domain. At first, I was quite astonished by this behaviour. I allways thought ASP.NET applications ran in a single AppDomain unless something changed to the configuration file or one of the assemblies. This seems to be only partially correct, in fact ASP.NET monitors all file changes in the application and as soon as this count hits a mere 15, it will automatically recycle and create a new AppDomain. As the workitem cache is a file store which will be target of multiple write operations, it will allmost allways cause a recycle of the AppDomain.

Getting rid of this annoying behaviour can be achieved by setting the numRecompilesBeforeAppRestart attribute of the compilation tag in your application's configuration file to a very large number or better, move the cache to a folder outside the website's virtual directory.

 

<add key="WorkItemTrackingCacheRoot" value="D:\Data\Cache" />

 Buck

Answer 10

SP1 beta is out now, and it includes the fix to the GCHandle issue, according to Brian Harry's blog post.

Buck

Answer 11

Tried to fix the issue by setting numRecompilesBeforeAppRestart to a value of 500, but the exception still occurrs the very first time I try to expand a node in my web application which gathers work item information. The second time, it works fine.

Good to see that SP1 is out in beta and the issue have been fixed, but I think TFS SP1 beta is the first Microsoft beta I don't dare to install. Will there be a smooth upgrade path from beta to RTM?

Answer 12

Buck Hodges wrote:

SP1 beta is out now, and it includes the fix to the GCHandle issue, according to Brian Harry's blog post. Buck

Hmm.. I got this one in SP1 too, just the other day.....

Fortunatly, i saw Naren's blog about WIT on web, and did what that said and it disappeared.

Answer 13

BTW, SP1 is installed but I still have sometimes this exception:

w3wp.exe Error: 0 :    at System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle)
   at System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value)
   at CProdStudioObjectRoot.{dtor}(CProdStudioObjectRoot* )
   at CField.{dtor}(CField* )
   at ATL.CComObject<CField>.Release(CComObject<CField>* )
   at CProdStudioObjectRoot.ReleaseRegistered()
   at Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DatastoreClass.set_CallingProcessIdentity(Int32 hCallingProcessIdentity)
   at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal()
   at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITeamFoundationServerObject.Initialize(TeamFoundationServer teamFoundationServer)
   at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore..ctor(TeamFoundationServer teamFoundationServer)

Answer 14

I have SP1 installed-- I get this error as well. I have my refresh set to 80000. . . any ideas?

Answer 15

My asp.net app typically gives this error when my application pool is set to 2 worker processes. The error goes away when I change the number of worker processes to 1.

By the way, VS2005 SDK and TFS are NOT installed on my development box. I deployed the web app with the teamfoundation dlls in the local bin folder.

I have also used WorkItemTrackingCacheRoot to a temp folder outside of my application folder:
<add key="WorkItemTrackingCacheRoot" value="C:\temp\teamFoundationCache"/>

Answer 16

Same here, updated to SP1, and still get the GCHandle error.
I'm manipulating WITs through a webapp.

I found this: http://support.microsoft.com/kb/918454 which refers to running reports. Will this fix the issue?

Answer 17

I finally solved the issue by installing this
Though it crashed a couple of times and I had to run it several times until the datastore.dll was updated.

Answer 18

I'm getting the save behaviour, is this SP1 for Visual Studio 2005 or for TFS?

Answer 19

SP1 for Visual Studio Team Suite (i.e. the client) as per the link reported by pablog above.

Note, depending on what you have installed, the SP1 install appears to run multiple times.  This is normal.

 

Let us know is this works for you,