Comprehensive pnsrad.dll/pnsovr.dll export tracer

Closed
  • Is something wrong?
#20 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp
Domain
devtools, reverse-engineering

Research direction

Start with docs/design/2026-09-21-mic-provider-voip-fix.md, echovr-reconstruction/src/pnsrad/Plugin/RadPluginAPI.h, and echovr-reconstruction/src/pnsovr/exports.cpp; then inspect the existing MinHook and HookGuard usage. Done means both DLL export surfaces are traced with the same structured format, including arguments, returns, and duration, while calls continue through to the real implementations.

Written by the indexing model from the issue text.

Description

backlog

Andrew: rather than discovering pnsrad.dll defects one feature at a time (mic
stub #15, the party-broadcaster-handle question in pnsrad_enabler.cpp),
build a comprehensive call tracer over both DLLs' full export surfaces so we
know everything they're relied on for, up front.

Design sketch

Reuse the existing MinHook + HookGuard mechanism already used throughout
this codebase — no separate forwarding DLL, no file renaming.

  • Every pnsrad.dll export (~33 unique functions; see
    docs/design/2026-09-21-mic-provider-voip-fix.md and
    echovr-reconstruction/src/pnsrad/Plugin/RadPluginAPI.h for the full,
    typed list) gets a MinHook trampoline: log name, typed args, return value,
    duration → the existing structured logger. Always call through to the real
    implementation — pure observation, never altered behavior. This is the
    "Fidelity Monitor" pattern the C++/mingw addendum already mandates for
    every translation layer ("log both input parameters and output results
    side-by-side").
  • Same treatment for pnsovr.dll's exports
    (echovr-reconstruction/src/pnsovr/exports.cpp), gated on it actually
    loading (-micprovider OVR, a machine with the Oculus runtime/headset).
  • Both traces use the same format, so a pnsrad run and a pnsovr run diff
    directly — showing exactly which pnsovr-era behavior pnsrad is silently
    not providing, across the whole export surface, not just whichever
    feature someone happened to test.

Why now, not blocking

Filed to capture the idea per Andrew's "we don't want to lose state"
convention. Does not block the in-flight mic provider fix (#15, PR #19,
which doesn't depend on this and has no unresolved design questions of its
own). Pick this up after the mic fix, or whenever the next pnsrad social
feature (Party/Friends/Users/Activities — see the unresolved broadcaster-
handle question in pnsrad_enabler.cpp's PartySendInviteHook) needs
investigating anyway.

🤖 Generated with Claude Code

Dominant language
C++
Stars
2
Forks
5
Avg merge
5h 8m
Merged PRs (30d)
911

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EchoTools/nevr-runtime

All issues in EchoTools/nevr-runtime

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.