•   Posted in:
  • .NET

I was investigating some dead lock that happens in our application. Here is call stack of main thread:

ntdll!NtWaitForSingleObject+0x14
KERNELBASE!WaitForSingleObjectEx+0x93
clr!CLREventWaitHelper2+0x3c
clr!CLREventWaitHelper+0x1f
clr!CLREventBase::WaitEx+0x71
clr!WKS::GCHeap::WaitUntilGCComplete+0x2e
clr!Thread::RareDisablePreemptiveGC+0x18f
clr!StubRareDisableHRWorker+0x38
clr!COMToCLRWorker+0x19d612
clr!GenericComCallStub+0x57
SomeDll!SomeFunction+0x62
ntdll!LdrpCallInitRoutine+0x6f
ntdll!LdrpInitializeNode+0x1c1
ntdll!LdrpInitializeGraphRecurse+0x80
ntdll!LdrpPrepareModuleForExecution+0xc5
ntdll!LdrpLoadDllInternal+0x199
ntdll!LdrpLoadDll+0xa8
ntdll!LdrLoadDll+0xe4
hmpalert!CVCCP+0x67eb
KERNELBASE!LoadLibraryExW+0x161
KERNELBASE!LoadLibraryExA+0x31
KERNELBASE!LoadLibraryA+0x3f
0x00007ffa`0fec9ece
...
clr!ExecuteEXE+0x3f
clr!_CorExeMainInternal+0xb2
clr!CorExeMain+0x14
mscoreei!CorExeMain+0x112
mscoree!CorExeMain_Exported+0x6c
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

Ok, it looks like main thread is waiting for GC to finish. But what is GC doing? And it looks GC related code is here:

ntdll!NtWaitForSingleObject+0x14
KERNELBASE!WaitForSingleObjectEx+0x93
clr!CLREventWaitHelper2+0x3c
clr!CLREventWaitHelper+0x1f
clr!CLREventBase::WaitEx+0x71
clr!`anonymous namespace'::CreateSuspendableThread+0x10c
clr!GCToEEInterface::CreateThread+0x170
clr!WKS::gc_heap::prepare_bgc_thread+0x4c
clr!WKS::gc_heap::garbage_collect+0x1836b7
clr!WKS::GCHeap::GarbageCollectGeneration+0xef
clr!WKS::GCHeap::Alloc+0x29c
clr!JIT_New+0x339
...
mscorlib_ni!System.Threading.Tasks.Task.Execute()$##6003FAD+0x47
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)$##6003AEF+0x172
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)$##6003AEE+0x15
mscorlib_ni!System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef)$##6003FBA+0x231
mscorlib_ni!System.Threading.Tasks.Task.ExecuteEntry(Boolean)$##6003FB9+0xa1
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)$##6003AEF+0x172
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)$##6003AEE+0x15
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)$##6003AED+0x55
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart(System.Object)$##6003BFF+0x60
clr!Thread::intermediateThreadProc+0x8b
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

All other

I am working in software company and many sometimes we have some enterprise level companies as our clients. And sometimes we have problems with our software with some of these clients. Sometimes it is legitimate bug on our side. But very often there is conflict security software. And sometimes it is so painful to deal with, that I decided to write about.

Let say I bought and installed some software on my home computer. And then I found that it does not work. I contacted support and they asked me to temporary remove my security software to check that there is no interference with their software. I can do it and we quickly can confirm whether this was a problem.

  •   Posted in:
  • .NET

When I am working with WinDbg and .NET I usually using following command to load .NET support Dll into WinDbg:
.cordll -ve -u -l

But in case of .NET Core it does not work. It took me quite some time to figure out what to do. Firstly, install dotnet-sos tool into dotnet:
dotnet tool install -g dotnet-sos

Then activate dotnet-sos tool by execution this command:
dotnet-sos install

And this will copy support dll to C:\Users\<username>\.dotnet\sos\sos.dll, where <username> is your username on this computer. These two commands you need to execute only once per .NET Core version or after tool is updated.

And lastly to load this dll into WinDbg, execute this

How to get to Exception object in .NET when native code calls it

Few day ago, I did investigate crash dump where .NET code raised some exception. Some .NET code called from native host using COM interface. .NET wraps such calls in try catch and return proper HRESULT to caller in native code in case of exception. In my case that .NET method failed and return failed HRESULT. Then due to unforeseen design issues, native code crashed and as result Windows created crash dump and terminated process.

Normally in most native languages when exception is raised, exception object of some kind is created and when exception handled somewhere, this object is destroyed and after that there is no way to