Memorymappingfile Leak Analysis Process

A recent project suddenly received an urgent problem report-the entire software suddenly crash out when the user was doing some critical operations. Fortunately, the product inherits the function of auto-fetch dump ...

  After you receive the dump, open it via WinDbg to view the corresponding callstack. Quickly navigate to the wrong thread. No map succeeded in calling MapViewOfFile () to cause crash.   Next, we need to know why the map failed? With Getlasterrorcode (), we learned that the process outofmemory caused the map to fail. MapViewOfFile () needs to map 512KB (4MB) of contiguous memory, and with the!address-summary command, we find that the largest contiguous block of memory in the system is 1.5Mb. Crash thus took place.    so far, we can be sure that the crash is due to memory leak causing mapviewoffile () failure. So, what's the leak? Looking back at the output information above, we can see that the memory used by mem_mapped uses up to 934mb,mem_private memory of 805Mb. Accordingly, we suspect that the memory mapped file used in the product may have a large number of leak.   Run command!address-f:mem_mapped, you get a similar output:  the third column, which is rgnsize, the size of the mapping window for the current MMF. Looking at this output, we found that the window size of 512kB files around 500, and the size of 256KB files 1800. Accordingly, we can lock these 256KB MMF files.   The question below, is, who mapped so many MMF files? There are different ways to do this in different projects. If you are familiar with the project data, you can first look at the 256KB by DD What is the content? Is there anything you are familiar with? If it's a string, it's easier to locate the problem.   Here, we assume that we're not familiar with the contents of the file, so we can't guess who created it. We can only take other measures.   The first column above the output, which is baseaddr, is the address of the map view. If we want to use the map view, we have to have the corresponding pointer pointing to the view. Therefore, we randomly selected a 256KB view of the baseaddress, and then through the following command to find who also pointed to the memory.    from this output we can see that there are about 10 places where the pointer address is saved. Next, we need to look at who, and the instance of those classes, also save these addresses. There are no other good ways to get around these addresses by using DDS commands to see ifThe symbol with the object.   After looking at multiple addresses, we found that there is an object that vftable to Cmmfserializer. This gives us a great deal of certainty: there are mmf! in the class name. leak!   Next, who did we target to create the Cmmfserializer object without destroying it? First, we get the virtual table address of the Cmmfserializer with the X command, so that we can search the heap for where these objects exist.   Then, run the!heap command, and you'll be able to see the addresses that have those objects. From our output we can see that a large number of Communicatorobj objects exist in the heap. This shows that the Communicatorobj objects have not been removed. As a result, we can conclude that communicatorobj leaks lead to so much MMF leaks, and very high mmf_private usage rates are so high. The rest of the work is simple, look at the code, analyze where the communicatorobj is used.