Most of time, during the troubleshooting of an issue, it is requested to analyse a memory dump of our process.
Let’s try to understand what a memory dump is.
The easiest way to define a memory dump is to think about it like a "picture" of our process at specific instant of its life.
There are two kinds of process’s memory dumps: full dump and mini dump. The difference between them (as the name suggest) is the quantity of information stored inside it.
- A full memory dump stores all information concerning the virtual memory of our process: threads’ activities, stack objects, heap state, library loaded and so on. Basically we can say that every information concerning our process is there.
- A mini dump stores only a sub set of process information. Typically you can find there the threads’ call stack, some information concerning the process environment and nothing more.
How can you understand the dump typology: mini or full dump? Typically a debugger add this information on dump’s name, anyway I believe that the quickest way to understand it is by checking the file’s size. A mini dump typically is smaller than 1.5 MB. A full dump is as big as process’s virtual memory: typically some hundred of megabytes or some gigabytes.
As you can understand, to analyse what it is going wrong on our process it is better to have a full dump even if in some cases a mini dump could be enough.
The question is: how can I create a dump for my process? Well, there are a lot of different ways:
- Process Explorer
- Stating from Windows Vista, also from task manager. Right click on your process, create memory dump.
Typically at CTS we use a debugger to collect memory dumps. The first two items mentioned above are good examples of them and probably the most used debuggers. Since a dump is a picture of our process, a debugger is the camera that allows us to take the picture.