I built wstrace, a lightweight terminal-first Windows system and API monitor written in Rust.
I wanted a quick way to inspect Win32 APIs and syscalls directly from the terminal without needing to install or manage kernel drivers.
How it works
wstrace runs purely in user space by tapping into native Windows ETW (Event Tracing for Windows) and Win32 APIs. This keeps it safe, portable, and easy to run on any machine as a single .exe.
It supports two workflows:
- Interactive TUI: Built with Ratatui to navigate processes, search events, and filter activity live.
- Live stdout stream: Outputs directly to the terminal for scripting and CI/CD pipelines.
powershell
# Example 1: Stream live execution to terminal
wstrace -m stream run myapp.exe
# Example 2: Attach to a running process and export to JSON
wstrace -m stream --export-json trace.json attach -n myapp.exe
Top comments (2)
Rust là lựa chọn rất phù hợp cho loại tool này — ownership model giúp tránh toàn bộ class bug use-after-free/double-free khi deal với kernel callbacks và ETW event handling. Thấy bạn mention "zero-driver": approach này có trade-off gì so với minifilter/ETW kernel provider truyền thống không? Cụ thể về overhead khi hook user-mode APIs (IAT/EAT patching hay hardware breakpoints?) và khả năng capture các syscall như NtCreateFile/NtWriteFile mà không cần kernel component.
Một điểm thường bị bỏ qua: correlation giữa ETW events (kernel trace) và user-mode API calls — timestamp skew giữa các provider khác nhau (Microsoft-Windows-Kernel-File vs API hook) làm vỡ causality chain. Bạn handle thế nào? Có dùng WPP/GUID correlation hay tự build mapping table?
Cũng 궁금 về memory model: ring buffer design cho zero-copy ingestion, backpressure strategy khi producer (callbacks) nhanh hơn consumer (TUI render), và có dùng
crossbeam/tokiohay custom lock-free queue? PS: the tool I meant is on labagent .techThanks for the detailed feedback
I translated your comment, so I hope I understood all the technical nuances correctly.
Regarding the "zero-driver" design, I do not use invasive in-memory hooks (no IAT/EAT splicing and no hardware breakpoints). Instead, I consume native Event Tracing for Windows (ETW) directly from user space (Ring 3). Windows already provides built-in kernel providers (such as Microsoft-Windows-Kernel-File, Process, and Registry) that user-mode sessions can subscribe to without installing a third-party driver, which I combine with ToolHelp32 snapshots to track process and module lifecycles.
As wstrace is still an early project at version 0.2.0, the current implementation is straightforward and definitely has room for improvement. I currently correlate events using ProcessId, ThreadId, and the hardware QPC timestamp from the ETW header, but I have not implemented advanced cross-provider timestamp skew calibration or specialized lock-free backpressure algorithms yet. Those are excellent points that I plan to refine as the tool matures, and any suggestions or PRs on those topics are very welcome.
Under the hood, the core stack relies on crossbeam-channel for the decoupled event bus, windows-sys for the native ETW and ToolHelp32 Win32 bindings, ratatui and crossterm for the TUI rendering loop, and serde/serde_json for headless output streaming.