I think this is something that should be understood far more - I've seen far too many developers basically give up when the execution of the code they're debugging goes into something they didn't write or an exception happens in there, and are shocked when I'll just keep on tracing in Asm. In fact for languages like C++ where a single statement can do a lot of implicit things, I prefer to debug in Asm since I can see exactly where things went wrong.
Maybe education is partly to blame, as many students are taught that the only thing they interact with is the source code, the binary being an opaque blob that comes out of a one-way process, and trying to go the opposite way is somehow seen as "wrong" (legal issues notwithstanding); the emphasis on low-level architecture and Asm as "you're not supposed to know this" further adds to the notion, along with the increasingly closed nature of software and hardware. Contrast this with those who grew up with early computers of the late 70s/early 80s, where it was almost second-nature to use a disassembler and analyse the firmware even without its source code (the source was usually Asm in those days, so you didn't miss much, but my point still stands.)
> I think this is something that should be understood far more - I've seen far too many developers basically give up when the execution of the code they're debugging goes into something they didn't write or an exception happens in there
Those other devs may be suffering from a kind of "appeal to authority" fallacy - they assume that this release-grade third-party code section must be correct.
Or, it may be that they know that even if the problem does lie in the third-party binaries, the only fix is to submit a bug report. Since a bug report with a comprehensive steps-to-reproduce is more likely to get addressed than one with an ASM trace, it makes sense to focus effort there.
Or, it may be that they're clock punchers/overworked, and tracing someone else's code jeopardises them leaving on time/shortening their "in" tray.
Maybe education is partly to blame, as many students are taught that the only thing they interact with is the source code, the binary being an opaque blob that comes out of a one-way process, and trying to go the opposite way is somehow seen as "wrong" (legal issues notwithstanding); the emphasis on low-level architecture and Asm as "you're not supposed to know this" further adds to the notion, along with the increasingly closed nature of software and hardware. Contrast this with those who grew up with early computers of the late 70s/early 80s, where it was almost second-nature to use a disassembler and analyse the firmware even without its source code (the source was usually Asm in those days, so you didn't miss much, but my point still stands.)