This is not always true. It is very easy to call correct code and cause it to crash, just because it expects correct data, but gets incorrect. Offen this is result stability/performance tradeoff.Also, don't get me wrong - dump is not silver bullet or magic wand, but what I'm trying to say that it is really powerfull tool for investigation of issues. In many cases it can provide you immediate answer to questions like "is that our code called module which crashed the FSX?". In cases where you can't get this answer immediately but have number of dumps for same issue very likely you will find something common in stack, memory addresses, or in loaded modules list. It is like asking customer questions you don't even thought to ask which he can't answer anyway, but you still getting those answers.Also, I don't suggest you to dig too much into dumps, because learning details can be really complex, but rather do all quick things you can do, like getting all stack, heap, modules, and other information. All you need to know to start is how to run analyzing scripts in windbg.exe.