Syscall tracing works well for debugging applications or pieces of one that interact externally, or for ensuring that the OS is doing what you think it should, but I've found that more often than not the buggy part is "inside"; e.g. if an output file is incorrect, you would be able to see the incorrect data being written to it via the OS (which would've been clear from inspecting the file itself), but not what lead to that.<p>Coincidentally, I prefer to use an Asm-level debugger (WinDbg, OllyDbg) whenever I need to use one - which for debugging something I wrote, is not very often. Maybe it has to do with the fact that I started with Asm and disassembling other programs, so it's relatively straightforward to map between source code and the instructions the compiler generated. This also helped with figuring out a very subtle compiler bug - I know that they're quite rare, but when they do occur, they tend to be <i>extremely</i> difficult to figure out otherwise.