Memory dump files modes

Introduction

Sometimes when we are capturing memory dump file, diagnostic tools ask us which kind of memory dump file we prefer. Usually we have two available options:

• Full memory dumps 
• Minidumps 

Although this question was described in Internet for 1 million times, I would like to write my own explanation.
Another question is collecting memory dump files for x86 processes on x64 environment.

Full memory dumps vs minidumps.

The full memory dump contains the entire memory space of a process, handle table, images which are plugged to the process and other useful stuff, which may be used during the file analysis. Usually the full memory dump file is enough to handle issues related to the managed world (CLR).
The minidump allows to select parts of process to include do the memory dump file. So during the creation of minidump the set of information is configurable. It's obvious that we may collect the set so that the output doesn't differ from a full memory dump. Moreover, if we enable all the available flags, the produced memory dump will include even more info than full memory dump. So the name "minidump" doesn't actually reflect the nature of the dump.

More info about memory dump file kinds and modes can be found here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff560251(v=vs.85).aspx.

The first question that usually comes is what if we collect minidump with default flags and provide somebody with it for analysis. Well, the engineer will not be happy, because its capabilities will be significantly limited:

• Unable to resolve names for .NET methods (i.e. all Sitecore methods, mscorlib ones). This is because all the metadata info is located in memory space, which isn't included to the memory dump. The engineer will be able to see only addresses which may mean anything. 
• Unable to analyze heap. We will be not able to see heap stats (which are object and how may they take), generations contents etc. 
• Unable to view any object. Given this we are not even able to analyze the process state. 
• Unable to review the method implementations, extract assemblies from the memory. 

The second question is what if we enable all the available flags before capturing. Well, the /ma flag will be sufficient here. The only thing here is that not all the tools provide us with options to choose and usually the default set of flags produces pretty poor dump files.

Given all the info above it's strongly recommended to collect full memory dump files each time unless somebody explicitly asks to generate another kind.

Dump files for WOW64 processes

Well, refer to the article below to get very good explanation regarding this topic:
http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.aspx
The main point here is that x64 software should be rather able to collect memory dump files for x86 processes or we should use x86 version of software.
Here is a small list of software:

• Windows Task Manager – use different versions for different processes. 
• DebugDiag 1.2 – use x64 version any process. It properly handles both x64 and x86. 
• Procdump – use x64 version for any process. It properly handles both x64 and x86.