The problem is that after some hours of running, the process starts eating up the CPU cycles. When debugging with WINDBG we notice that the thread consuming much of the CPU is in fact the Garbage Collector (<gcServer> is set to true).
On inspection of the Heap we notice that there is a very huge array on the LOH of the type System.LocalDataStoreElement with around 18million entries all set to null. This array is copied and increased each time, which is what is causing the cpu issue.
Now in our services we are passing Identities to impersonate user in the other appdomains / processes in the Named dataslots for the different threads (we have an object which implements the ILogicalThreadAffinative).
This issue is not present if the process runs on the CLR 2.0. Anybody can shed to us some light of what we are doing wrong or what changed in the CLR 4.0 please?
Why don't you re-build project with .NET Framework V4.0 directly?
The useLegacyV2RuntimeActivationPolicy attribute is useful if your application uses legacy activation paths, such as the
CorBindToRuntimeEx function, and you want those paths to activate version 4 of the CLR instead of an earlier version, or if your application is built with the .NET Framework 4 but has
a dependency on a mixed-mode assembly built with an earlier version of the .NET Framework. In those scenarios, set the attribute to true.