It is very important to have some back ground on what was happening when the Memory Dump was taken.  This helps you detemermin which WinDbg commands to execute and provides you some context on how to interpret the output of those commands.

I wrote this article here which explain my favorite WinDbg commands.

I was reviewing a memory Dump from a server that was having performance issues.  I saw nothing in the memory dump running at all, this means that the process which was dumped was not the one having the problems or, the dump was taken from the wrong machine(?), yes it happens.

I was looking at the PERFMON logs from Server A and had a dump from Server B, the issue was happening in a Web Farm so this kind of log inconsistency can happen.  It is hard to find which server in a Web Farm is the specific one having the problem.

See, when you analyze memory dumps and you see nothing, then you start asking yourself questions and one of those questions is: is this dump taken from the server having the performance problem?  And to find that out you need to know the server name, and you find that out with this command, Figure 1.

!envvar COMPUTERNAME

Figure 1, how to find the server name in a memory dump

The help documentation that comes with WinDbg is a very good source to learn about WinDbg.  As seen in Figure 2, you can read in detail about what !envvar is and that it gets the value from the Exts.dll and is a dump of the ENVIRONMENT VARIABLES.

Figure 2, how to find the server name in a memory dump

Happy debugging to you!