Hang troubleshooting needed

Question

Hello,

I have ASP.NET hang on me. I saw Requests Current climb to 5000 which I never saw before (since I assume number of threads in a pool is 25xnumber of CPUs).
I generated memory dump and DebugDiag gave following
The following threads in w3wp.exe__SharePoint - 80__PID__4848__Date__10_02_2009__Time_03_52_28PM__22__Manual Dump.dmp are calling an ISAPI Extension OWSSVR

( 25 35 37 38 39 41 43 44 45 59 71 80 81 82 85 92 99 101 102 103 114 126 127 128 129 130 )

19.70% of threads blocked

Detected possible blocking or leaked critical section at 0x000cf0d0 owned by thread 37 in w3wp.exe__SharePoint - 80__PID__4848__Date__10_02_2009__Time_03_52_28PM__22__Manual Dump.dmp

Impact of this lock

17.42% of threads blocked

(Threads 28 30 31 32 33 34 36 40 42 72 78 86 87 90 96 97 98 104 106 111 113 115 131)

The following functions are trying to enter this critical section
mscorwks!UnsafeEEEnterCriticalSection+18


Majority of threads are having the same pattern below on call stack

mscorwks!SVR::gc_heap::wait_for_gc_done+99
mscorwks!SVR::gc_heap::try_allocate_more_space+17
mscorwks!SVR::gc_heap::allocate_more_space+2f
mscorwks!SVR::GCHeap::Alloc+74

Call stack for thread 37 is below

ntdll!KiFastSystemCallRet
ntdll!NtWaitForSingleObject+c
kernel32!WaitForSingleObjectEx+ac
mscorwks!PEImage::LoadImage+199
mscorwks!CLREvent::WaitEx+117
mscorwks!CLREvent::Wait+17
mscorwks!SVR::GCHeap::WaitUntilGCComplete+32
mscorwks!Thread::RareDisablePreemptiveGC+1a1
mscorwks!ThreadNative::GetDomainLocalStore+100
mscorlib_ni+317a68
mscorwks!COMToCLRWorkerBody+10f
mscorwks!COMToCLRWorkerBody+208
mscorwks!COMToCLRWorkerDebuggerWrapper+37
mscorwks!COMToCLRWorker+164
0x01eea295
STSWEL!VglobalConfig::lookupSite+ff
STSWEL!VdbServer::init+5a
STSWEL!VdbServer::initFromVframeworkWithUrl+205
STSWEL!VdbServer::initFromVframework+8d
OWSSVR!GetExtensionVersion+208a5
ONETUTIL!Vframework::doMain+69
OWSSVR!GetExtensionVersion+819
ONETUTIL!COWSThreadWithHeap::WalkHeap+16f
ONETUTIL!COWSThreadWithHeap::Uninitialize+45d
ONETUTIL!VonetLocks::CCritSec::~CCritSec+1a
msvcr80!_callthreadstartex+1b
msvcr80!_threadstartex+66
kernel32!BaseThreadStart+34

Output of !threads does not list any of the threads with GC disabled.

Output of other potentially usefull commands are below

0:037> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
-----------------------------
Total           4867
CCW             12
RCW             1051
ComClassFactory 0
Free            100

0:037> !eeversion
2.0.50727.832 retail
Server mode with 2 gc heaps
In plan phase of garbage collection
SOS Version: 2.0.50727.832 retail build


Time spent in GC during hang was 20%

Answer 1

Hello Lorry

 

Welcome to the CLR forum! After carefully analyzing the provided information, I have these suggestions for you:

 

1. From the callstack of thread 37, your ASP.NET app seems related to sharepoint (maybe a sharepoint webpart?). Honestly I’m not familiar with sharepoint, so my suggestions below are based on common language runtime. Maybe you can tell me more about those sharepoint modules (ONETUTIL, STSWEL) and the lock the thread is owning (VonetLocks)?

 

2. Could you please run the command !threads, and look for threads with “(GC)” in the Exception column? If you find such a thread, please dump its raw call stack using the kb command. This thread should be the one that triggers GC.

 

