WCF "Instance already exists in CounterSet" error when reopening ServiceHost

Question

I have a working ServiceHost with a single NetTcpBinding and a single endpoint.

I .Close() it. Then, I create a new ServiceHost instance with the exact same configuration as the first one. Then, when I try to .Open() the new instance I'm getting this very awkward exception:

System.ArgumentException occurred
  Message=Instance '[email protected]:||localhost:2718|game|' already exists in CounterSet 'e829b6db-21ab-453b-83c9-d980ec708edd'.
Parameter name: InstanceName
  Source=System.Core
  ParamName=InstanceName
  StackTrace:
       at System.Diagnostics.PerformanceData.CounterSetInstance..ctor(CounterSet counterSetDefined, String instanceName)

Has anybody seen that before? Is it a bug in the .NET Framework (I'm using 4.0, by the way)?

Probably relevant info about my ServiceHost:

• No clients are connected to the host, when it is first closed;
• A custom IInstanceProvider is used to create instances;
• The binding's ReliableSession is turned on;
• The service type is marked with the ServiceBehavior below;

.

[ServiceBehavior(
IncludeExceptionDetailInFaults = true,
InstanceContextMode=InstanceContextMode.PerSession,
ConcurrencyMode=ConcurrencyMode.Reentrant,
UseSynchronizationContext = false
)]

I'm open to reveal any extra info you might want to know about the application.

Update 1 I compiled the application targeting .NET 3.5 and the error did NOT happened. Unfortunately, I have to deactivate everything that relied in Task's.

Update 2 I logged a bug at Microsoft Connect about this issue. I guess this question is already answered now.

Answer 1

This is a bug with .NET Framework 4.0. I logged a bug at Microsoft Connect about it.

Here's the answer from Microsoft:

This looks like a known problem caused by timing issues in tight Close/open sequence of ServiceHost. ServiceHost maintains some performance counters that might not get garbage collected leading to this exception. I assume you are using .Net Framework 4.0? Please try to workaround by doing a forced GC before you open the second ServiceHost:

GC.Collect() 
GC.WaitForPendingFinalizers()

Doing what they advised solved the problem. I hope it gets fixed in a later release.