WinDbg uses debugging information (pdb/symbol files) for debugging. So ,for example say I get a unknown exe (malicious) can I debug it since I'll not be having its .pdb
Yes. Symbols are one of Windbg's main strength, but it can also debug anything without symbolic information.
Is WinDbg best suited to analyze memory dumps and crash issues only?
Once again, it can do that, but that's not its sole use.
Ollydbg being a ring 3 debugger is good to analyze/debug malicious
exe's but doens't support unknown dlls(there is loaddll but you have
to know which function the dll exports and there parameters)
If you need to analyse a DLL, you'll need a program to load it and then debug this program, thus you can't debug a DLL by itself (DLLs, as their name imply are dynamic libraries used by a main program). That's a system requirement.
and rootkits(sys files).
Yes, you'll need a ring0 debugger.
You can also mix static (disassembler) and runtime (debugger) analysis for your DLL and driver (*.sys) file. Hex rays has a free version of IDA.
Both debuggers can be used for Ring3 (user-land) debugging, and only Windbg can do Ring0 (kernel-land) but they have their own strengths and weaknesses.
From my point of view (I'm using both a lot):
- Pros: great for displaying information to the end-user; Color schemes, Well organised displaying windows.
- Cons: symbolic information is minimal; no command line; GUI only
- Pros: extremely powerful with symbolic information; Ring0 debugging; windows internals; bare metal stuffs
- Cons: not really user-friendly; steep learning curve
They both have a native plugin system (C / C++); windbg have a scripting language which is a real PITA (but pykd [Windbg scripting in python] can alleviate this problem).
Note that windbg can't do in-place live ring0 debugging (à la Softice or Syser) except with "livekd" (but this works on a system snpashot, not live): you need a host system (the debugger) and another machine which will be the debuggee (either a virtual machine or another physical machine).