What dk70 said. If the symbol path is configured that way, whenever the debugger encounters a new binary for which it must find symbols, it will:
1) Check first in C:\symbols. If a matching symbol is not found...
2) Check whether the symbol is available from the MS symbol server. If it is, copy it down to C:\symbols so it can be cached.
In practice, the MS symbol server will contain symbols for MS binaries (exe, dll, sys), but not for 3rd-party modules, obviously.
To have WinDBG attempt analysis of a crash dump, either a BSoD or a usermode process dump, simply open the dump via File | Open, or pass it as a command-line arg. The debugger will attempt to find the relevant symbols and it will then produce a diagnosis, to the best of its automated abilities. Look for a line like this in the output:
Probably caused by : win32k.sys ( win32k!FindTimer+57 )
If that references a non-default driver, the first thing to do is to update the driver. If that doesn't help and subsequent dumps all point at the same driver again, try removing it as a test.
In the example above, it's win32k.sys and that's a rather important system driver. When the "probably caused by" verdict points at an OS binary, the situation is far more complex and minidump analysis cannot always pinpoint the true cause.