If you're in the IDE running SOS, you're running in Debug mode. Strange
things happen in debug mode with regard to object lifetimes and GC. Given
that you're nulling out the reference, I find it hard to accept, but it
*could* be part of the problem. I'm reaching though, I admit.
You may want to try compiling in release mode, running your app, generate a
dump, and then load that into WinDbg / SOS and poke around that way.
As a quick aside, there is a better tool for debugging this than !gcroot.
I've been really happy with sosex.dll, as it's made doing this stuff in
WinDbg much easier:
http://www.stevestechspot.com/SOSEXANewDebuggingExtensionForManagedCode.aspx [John Robbins talking about it]
http://www.wintellect.com/cs/blogs/jrobbins/archive/2007/06/19/great-sosex-a-phenomenal-net-debugging-extension-to-see-the-hard-stuff-steve-johnson-is-my-hero.aspx --
Chris Mullins
[quoted text, click to view] "AJ" <noone@nowhere.com> wrote in message
news:MPG.20fc3f80a06d03c39896ad@news.zen.co.uk...
> I'm trying to locate a memory leak..
>
> I've a test app which creates an instance of a big class, null's the
> reference, then calls GC.Collect() a few times in an attempt to clean up
> any memory. Thus, in thory, I don't think my instance should exist
> anymore.
>
> I use SOS (within the IDE):
>
> !name2ee gives me the method table for my class
> !dumpheap -mt xxx -> lists the object instance that I think should have
> be GC'd
> then !gcroot <instance address> to look to see what's still holding it.
>
> The only root displayed starts:
>
> DOMAIN(0014C278):HANDLE(WeakSh):9f127c:Root:0141538c
> (MyNamespace.SomeOtherClass)->
>
> which I thought meant that this was a weak handle that won't be keeping
> the instance alive.
>
> Am I misunderstanding how gcroot works?
>
> If I then "!gcroot 0141538c" I get a pinned object[] root (which is
> probably the overall cause of the problem, therefore), but why doesn't
> this one show up when I gcroot the original class instance?
>