3. Because this is a multi processor machine with 2 heaps (we could see this from the !eeversion output), we have 2 threads dedicated to doing garbage collection. Please find out which ones they are by searching the stacks of all threads (~* kb and ~* e !clrstack) for the function gc_thread_stub which is the first function called on the GC threads. Please dump the call stack of the GC threads.

 

4. Please run !threadpool, as I’m interested in your CPU utilization.

 

5. You said that the following functions are trying to enter this critical section

mscorwks!UnsafeEEEnterCriticalSection+18

Could you please find out what the thread is, and its call stack?

 

6. Because the majority of your threads tried to allocate more memory and waited for GC completion.

mscorwks!SVR::gc_heap::wait_for_gc_done+99   

mscorwks!SVR::gc_heap::try_allocate_more_space+17   

mscorwks!SVR::gc_heap::allocate_more_space+2f   

mscorwks!SVR::GCHeap::Alloc+74

What can make us spend a lot of our time in GC?  As Tess said in her blog http://blogs.msdn.com/tess/archive/2006/03/27/561715.aspx, there are these common reasons:

   a. Have a high allocation rate / second

   b. Let your objects reach gen 2 and then let them die

   c. Create a lot of objects that get stored on the large object heap (since collecting the LOH means collecting all generations)

   d. Block the finalizer so that no matter if objects are collected they still can't go away if they have a finalizer

Tess also introduced the methods to determine the cause. Please follow her instructions, and post your findings here.

 

7. If the dump is not too big, please upload it to this place. I’d like to take a look at it.

https://sftus.one.microsoft.com/choosetransfer.aspx?key=84a41878-7893-49a5-80a0-fa7752cd571a

Password:

