I will give Windows this

You have Event Viewer, Windbg built-in.

Windbg Preview blows away other debugging tools.

And then there's freeware "API Monitor". This thing is incredible, it's like a GUI for looking at all syscalls and COM events on every program without needing to explicitly debug.

The closest thing I could approximate it to would be something like BPF

http://www.rohitab.com/apimonitor

I'm (among other things) a Linux system engineer and an occasionally reluctant Linux plumber on my team. Debugging kernel panics / bluescreens is night and day between Linux and Windows.

I have a Windows gaming rig that I was getting BSODs on. It took about ten minutes to reconfigure Windows to write full crash dumps, get WinDbg set up, and determine where and what was crashing the system (bad display driver install - DDU and reinstall fixed it). There were plenty of guides as to how to get it set up and how to get it to pull Windows debugging symbols from the Internet. It was completely painless.

I have to keep a well-worn grimoire covered with notes and scribbles on how to get kdump working correctly to do the same sort of work on the Linux machines that I support - assuming that devops even set them up in the right configuration for kdump to work.

I also am a lifelong Linux user and prefer it to Windows.

But I have to hand it to Windows in this realm, despite how I might feel about other parts of it.

Linux has strace, valgrind/kcachegrind, eBPF, etc

And those tools are incredibly powerful, but have a far steeper learning curve and (personal opinion) UX than similar Windows tools.

I've used Windbg Preview to debug code written in niche languages like D and it's been able to sync source code from .d files and let me set breakpoints.

That really blew me away. I know that debug info is standardized in PE/COFF and in Linux with DWARF, but still.

Neat (at least I think so) screenshot of Windbg Preview debugging a D .dll with source synced:

https://media.discordapp.net/attachments/625407836473524246/...

The JS scripting is pretty wild too.

Repo full of them here. Example for generating a mermaid diagram image of callgraph, given a function name:

https://github.com/hugsy/windbg_js_scripts/blob/main/scripts...

(Material from a Defcon workshop by same author):

https://github.com/hugsy/defcon_27_windbg_workshop

I mess around with ~5 Linux boxes, so this is a small sample size, and also all my neighbors' Windows PCs.

Seems like the Windows PCs are more likely to show you a blue screen/crash than a Linux one.

Would that match your experience too?

My experience is that these days only hardware failures crash Windows.

A few years ago the biggest source of BSODs were the performance-optimised video drivers. That has thankfully improved a lot…

Honestly, not really. My Linux daily driver PC and Windows gaming PC are about equally reliable. The only recent blip for me has been with my Windows machine randomly crashing due to what turned out to be a bad RAM DIMM module.

My Windows PC actually seems to have video card problems less often, though I don’t really blame Linux here because they both have nVidia cards.

To clarify: WinDbg is not built-in in the literal sense (you have to download it separately), but it does come with a plenty of extension commands which lets you peek over Windows internals with ease (e.g. PEB, kernel process/threads, I/O Request Packets with all their Stack Locations, etc.). And it integrates with the operating system easily as a Just-In-Time debugger.

> WinDbg is not built-in in the literal sense (you have to download it separately)

I’m not sure about that. I think you downloading the GUI, not the debugger. The symbolic debugger engine is in DbgEng.dll and is included in Windows.

Perhaps we don't agree on certain terminology.

I would opine that a debugger in the usual sense is a software that interacts with both the end user (frontend) and the debugee program (debugging/tracing engine), allowing the user to study, analyze, and manipulate the dynamic execution of said program.

The debugger stacks on e.g. Linux and Windows are as follows:

- Linux: GDB, LLDB (frontend + debugging framework); libbfd, libdwarf (object file/symbol engine); ptrace (debugging/tracing engine)

- Windows: WinDbg, cdb, ntsd, kd (frontend); DbgEng.dll (debugging framework); DbgHelp.dll (object file/symbol engine); DbgUi*, Nt* syscalls, kd stubs (debugging/tracing engine)

I have a question: would you call gdbserver a debugger?

Modern debuggers are complicated. There’re good reasons to name all of these components “a debugger”. But I think the symbolic engine deserves the name “debugger” more than the GUI.

Note that in Windows, the GUI is the only piece missing from the default OS installation. The rest of the stack (DbgEng.dll, DbgHelp.dll, kernel calls, tracing, and more) is shipped with the OS.

> would you call gdbserver a debugger?

I’m not an expert on Linux. But based on this page https://www.tutorialspoint.com/unix_commands/gdbserver.htm probably not. I think it says that thing’s an IPC server which doesn’t do debugging on its own, doesn’t even need symbols, instead relies on the host to implement the actual debugger.

In Linux this would be like using one of the many tracing tools such as strace, and a dbus viewer.

API Monitor sounds like SnoopDOS.

Doing debugging work on macOS is actually not particularly difficult either; it’s just that very few people do so and the number of online resources is much smaller.

And Linux makes it even easier.

Pros and cons

Pros: no PatchGuard sh*t, complete source available

Cons: your out-of-box experience may vary depending on your distro

Not really. Almost every major distro comes with all those tools prepackaged.

I meant particulary debug symbols

Fedora/CentOS has -debuginfo for every binary package, while Debian seems to vary for each package