vd-observer

Inspiration

VR streaming issues such as black screens, stuttering, stream drops, and unexpected exits are difficult to diagnose because the evidence is spread across Virtual Desktop, SteamVR, OpenXR, GPU drivers, Windows, and the network.

VD Observer was built to make those incidents easier to reconstruct. Instead of relying on memory after a failure, it creates a local observation session and records a timestamped timeline of verifiable runtime facts.

What it does

VD Observer is a lightweight Windows command-line observer for Virtual Desktop and related VR runtimes.

It can:

Discover and track Virtual Desktop, SteamVR, and Meta/Oculus-related processes
Sample CPU usage, memory usage, and thread counts
Observe TCP/UDP connection metadata changes for tracked processes
Record user-entered problem markers during reproduction
Save environment snapshots for Windows, hardware, and network adapters
Export a complete session as JSONL, JSON, and CSV files

The output is designed to be easy for developers, technical support, or AI-assisted analysis workflows to filter and correlate around the time of a reported fault.

How we built it

The project is written in Python and uses psutil for process, resource, and network observation.

Each run creates an independent session directory containing:

manifest.json for the collection scope, timestamps, and completion reason
environment.json for the local environment snapshot
events.jsonl for a unified event timeline
metrics.csv for periodic CPU, memory, and thread-count samples

The collector records UTC time, local time, and monotonic time so events can be compared reliably even during longer troubleshooting sessions.

Challenges we ran into

The biggest challenge was making the tool useful without becoming invasive. VR failures often involve sensitive system and network information, so VD Observer only records observable metadata by default. It does not inject into Virtual Desktop, modify its processes, proxy traffic, decrypt traffic, or upload logs automatically.

Another challenge was designing a simple event format that can combine process lifecycle events, resource metrics, network changes, and manual fault markers in one timeline while remaining easy to inspect and export.

What we learned

We learned that reproducible troubleshooting needs more than a crash report: it needs context from the moments before, during, and after the failure.

We also learned the value of local-first observability. Structured logs can make a complex VR streaming issue much easier to explain, share safely after review, and analyze consistently.

What's next

Planned improvements include Windows Event Log and crash-event collection, GPU and encoder metrics, VR runtime state collection, ring-buffer recording, a timeline UI, and redaction-aware export tools.