{Cv52[kbga+nO

 

Regards.

Jialiang Ge

 

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

2. There is no thread with Exception relevant to GC available in output of !threads
3. Threads 17 and 16 are GC threads. Stacks are below

0:017> kb
ChildEBP RetAddr  Args to Child             
0e23fbc0 7c827d0b 77e61d1e 00000400 00000000 ntdll!KiFastSystemCallRet
0e23fbc4 77e61d1e 00000400 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0e23fc34 79e718fd 00000400 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac
0e23fc78 79e718c6 00000400 ffffffff 00000000 mscorwks!PEImage::LoadImage+0x199
0e23fcc8 79e7187c ffffffff 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
0e23fcd8 7a0cb702 ffffffff 00000000 00000000 mscorwks!CLREvent::Wait+0x17
0e23fd1c 7a0d17ee 00104428 0000000f 05fb0038 mscorwks!SVR::t_join::join+0xae
0e23fd54 7a0d783b 00000002 05fb0038 00000002 mscorwks!SVR::gc_heap::relocate_phase+0xd4
0e23fe54 7a0d8110 00000002 00104428 00000002 mscorwks!SVR::gc_heap::plan_phase+0x90b
0e23fe70 7a0d85a8 00000000 ffffffff 00104428 mscorwks!SVR::gc_heap::gc1+0x57
0e23fe88 7a0d8698 00000002 00000000 00104428 mscorwks!SVR::gc_heap::garbage_collect+0x33a
0e23fea8 7a0d8987 0e23ff00 77e6956d 0e23fec8 mscorwks!SVR::gc_heap::gc_thread_function+0x69
0e23ffb8 77e64829 00104428 00000000 00000000 mscorwks!SVR::gc_heap::gc_thread_stub+0x9b
0e23ffec 00000000 7a0d88eb 00104428 00000000 kernel32!BaseThreadStart+0x34

0:016> kb
ChildEBP RetAddr  Args to Child             
0e1ffdd0 7a0cdb34 52064404 523071d8 0e1ffe0c mscorwks!SVR::gc_heap::relocate_survivors_in_plug+0x245
0e1ffdec 7a0cdc4f 523072d8 0e1ffe0c 00000002 mscorwks!SVR::gc_heap::relocate_survivors_in_brick+0x3c
0e1ffe1c 7a0d17a3 00000002 01fb0038 01fb0038 mscorwks!SVR::gc_heap::relocate_survivors+0x10a
0e1ffe54 7a0d783b 00000002 01fb0038 00000001 mscorwks!SVR::gc_heap::relocate_phase+0x89
0e1fff54 7a0d8110 00000002 00103660 00000004 mscorwks!SVR::gc_heap::plan_phase+0x90b
0e1fff70 7a0d85a8 00000000 ffffffff 00103660 mscorwks!SVR::gc_heap::gc1+0x57
0e1fff88 7a0d8698 00000002 00000000 00103660 mscorwks!SVR::gc_heap::garbage_collect+0x33a
0e1fffa8 7a0d8987 00000000 da0e1e58 0e1fffec mscorwks!SVR::gc_heap::gc_thread_function+0x69
0e1fffb8 77e64829 00103660 00000000 00000000 mscorwks!SVR::gc_heap::gc_thread_stub+0x9b
0e1fffec 00000000 7a0d88eb 00103660 00000000 kernel32!BaseThreadStart+0x34

4.  Output of !threadpool is below

0:000> !threadpool
CPU utilization 100%
Worker Thread: Total: 10 Running: 5 Idle: 5 MaxLimit: 200 MinLimit: 2
Work Request in Queue: 2533
...
umber of Timers: 20
--------------------------------------
Completion Port Thread:Total: 2 Free: 0 MaxFree: 4 CurrentLimit: 2 MaxLimit: 200 MinLimit: 2

Why limit is 200? I thought it's number of CPU multiplies by 25? Shall be 50?
One thing to note thought about Sharepoint. It has wildcard mapping to ASP.NET on website so even static JPG files are being pipelined through ASP.NET processor.
What is exactly is limited number of Requests in Queue before it throws 500? Which setting is that?

5.
There are 4 threads which are trying to enter CriticalSection. Example is below

0:028> kb
ChildEBP RetAddr  Args to Child             
12d7e518 7c827d0b 7c83d236 00001758 00000000 ntdll!KiFastSystemCallRet
12d7e51c 7c83d236 00001758 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
12d7e558 7c83d281 00001758 00000004 000cf0d0 ntdll!RtlpWaitOnCriticalSection+0x1a3
12d7e578 7a05ae43 000cf0d0 79e836c2 000cf0d0 ntdll!RtlEnterCriticalSection+0xa8
12d7e580 79e836c2 000cf0d0 c6c6045c 000ffbc4 mscorwks!UnsafeEEEnterCriticalSection+0x18
12d7e5bc 79f4c1d0 c6c60408 000ffbc4 000ffa7c mscorwks!CrstBase::Enter+0x13c
12d7e5e8 79f4c53a c6c6077c 0202d8c4 0202da14 mscorwks!ThreadStore::LockDLSHash+0x31
12d7e69c 793d7a68 0202d8c4 13c041ba 0202d8c4 mscorwks!ThreadNative::GetDomainLocalStore+0xe8
12d7e7e0 79e8e8ed 7939efcc 52607aa0 00000001 mscorlib_ni+0x317a68
12d7e8a0 34cc2a63 4c596401 fb63ff8e 35c222b9 mscorwks!SystemNative::ArrayCopy+0x4f9
WARNING: Stack unwind information not available. Following frames may be wrong.
12d7e8b4 52904ad8 5290c64c 2451da2d 12d7f47c offparser+0x32a63
12d7e8b8 5290c64c 2451da2d 12d7f47c 79fc84c6 0x52904ad8
12d7e8bc 2451da2d 12d7f47c 79fc84c6 12d7f5f8 0x5290c64c
12d7e8c0 12d7f47c 79fc84c6 12d7f5f8 00000000 0x2451da2d
12d7e8c4 79fc84c5 12d7f5f8 00000000 00000000 0x12d7f47c
12d7f47c 79f54465 12d7f5f8 c6c614c0 12d7f7b0 mscorwks!CallJitEHFinally+0x81
12d7f480 12d7f5f8 c6c614c0 12d7f7b0 79f55262 mscorwks!COMPlusFrameHandler+0x10d
12d7f520 79f361fb 000ff888 12d7f738 12d7f7a0 0x12d7f5f8
12d7f56c 79f55eb5 ade283f8 00000000 12d7f6f0 mscorwks!COMToCLRWorkerDebuggerWrapper+0x37
12d7f628 79e73959 12d7f658 7a327478 ffffffff mscorwks!CLRException::IsPreallocatedExceptionObject+0x47

0:028> !clrstack
OS Thread Id: 0x1fb8 (28)
ESP       EIP    
12d7e638 7c8285ec [HelperMethodFrame_1OBJ: 12d7e638] System.Threading.Thread.GetDomainLocalStore()
12d7e6a4 793d7a68 System.Threading.Thread.GetData(System.LocalDataStoreSlot)
12d7e6ac 13c041ba Microsoft.SharePoint.Administration.Tls.get_Data()
12d7e6b8 13c03fbc Microsoft.SharePoint.Administration.SPFarm.get_ThreadContext()
12d7e6c4 13c02eac Microsoft.SharePoint.Administration.SPContentDatabase.ValidateDatabaseSchemaCompatibility()
12d7e750 13c02993 Microsoft.SharePoint.SPSite.PreinitializeServer(Microsoft.SharePoint.Library.SPRequest)
12d7e7b4 27eb0a24 Microsoft.SharePoint.SPSite.GetSPRequest()
12d7e7c8 27eb099d Microsoft.SharePoint.SPSite.get_Request()
12d7e7d8 27eb3669 Microsoft.SharePoint.SPSite.OpenWeb(System.Guid, Int32)
12d7e850 27eb3617 Microsoft.SharePoint.SPSite.OpenWeb(System.Guid)
12d7e86c 27eb357f Microsoft.SharePoint.Publishing.CachedArea.GetIdentityWeb(System.Guid, Microsoft.SharePoint.SPSite, Boolean)
12d7e8a4 27eb3447 Microsoft.SharePoint.Publishing.CachedArea.GetSuperReaderIdentityWeb(Microsoft.SharePoint.SPSite)
12d7e8c4 2451da2d Microsoft.SharePoint.Publishing.CachedArea..ctor(Microsoft.SharePoint.Publishing.PublishingWeb, System.String, System.String, System.String, System.String, System.String, Microsoft.SharePoint.Publishing.CachedObjectFactory)
12d7ece8 2451d468 Microsoft.SharePoint.Publishing.CachedArea.CreateCachedArea(Microsoft.SharePoint.Publishing.PublishingWeb, Microsoft.SharePoint.Publishing.CachedObjectFactory, System.String)
12d7ed24 2451ce5e Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(Microsoft.SharePoint.Publishing.PublishingWeb, System.String)
12d7ed50 2451cdd1 Microsoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(Microsoft.SharePoint.Publishing.PublishingWeb)
12d7ed60 1aa9c386 Microsoft.SharePoint.Publishing.TemplateRedirectionPage.ComputeRedirectionVirtualPath(Microsoft.SharePoint.Publishing.TemplateRedirectionPage)
12d7eeb8 16f80624 Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.CombineVirtualPaths(System.String, System.String)
12d7eef4 6604924c System.Web.Hosting.VirtualPathProvider.CombineVirtualPaths(System.Web.VirtualPath, System.Web.VirtualPath)
12d7ef04 66134e57 System.Web.UI.DependencyParser.AddDependency(System.Web.VirtualPath)
12d7ef14 66329c7c System.Web.UI.DependencyParser.ProcessDirective(System.String, System.Collections.IDictionary)
12d7ef28 65fdbe3f System.Web.UI.PageDependencyParser.ProcessDirective(System.String, System.Collections.IDictionary)
12d7ef38 65fdb990 System.Web.UI.DependencyParser.ParseString(System.String)
12d7ef4c 65fdb4bf System.Web.UI.DependencyParser.ParseFile(System.String, System.Web.VirtualPath)
12d7ef8c 65fdb1e7 System.Web.UI.DependencyParser.GetVirtualPathDependencies()
12d7efc0 65fd8419 System.Web.Compilation.TemplateControlBuildProvider.GetBuildResultVirtualPathDependencies()
12d7efd0 6604595a System.Web.Compilation.BuildManager.GetVirtualPathDependencies(System.String)
12d7efe0 1aa9b4e7 Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.CalculateFileDependencies(System.Web.HttpContext, Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData, System.Collections.ICollection ByRef, System.Collections.ICollection ByRef)
12d7f080 1aa9ad9d Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureDependencies(System.Web.HttpContext, Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData)
12d7f0cc 1aa9a94e Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureCacheKeyAndViewStateHash(System.Web.HttpContext, Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData)
12d7f158 1aa9a569 Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.GetVirtualPathProviderCacheKey(System.Web.HttpContext, Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData)
12d7f168 1aa99eb3 Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.GetVirtualPathProviderCacheKey(System.String)
12d7f188 13c02cf9 Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.GetCacheKey(System.String)
12d7f1a4 13c02c9f Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.GetCacheKey(System.String)
12d7f1b4 65fd6965 System.Web.Hosting.VirtualPathProvider.GetCacheKey(System.Web.VirtualPath)
12d7f1bc 65fd68d5 System.Web.Compilation.BuildManager.GetCacheKeyFromVirtualPath(System.Web.VirtualPath, Boolean ByRef)
12d7f1cc 65fd689a System.Web.Compilation.BuildManager.GetVPathBuildResultFromCacheInternal(System.Web.VirtualPath)
12d7f1dc 65fd6573 System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(System.Web.VirtualPath, Boolean, Boolean, Boolean)
12d7f244 65fd64ea System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(System.Web.HttpContext, System.Web.VirtualPath, Boolean, Boolean, Boolean)
12d7f280 65fd6448 System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(System.Web.VirtualPath, System.Web.HttpContext, Boolean, Boolean)
12d7f298 65fd6353 System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(System.Web.VirtualPath, System.Type, System.Web.HttpContext, Boolean, Boolean)
12d7f2d4 65fd62d4 System.Web.UI.PageHandlerFactory.GetHandlerHelper(System.Web.HttpContext, System.String, System.Web.VirtualPath, System.String)
12d7f2ec 65fd628d System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(System.Web.HttpContext, System.String, System.Web.VirtualPath, System.String)
12d7f308 65fc0558 System.Web.HttpApplication.MapHttpHandler(System.Web.HttpContext, System.String, System.Web.VirtualPath, System.String, Boolean)
12d7f34c 65fd58cd System.Web.HttpApplication+MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
12d7f35c 65fc1610 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
12d7f39c 65fd32e0 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)
12d7f3ec 65fc0225 System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object)
12d7f408 65fc550b System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
12d7f43c 65fc5212 System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
12d7f448 65fc3587 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)
12d7f5f8 79f35ee8 [ContextTransitionFrame: 12d7f5f8]
12d7f648 79f35ee8 [GCFrame: 12d7f648]
12d7f7a0 79f35ee8 [ComMethodFrame: 12d7f7a0]
6. I uploaded file to MS repository if you can take a look.

