Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Leak #11

kevinkouketsu opened this Issue Nov 26, 2018 · 4 comments


None yet
2 participants
Copy link

kevinkouketsu commented Nov 26, 2018

I'm using your project to create a windows service. When any app of my company stop of respond (for a couple seconds) I need to send the .dump to my server via ftp.

So, basically, I'm using this code:

var dumper = new DumpWriter.DumpWriter(); dumper.Dump(app.Process.Id, DumpWriter.DumpType.MinimalWithFullCLRHeap, IntPtr.Zero, dumpFileName, false);
It grows approximately 20 mb to each generation of dump and never decreases.
Using the DumpType.Minimal option I do not have this giant growth but I have some growth as well.

I can't find the error on library or on my code. Removing the dump generation works well.


This comment has been minimized.

Copy link

lowleveldesign commented Dec 6, 2018

Could you check with VMMap snapshots where the leak is? At least to see if it's native memory or .NET memory. If it's in .NET please try making PerfView snapshots and compare them ( I will look at this issue but probably someday in January as December is really busy for me.

@lowleveldesign lowleveldesign added the bug label Feb 13, 2019


This comment has been minimized.

Copy link

lowleveldesign commented Feb 19, 2019

I collected a VMMap trace of a Minidumper instance and I can see that the leak happens in the Private Data memory:


I later collected umdh trace but most of the allocations seem to be happening in the IL_Stub generation for PInvoke, for example:

+   40000 ( 40000 -     0)      1 allocs	BackTrace119
+       1 (     1 -     0)	BackTrace119	allocations

	mscordacwks!operator new+30
	mscordacwks!std::vector<std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> > > >,std::_Wrap_alloc<std::allocator<std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> > > > > > >::_Insert_n+CA
	mscordacwks!std::_Hash<stdext::_Hmap_traits<unsigned __int64,DAC_INSTANCE * __ptr64,DacInstanceManager::DacHashCompare,std::allocator<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> >,0> >::_Check_size+9E
	mscordacwks!std::_Hash<stdext::_Hmap_traits<unsigned __int64,DAC_INSTANCE * __ptr64,DacInstanceManager::DacHashCompare,std::allocator<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> >,0> >::_Insert<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> & __ptr64,std::_List_unchecked_iterator<std::_List_val<std::_List_simple_types<std::pair<unsigned __int64 const ,DAC_INSTANCE * __ptr64> > > > >+156
	<no module>!???+0 : 7FF8CF286600 -> DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, UInt64, Microsoft.Diagnostics.Runtime.DacInterface.MethodTableData ByRef)

It looks to me as a problem in ClrMD. I found one issue which may be related (Microsoft/clrmd#47), but it was for leaking call stacks. However, symptoms are very similar. In a free moment I will have a look at the DAC interfaces we are using.

lowleveldesign added a commit that referenced this issue Feb 22, 2019


This comment has been minimized.

Copy link

lowleveldesign commented Feb 22, 2019

@kevinkouketsu, thanks for reporting this problem. It should be fixed in the latest release. More info here.


This comment has been minimized.

Copy link

kevinkouketsu commented Feb 22, 2019

I'm sorry not be useful with informations about the problem.
I'm glad you solved the problem and learn about using block with DataTarget

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.