hey there how are you guys doing i'm going to show you a simple technique in windy bug to detect dot net memory leaks okay let's get into it so i have loaded up wind debug with a memory dump that contains a memory leak i have written a program in which i've created a whole bunch of objects and i've just let it linger in memory and i've taken a memory dump of that computer program to illustrate the problem that if you have a net memory dump with a memory leak how do you find these objects so i have put the source code for this program on github if you would like to look at it it's only a couple of lines of code you don't really need to look at it it's just used to illustrate the problem of how to find objects in net memory dumps now technically you can't have a memory leak in net that's true what we are talking about when we say memory leak are objects that have references to them but we don't know that they exist this often happens due to the way dotnet works where certain things like events certain things like certain kinds of references are really complex to decipher in code and so objects linger even though we think that they should have been removed so i'll show you a technique how to just search through the memory find these objects find the roots and prove that these objects are really the leaks that are appearing when we look at the memory of the program okay so let's get started so the first thing you want to do is you want to ensure that you have symbols configured you can check out my video in the playlist below where i have a short video on how to set symbols but you can also just google how to set symbols i'm going to skip this for this video we don't really need to go through that but you must have your symbols loaded because in a net memory dump the symbols are very important in order to decode the net objects so let's start so the first thing i'm going to do is i'm going to type load by sysclr so what this does is it loads the sos plugin which we are going to use to decode.net you can google on the internet what exactly is the sos plugin i have a video in this playlist in which i use the sos plugin to do net memory debugging do check it out if you want to learn more about sos plugin i'm gonna use it in order to dump memory so the first thing we're going to do is we're going to type dump heap minus stat okay so what dump it minus stat does is that it builds a histogram of objects and it gives you the count and the size of the total number of objects in memory we are going to use this to try to find our memory leak so what we are going to do is we are going to look through this list and we are going to find objects that are have an excessive high count or an excessive size one one of the two i have conveniently named uh the leaking object in this memory dump as uh leaky data now the reason i did that is so that i could spot it really easily but you might not have the luxury of having a very descriptive name for the object that's leaking however to show you this technique i chose to do it this way in real life you probably are looking for an object that is um that you have a count that is really really excessive or a size that is really excessive and it may be really difficult um i will make a video in future about how to target and find those objects using more advanced techniques but for this video i'm just going to stick to this line of reasoning where you kind of spotted that you have an object in memory that is it is not supposed to be there and we're just going to drill down and find what is the root of that object i'm going to give it a start with leaky data so what i'm going to do is i'm going to click on the first row this is the method table so what the method table does is that it is the description of what this object is in memory i'm declared this as a class so the method table type would be class when i click on it what wind debug does is wind debug runs a command what it does is it runs dump heap slash d uh the method table and it gives the address of the meta table and what it does is it dumps out every single instance of this object in memory what i can do with this is i can see all the instances i can click on one of them like a sample so i'm just going to click on on one of these objects and what it's going to do is it's going to dump object and dump out the body of that object what i did i created uh two properties for this object one called some data and another called some event so it's going to show me the value of some data and some minute some event uh that's not really important for now what i want to do is i'm going to take this memory address right here and i'm going to do a command called gc root so what gc root does is that it takes the memory address of the object and then it walks it backwards to see what is the originator of this address it will stop at the first memory address created by the app domain in my case it will be the object leaky app so leaky app is the main so what it's saying here is leaky app domain owns leaky data the array which owns leaky data inside the array so one unique route that means that this object is alive it won't get garbage collected okay so what i'm going to do is i'm going to run dumphip minus stat again and i'm going to choose a different object to show you a different gc handle so i'm going to choose the event handler now the reason i'm going to choose the event handler is because usually when objects are lingering longer than they should it's probably something to do with an event handler so i'm going to show you a sample so if i dump out the event handler same thing it's going to show me the instances of each i'm just going to pick one as a sample and the event handler for this object over here which is my leaky handle i'm going to do the same thing i'm going to gc root the event handler and what it shows me is that leaky app owns leaky data the array that owns instances of leaky data and each leaky data owns one event handler and the target of the event handler i'm going to click here and i'm going to get the target of the event handler over here and i'm going to gc route it and you will notice that the event handler is owned by the system event handler so this pattern of an object owning an event handler which is owning a leaky event handler over here this is a very common pattern when you have memory leaks to do with event handling so if i walk deeper into this i will find that the number of subscribers and the number of subscriptions to the event handler will just keep growing and this is one of the most common pattern that you have for why objects are leaked so once we have seen the gc route the technique to find memory leaks is actually just doing this over and over again if you are able to pick an object which you know is causing a problem and you're able to get the roots you will be able to see all the roots here and make an intelligent decision whether that's the cause of the memory leak there is no real way in wind debug to say this is a leak versus an object that genuinely should exist but this is probably better than nothing try to guess what the object is there is a few more things we can do so there is another command you can use called ee heap and what ee heap does is that it dumps out the total amount of memory in the uh various heaps that dotnet is using i won't cover this that much in this video this is a bit more complex where you'll have programs where you don't even know whether it's a net memory leak i'll go through this in a future video it's a bit more advanced um but there's also the concept that the different generations of dot net um have different size heaps so in a nutshell what happens is that in dot net dot dotnet makes three heaps in order to allocate memory which is generation zero one and two and objects that survive garbage collection move up the generation there is another heap called the large object heap where objects that are bigger than a certain size they go inside that heap if you gc route those objects they work the same way as any other object it will show you the route so if you find objects in the large object heap that is too large then you can actually gc route and find out where the route is [Music] in.net if an object has been marked by the garbage collector as safe to clean up but the object has a finalizer on it then the object won't be cleaned up until the finalizer has completed if you suspect that there are a lot of objects that are being finalized but they have not completed you can actually check the finalizer queue by just running the command finder live queue and i think it's finalized q and what will happen is that it will dump uh all the objects that are safe for final for cleaning up but their finalizers have not completed if we gc route these objects they will say that the objects are aligned and they are alive not because that their references are valid is because their finalizers have not finished so i'll show you an example of that i'm just going to dump the first object that i see over here so it is a save file mapping handle so i'm going to dump out this object right here and i'm going to uh gc route this object there we are so our gc rooted this object and um we will see something a bit interesting this object is held by the uh sb uh sbcs code page encoding which is held by a stream reader but the thing is that this is not being held by the app so what has happened is that i'm gonna put all at the back up sorry all in front [Music] there we are i don't know why you gotta put all in the front so what's gonna happen is that it's gonna dump out all the uh the roots and we're gonna see that the roots are not being held by the app this means that this object has been marked for garbage collection but its finalizer has not completed so those are some of the techniques that are used to find memory leaks i will go in depth with the e-heap in a future video and probably also a video on how to debug the large object heap the large object heap is it's just a heap but it usually contains objects that are far larger so they're usually arrays or strings so i thought it'd be a bit more it's a bit more complex than trying to debug just regular objects but this is the technique i use let me know in the comments below if you know this technique let me know if you want more videos on net debugging and definitely let me know your thoughts on this video tell me what you liked what you didn't like subscribe if you haven't already that lets me know what kind of videos to make that lets me know how much people like these videos uh give me a thumbs up that tells me if i'm doing a good job give me a thumbs down if you think it's bad it's up to you definitely leave me a comment let me know what you think and give me topics to that you want i will be making a topic about the ee heap but just let me know what other kinds of debugging videos you like well until next time i'm hi voice signing out [Music] you