Answer 3

Hello

I have received your dump. Here is my initial analysis:

Thread 28 30 31 32 33 34 36 40 42 72 78 86 87 90 96 97 98 104 106 111 113 115 131 blocked on the critical section 0x000cf0d0 which is currently owned by the thread 37. Thread 37 called an ISAPI Extension OWSSVR, and is waiting for GC completion. GC is in "plan phase," where objects are being moved around. The finalizer thread in the dump is waiting for GC compeletion too.

So the questions are:
1. Why are so many threads blocking on the critical section because of Thread.GetData()? What is critical section for?
2. What makes GC so busy??

I'm digging into the first one.

As for the second one, please collect performance logs with counters that could possibly help.

Process/%Processor Time
Process/Virtual Bytes
Process/Private Bytes
.NET CLR Memory/All counters (To see how much time we are spending doing GC, how much memory is managed and how the ratio of Gen 0/Gen 1 and Gen 2 collections look)
ASP.NET counters to look for queueing, execution time etc.

Regards,
Jialiang Ge

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 4

I uploaded perfmon data to your repository. In essense major counters are below

Requests Executing - maximum is staggering 118102, average 4172
Requests Current - maximum 5001, average 273
Request Queued - maximum 1414, average 63

Process usertime - maximum 147, average 50
Process Priviliage time - maximum 191, average 129
Process total - maximum - maximum 196, average 178

