Production debugging by analyzing crash dump is quite different than your regular every day visual studio debugging and therefore requires a completely different mindset. Here are the main considerations/limitations that you should always keep in mind when embarking on the route of dump analysis.
1. Memory dump is just a snapshot at the point in time when you capture it. If your application had an issue at time T1 and you take a snapshot at time T2, your process memory may have changed at T2 and therefore you might not be able to get to the root cause of problem. Make sure you are using right tool to take memory snapshot at right time. That been said, in some scenarios its really very tricky to take a memory dump at that right moment.
2. Even though Windbg is extrememly powerful, Visual studio is still your best friends. Don’t treat Windbg as a replacement of Visual Studio, primarily because in general finding a bug (or fixing it) via Windbg is more costly as well as time consuming to solve a problem as compared to effort needed with Visual Studio. Not to mention the learning curve of debugging via Windbg because its not just that you need to know Windbg commands but more so because you need to have a sound knowledge of windows/CLR internal data structures.
3. Always have an opn mind when you are performing this type of debugging. Depending upon the symptoms of the problem, you may or may not have an initial theory as to what is root cause of the problem. In case you have an initial theory about the problem, take it as a starting point and be prepared to drop this theory (and move to new one) as you analyze the dump file. Sometimes what you see in the dump file may be a false negative, it always help to have your mind open and explore other ventures.