4 ms·

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". Th

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 http://www.rohitab.com/apimonitor

oshiar53-0 5y ago
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.
- Const-me 5y ago
  > 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.
  - oshiar53-0 5y ago
    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?
    - Const-me 5y ago
      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 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.
sys_64738 5y ago
API Monitor sounds like SnoopDOS.
29athrowaway 5y ago
In Linux this would be like using one of the many tracing tools such as strace, and a dbus viewer.
phone8675309 5y ago
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.
- BenjiWiebe 5y ago
  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?
  - jiggawatts 5y ago
    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…
  - phone8675309 5y ago
    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.
- gavinray 5y ago
  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/831606636204392448/unknown.png 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/CallGraph.js 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 https://github.com/hugsy/defcon_27_windbg_workshop

oshiar53-0 5y ago

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.

Const-me 5y ago
> 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.
- oshiar53-0 5y ago
  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?
  - Const-me 5y ago
    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 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.

sys_64738 5y ago

API Monitor sounds like SnoopDOS.

29athrowaway 5y ago

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

phone8675309 5y ago

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.

BenjiWiebe 5y ago
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?
- jiggawatts 5y ago
  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…
- phone8675309 5y ago
  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.
gavinray 5y ago
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/831606636204392448/unknown.png 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/CallGraph.js 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 https://github.com/hugsy/defcon_27_windbg_workshop