The analysis from MIcrosoft is given below.
It shows a lot of pinned objects in memory. Some of whose GUID seems to be given. Also a screen with 4 RadGRid is creating many objects, as mentioned in the Summary below. Do you recognize the pattern given below? Can you please offer any solution? An early reply will be very much appreciated as this is urgent and may affect the Go-Live of a very big project.
We have a few pinned handles here, which are System.Object arrays:
Pinned Handles: 58
I looked at a couple of them to track down their roots, but couldn’t find any. The data in these appear to be something like this:
201cd4d0 6c69462f 20726574 4943432f 61465454 /Filter /CCITTFa
201cd4e0 63654478 2065646f 572f0a0d 68746469 xDecode ../Width
201cd4f0 32373120 2f0a0d38 67696548 32207468 1728../Height 2
201cd500 0d393032 69422f0a 65507374 6d6f4372 209../BitsPerCom
201cd510 656e6f70 3120746e 432f0a0d 726f6c6f ponent 1../Color
201cd520 63617053 442f2065 63697665 61724765 Space /DeviceGra
201cd530 2f0a0d79 676e654c 37206874 52203020 y../Length 7 0 R
201cd540 442f0a0d 646f6365 72615065 3c20736d ../DecodeParms <
Do you or your developers recognize this pattern?
I then looked up the System.Byte[] arrays...There are lots of these objects on the LOH, some as large as 8+ MB...
I traced some of these to PwC.Tobacco.Entities.TobaccoDisputeDocument & PwC.Tobacco.Entities.TobaccoNotice on thread 18. Further investigation shows that the source of these objects which are living long is Telerik.Web.UI.RadGrid, which roots PwC.Tobacco.Entities.TobaccoNotice via session. Session timeout itself isn't all that long - 20 minutes, but because they are in load testing, it appears to me that the process is running into this very quickly. Here’s the root:
ESP:347f2ac:Root: 2a0b61bc(Telerik.Web.UI.RadGrid)->
3c0426e0(ASP.pages_notification_viewpublishmsanotificationlist_aspx)->
5bcc7750(System.Web.HttpContext)->
1e0d21e8(System.Threading.Thread)->
1e0d4edc(System.Runtime.Remoting.Contexts.Context)->
1e0d4d50(System.AppDomain)->
1e11c29c(System.ResolveEventHandler)->
1e11b948(System.Web.Compilation.BuildManager)->
1e11c8b8(System.Web.Compilation.MemoryBuildResultCache)->
1e0e2a04(System.Web.Caching.CacheMultiple)->
1e0e2a1c(System.Object[])->
1e0e5614(System.Web.Caching.CacheSingle)->
1e0e5698(System.Web.Caching.CacheExpires)->
1e0e56b8(System.Object[])->
1e0e5740(System.Web.Caching.ExpiresBucket)->
4b0073d0(System.Web.Caching.ExpiresPage[])->
4b007454(System.Web.Caching.ExpiresEntry[])->
10771788(System.Web.Caching.CacheEntry)->
10771758(System.Web.SessionState.InProcSessionState)->
126649ac(System.Web.SessionState.SessionStateItemCollection)->
12664a0c(System.Collections.Hashtable)->
1316bedc(System.Collections.Hashtable+bucket[])->
1316becc(System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry)->
14acd12c(PwC.Tobacco.Entities.TobaccoNotice)->
Summary:
So there are 2 things that are contributing to the OOM here:
1. Many objects of type PwC.Tobacco.Entities.TobaccoNotice are rooted in session via Telerik.Web.UI.RadGrid
2. Pinned System.Object[] arrays.