v0.8.4-alpha: startup fixes (mod switching itself off, and a frozen black screen)

Two testers, two different startup failures, both in the same 30 lines of code. v0.8.4 fixes both.

Neither of these was the motion-controlled weapon, the compiler, the runtime, or your PC. Both were bugs in how the mod attaches itself to the game's renderer at startup, and one of them has been in every release since v0.1.0. It only ever showed up on machines that reach that code in a slightly different order than mine does.

What was actually happening

To hook the game's renderer, the mod creates a tiny throwaway Direct3D swapchain, reads one function pointer out of it, and throws it away. Two things were wrong with that.

1. It built that throwaway on a window it does not own. Windows is allowed to refuse this, and on one tester's PC (Ubisoft Connect + SteamVR + Valve Index) it did, with E_ACCESSDENIED. The mod then correctly stood down and left the game completely alone, which is why his report was "nothing happens, I hear sound in the headset". The game was running perfectly. The mod had switched itself off. His log said so:

ERROR dummy swapchain creation failed: 0x80070005
ERROR cannot read the vtable, so no hooks installed. Game unaffected.
WARN  phase 2 hook NOT installed. Game continues unmodified (rule 7).

v0.8.4 creates its own hidden window instead, and if that somehow fails it tries two more routes and writes down exactly which one Windows refused and why.

2. It threw the throwaway away at the wrong moment. The mod was arming its render hook first and cleaning up second. On my PC that cleanup takes about 130 milliseconds and nobody ever noticed. On a second tester's PC it never finished at all, because by then the game's render thread was already inside the freshly armed hook, and both threads were waiting on the same Direct3D lock. That is a deadlock: a black screen you cannot navigate and have to force-kill from Task Manager. Which is exactly what he reported.

v0.8.4 cleans up before it arms the hook. There is no longer a window in which the two can collide, so this is removed rather than made less likely.

There is a third, smaller change that change 2 requires: the mod now pins the Direct3D module in memory before releasing its last reference to it. On both testers' machines the mod itself was the first thing in the process to load Direct3D at all, which is the difference that made these bugs visible on their PCs and invisible on mine.

Motion controls are unchanged and still on

The weapon still follows your right controller in position and rotation. That code is byte-for-byte identical to the build where it was first confirmed working in a headset, and it stays armed by default (wgun = 3, wgun_pos = 1 in grwxr.cfg). Nothing about it was disabled, reverted, or gated. If you never saw it work, it is because your session never got as far as starting VR at all.

Also in this release

• Your previous log is no longer destroyed on relaunch. It is kept as GRWVR\grwxr-prev.log. If you crash and immediately relaunch to see whether it repeats, the evidence you actually needed survives.
• Collect-Logs.bat ships in the zip and is copied into your GRWVR folder. Double-click it and it packages everything I need into one zip to attach to an issue.

Being straight with you

I do not have a headset on the machine I built this on, so v0.8.4 has not been confirmed in a VR headset by me. What I can tell you is exactly what was wrong, that both diagnoses came out of your logs rather than guesswork, and that the fixes are small and targeted at those two failures specifically.

If it still fails, the log is far more useful than it used to be: every route the mod tries now records its own error code, and the cleanup step now announces itself before and after, so a log tells us which line stopped instead of leaving a silent gap.

If you are updating

Run install.bat. It keeps your existing grwxr.cfg and merges in any new keys. If you hand-copy files instead, the game will not start, because the installer also places openxr_loader.dll and a copy of your own Windows dxgi.dll, and the game cannot load without both.

Reporting a problem

Please include three things, because together they separate every cause I currently know how to tell apart:

1. Your GRWVR\grwxr.log and every GRWVR\grwxr-<number>.log beside it. The game starts more than one process and the interesting one is often not the first.
2. Whether the game was running normally on your monitor, frozen, or gone from Task Manager.
3. Which headset and which runtime (SteamVR, Virtual Desktop, Steam Link, Quest Link).