If it's a kernal mode dump, it's usually a bad device driver. Saving room for a kernal dump, about 200M, allows you to open the dump file and determine the source of the crash. It's really quite easy to do and doesn't require extensive knowledge of debugging.
To determine the driver that caused a crash,
1. go to
to download and install the debugging tools.
2. launch windbg and set the symbol path to the symbol server.
3. Open the memory.dump file.
4. At the windbg command prompt, enter "!Analyze".
That's it windbg will analyze the dump and tell you the module that faulted.
A few months ago, I was getting blue screens on my new thinkpad. I took the dump file and did a !analyze to determine the faulty driver. It was ar5211.sys, the driver for the integrated wireless. I went to the IBM website and downloaded and installed the latest update for this driver. Issue resolved, and I didn't have to waste a lot of type rebuilding and restoring the laptop. Without updating the right driver, a rebuild/restore route would have been pointless anyway.
It may give you a warm and fuzzy feeling inside to stay up all night mindlessly rebuilding servers not knowing if that will resolve the issue or not; I'd rather determine the source of the issue so that my remediation approach will succeed with some degree of certainty.
Leaving 200M of the page file on C: at least leaves this option open.