Answer 5

Hello Lorry

http://blogs.msdn.com/junfeng/archive/2005/12/31/508423.aspx
http://blogs.msdn.com/jfoscoding/archive/2006/07/18/670497.aspx
http://blogs.msdn.com/ricom/archive/2006/07/18/670314.aspx

The Whidbey RTM implementation of Thread.GetData/Thread.SetData has several scalability issues caused by global locks being taken. The appdomain-global lock taken in LocalDataStore.SetData is one of them. There is another global lock taken in ThreadNative::GetDomainLocalStore that is even worse since it is process-global.

The best workaround is to use [ThreadStatic] variables instead of Thread.GetData/Thread.SetData:
        [ThreadStatic]

        static Object foo;

[ThreadStatic] variables do not suffer from the contention issues. Moreover [ThreadStatic] variables are several times faster compared to Thread.GetData/Thread.SetData.

Your threads 28 30 31 32 33 34 36 40 42 72 78 86 87 90 96 97 98 104 106 111 113 115 131 blocked on the critical section 0x000cf0d0 which is currently owned by the thread 37, because of the global lock taken in ThreadNative::GetDomainLocalStore. The lock slows your threads to respond to the requests.

If it is your code that calls Thread.GetData/Thread.SetData, please replace the calls with ThreadStatic.
If it is Sharepoint's product code that calls Thread.GetData/Thread.SetData, this looks like a defect of the product, and you may check whether your sharepoint is having the latest updates/SPs. I'm not an expert of sharepoint. You can also try the sharepoint forum: http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/threads.


