| Why debugging core/memory dumps on Windows is much more civilised than debugging on Linux |
[Wednesday 18th May 2011 at 9:01 pm]
Thomas
|
Reason #1: I can open a core/memory dump without having the corresponding executable.
Reason #2: I can get a complete library list from a core/memory dump without having the corresponding executable.
Reason #3: I can analyse a core/memory dump that came from a different system with different libraries without having to first get those symbols. In fact, I can analyse a core/memory dump without having to get *any* symbols.
Reason #4: I can specify an actual symbol path, that works, without having exactly match the directory structure on the system the core dump came from
Reason #5: Symbol servers. I don't even have to get the symbols myself - I can just tell Windbg "go grab symbols on-demand from these locations" and it Just Works.
Add all these reasons together, and it means that I can take a memory dump from a Windows 2003 server, open it in Windbg on my Windows XP desktop, and immediately be able to examine it. But I can't take a core dump from a Linux server running some random version and get anything remotely sane out of gdb on my Linux desktop. |
|