BTW, your perfmon log does not contain the counters that I requested:
Process/%Processor Time
Process/Virtual Bytes
Process/Private Bytes
.NET CLR Memory/All counters (To see how much time we are spending doing GC, how much memory is managed and how the ratio of Gen 0/Gen 1 and Gen 2 collections look)


Regards,
Jialiang Ge

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 6

Managed stack for thread 37 is below
144feffc 7c8285ec [HelperMethodFrame_1OBJ: 144feffc] System.Threading.Thread.GetDomainLocalStore()
144ff068 793d7a68 System.Threading.Thread.GetData(System.LocalDataStoreSlot)
144ff070 13c041ba Microsoft.SharePoint.Administration.Tls.get_Data()
144ff07c 13c03fbc Microsoft.SharePoint.Administration.SPFarm.get_ThreadContext()
144ff088 13c02eac Microsoft.SharePoint.Administration.SPContentDatabase.ValidateDatabaseSchemaCompatibility()
144ff114 13c0888c Microsoft.SharePoint.Administration.SPNativeConfigurationProvider.LookupSite(System.String, Int32, System.String ByRef, Int32 ByRef, System.Guid ByRef, System.Guid ByRef, System.Guid ByRef, System.String ByRef, System.String ByRef, System.String ByRef, System.String ByRef, Boolean ByRef, Boolean ByRef)
144ff450 79f35ee8 [GCFrame: 144ff450]
144ff5a8 79f35ee8 [ComMethodFrame: 144ff5a8]

Would not it mean that it's caused by SharePoint?

Answer 7

According to the callstack, I agree that it's most like a Sharepoint issue. Did you recently install any sharepoint SP or hotfixes? The knowledge of sharepoint is necessary to further dig into the issue, thus I suggested creating a new thread in the sharepoint forum.

Thanks
Jialiang Ge

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 8

Hi

Did you find solution to this issue? We are running into the similar kind of issue in Sharepoint.

---

Thanks & Regards Surendar