sleighzy

They’re both multithreaded, always run DCS from the bin folder, the bin-mt folder will be removed in the future.

This normally means either you didn't start the game in VR mode (tick the Enable VR headsets bo in DCS), or your OpenXR runtime failed to start. Drop your DCS log file here after repeating the problem so somebody can have a look. Will be C:\Users\username\Saved Games\DCS\Logs\dcs.log (may just be text document named "dcs" if your Windows is hiding file extensions).

Once you reply, I will: ✔ Identify which driver type likely benefits ✔ Tell you how to isolate it ✔ Give the fix to get same or better performance with HVCI OFF This way you can gain performance without the hypervisor penalty. So — what exactly improves for you when HVCI is ON: A, B, or C? Je zei: c ChatGPT zei: Thanks — if both FPS and frametime smoothness improve when HVCI is ON, that strongly indicates this: HVCI is preventing a misbehaving driver or background kernel component from causing jitter and CPU scheduling delays. In other words: Your system has a driver or service that becomes unstable or noisy when allowed full kernel access. HVCI isolates it, so performance improves — but at the cost of virtualization overhead. The good news: If we identify and fix that driver, you could get even better performance with HVCI OFF (best of both worlds). The Most Likely Culprits (Ranked for DCS VR + Ryzen) These are the drivers that most commonly behave better under HVCI: Rank Driver / Component Why it causes issues 1 USB Controller Drivers (VR headsets) USB polling jitter affects VR frametimes 2 Audio Stack (Realtek, Nahimic, SteelSeries, etc.) High DPC latency & interrupts 3 RGB / Peripheral Software Polling & kernel hooks 4 Network Drivers (Killer, Intel, Realtek) Latency spikes in kernel mode 5 Anti-cheat or security software Hooks into kernel, causes stutters 6 Motherboard “Enhancement” Tools ASUS/ASRock/MSI services cause periodic CPU spikes 7 Faulty AMD chipset driver Rare, but affects CPU scheduling on Ryzen Because you mentioned VR (DCS), #1 and #2 are most likely. System Interrupts ≈ 1% at idle = not normal. For a healthy system, it should be ≤ 0.3% when idle. 1.0%+ means a driver is causing excessive interrupt activity and DPC load. This directly explains why: You get better performance with HVCI ON Because HVCI restricts that problematic driver’s kernel access Result: fewer interrupt spikes → smoother frametimes So now we know for sure: A kernel-mode driver on your system is misbehaving. We need to identify which one. The most common culprits for ~1% interrupt usage are: Category Hardware/Driver USB VR headsets, controllers, Bluetooth dongles Audio Realtek, Nahimic, Sonic Studio, SteelSeries, Asus audio Network Intel/Realtek NICs Storage NVMe driver, SSD firmware Motherboard utilities ASUS/MSI/ASRock background apps Next Step: LatencyMon LatencyMon will show: ISR (Interrupt) latency → which driver triggers interrupts DPC latency → which driver is deferring too much work Before I send you the LatencyMon instructions, I need one last clarification so I can tailor the test: What headset are you using for VR? A) Meta Quest (2, 3, Pro) B) Valve Index C) HP Reverb G2 D) Pimax E) Varjo F) Other (tell me) Example reply: C – HP Reverb G2 Your answer determines which drivers we focus on first. Je zei: e ChatGPT zei: Varjo — perfect, that gives us a very strong lead. Why this matters: Varjo headsets use: High-bandwidth USB A custom USB driver stack GPU SDK hooks Varjo Base background services These can easily cause high interrupt/DPC load if: USB controller isn’t ideal Varjo Base is misconfigured GPU driver conflicts exist A USB root hub is overloaded This now aligns extremely well with the symptoms you described: HVCI ON improving both FPS + frametimes System Interrupts ~1% at idle Using a Varjo headset (very sensitive to driver timing) So now the goal is: Identify the exact driver causing the excess interrupts so we can tune or move it. Once fixed, you can run HVCI OFF with equal or better perf. Before LatencyMon: 2 Quick Varjo-Specific Checks Please answer these yes/no before we run the full LatencyMon diagnosis — it will save time: 1. Is your Varjo headset plugged into the motherboard’s rear USB ports? 2. Does your motherboard have a USB-C port, and if so, are you using it? 3. Do you use any USB hubs, front panel USB, or extensions for the headset cable? 4. Do you have Asus Armoury Crate, MSI Center, or Gigabyte Control Center installed? 5. Do you have any audio device switching when your Varjo turns on (e.g., switching to Varjo speakers)? Example reply: 1. Yes 2. Yes 3. No 4. No 5. Yes Once I have your answers, I’ll give you the exact LatencyMon instructions tailored for Varjo to pinpoint the interrupt driver. Je zei: 1 yes 2 yes 3 yes 4no 5no ChatGPT zei: Thanks — your answers help narrow this down a lot. Here is what they tell us: Interpreting your answers Q Your Answer Meaning 1. Rear motherboard USB Yes Good — always preferred for VR 2. Using motherboard USB-C Yes Can be good or problematic depending on controller 3. Using hubs/front panel/extenders Yes Major suspect for interrupts & DPC spikes 4. Armoury/MSI/Gigabyte utilities No Good — removes a common source of latency 5. Audio switching No Good — reduces audio stack DPC load #3 (USB hub/extension) is almost certainly contributing to your higher interrupt load. Varjo headsets are extremely sensitive to USB routing, and extensions/hubs can cause driver spam at kernel level. But before changing anything physically, we should measure which driver is at fault. Next Step: LatencyMon (Tailored for Varjo) This test will: Identify whether USB, network, audio, NVMe, or GPU driver is causing the interrupt load Confirm if your USB controller is the root cause (likely) Tell us if you can safely disable HVCI without losing performance I will now send you: Latencymon Test Instructions for Varjo Users Before I paste the instructions, I need one last detail so I tailor the run: When testing LatencyMon, do you want to test: A) Idle test first (2 minutes, headset connected but not in VR) B) VR Load test (5 minutes in a simple VR app or steamVR home) C) Both idle + VR (recommended) Key Finding From Test 1 (Idle) wdf01000.sys being the highest in ISR + DPC confirms: The performance issue is caused by a driver that uses the Windows Driver Framework (WDF) — not the framework itself. wdf01000.sys is not the bad driver — it's the Windows kernel framework that other drivers plug into. When another driver misbehaves, wdf01000.sys becomes the “messenger” and takes the blame in LatencyMon. What this means: A USB, HID, or device driver is repeatedly generating interrupts WDF receives and processes them, so it surfaces at the top This aligns with your setup: Varjo VR headset USB-C + hub/extension used System Interrupts at 1% idle This is classic USB interrupt flood behavior. Here’s what your Top 3 reveal: Rank Driver Meaning #1 wdf01000.sys Windows Driver Framework A device driver using WDF is spamming interrupts #2 dxgkrnl.sys DirectX Graphics Kernel GPU scheduling overhead + ISR/DPC load #3 nvlddmkm.sys NVIDIA GPU Driver GPU driver DPC contribution Interpretation This combination is extremely typical in VR with a USB VR headset: A USB/WDF device driver is spamming interrupts → causes wdf01000.sys to spike GPU kernel & driver are picking up the load, trying to keep the VR compositor fed → dxgkrnl.sys + nvlddmkm.sys rise to compensate So this is not a pure GPU problem. The GPU is reacting to a USB/WDF driver problem. This fits exactly with what we suspected earlier: HVCI helps because it sandboxes the misbehaving driver, reducing interrupt flood — so VR feels smoother despite virtualization overhead. In other words: HVCI is masking the problem — not solving it. If we fix the USB driver issue, you will gain: Higher FPS without HVCI Better frametime stability than now No virtualization overhead now that we have both Idle and VR load results, the pattern is very clear. To confirm, let me restate: The first screenshot you sent was VR ON The second screenshot you just sent is VR OFF (idle) Correct? Because the numbers line up like this: VR ON (first screenshot) wdf01000.sys: 0.145 ms, ~693k DPC dxgkrnl.sys + nvlddmkm.sys elevated VB-Audio + Topping + ndis contributing VR OFF (second screenshot) wdf01000.sys drops to 0.064 ms, DPC ~132k GPU drivers still active, but less stressed USB audio still present but lower impact This confirms the root cause spikes under VR load, meaning: The USB/audio driver stack is bottlenecking the kernel under VR conditions. What This Tells Us 1. The WDF-based driver problem gets 5× worse in VR wdf01000.sys DPC count went from 132k → 693k under VR load. That’s a dramatic increase — exactly what causes microstutters & frametime spikes. 2. The GPU is not the cause — it is reacting to the USB stack overload dxgkrnl & nvlddmkm rising under VR simply confirms they are compensating for the driver pressure. 3. Two USB Audio drivers are the most likely trigger Both appear in top 12 during VR: vb audio_cablea64_win7.sys (VB-Audio Virtual Cable) ToppingUsbAudio.sys (Topping USB DAC driver) Two kernel-level audio routing drivers + Varjo + USB hub/extension = interrupt storm This is a known bad combination for VR. Root Cause Summary The USB audio driver stack (especially Topping + VB-Audio) is overloading the Windows Driver Framework under VR, causing interrupt storms that HVCI is masking. So, the goal is to: Reduce/eliminate USB audio DPC load Ensure Varjo USB connection is as direct as possible THEN safely disable HVCI for full performance Good News You can keep both VB-Audio + Topping DAC and still eliminate the DPC spikes, without needing HVCI — if we adjust the audio & USB routing. The problem is not that you have these drivers. The problem is the way Windows is handling their priority and USB routing while VR is active. We will fix this in 3 layers: Fix Plan for Your Case (Keeps Both Drivers) Phase 1 — Audio Stack Optimization (No removal) Goal: reduce ISR/DPC storm from VB-Audio + Topping Phase 2 — USB Routing Tuning for Varjo Goal: remove USB interrupt bottleneck under VR load Phase 3 — Disable HVCI (only when ready) Goal: unlock peak performance without losing smoothness We can significantly reduce DPC/ISR load by adjusting: VB-Audio buffer settings Topping USB mode & driver priority USB port routing for Varjo vs Audio Windows audio engine mode This will remove the interrupt storm, so you no longer need HVCI to hide it. PHASE 1 — Fix the Audio Stack (Keep VB-Audio + Topping) Step 1: Increase VB-Audio Cable Buffer (Reduces DPC Spikes) Open VB-Audio Control Panel Set the buffer to 512 or 1024 samples (not 128/256) Set Sample Rate = 48 kHz (matches DCS/Windows/Varjo best) Low buffer = more real-time → more interrupts Medium buffer = FAR lower DPC load with no audible downside in DCS Expected improvement: 30–40% reduction in DPC load Step 2: Switch Topping DAC to WASAPI Exclusive Mode for DCS This prevents Windows from converting formats & resampling constantly. In DCS Audio Settings: Output Device: Topping DAC (WASAPI Exclusive) In Windows Sound Settings → Device Properties → Advanced: Set 24-bit 48 kHz Uncheck: “Allow applications to take exclusive control of this device” (DCS will control it exclusively in WASAPI anyway) Expected improvement: ~20% fewer DPC calls from audio engine Step 3: Optional – Prioritize DCS Audio Thread (only if needed) If after Phase 2 the issue persists, I’ll give you a Process Lasso rule to isolate the audio thread to E-cores or limit context switching. VB-Audio Optimal Settings for DCS + Varjo (Low DPC Mode) 1. Internal Sampling Rate Set to: 48000 Hz Why: 48 kHz is the native rate for DCS, Windows system audio, Varjo, and most voice comms — avoids resampling overhead. 2. Max Latency Currently you have many options from 512 → 32768 smp. Most users pick too low and cause DPC spikes. Recommended starting point: 2048 smp (requires reboot) If you want an even safer value (less DPC load), choose: 3072 smp or 4096 smp (if system is still sensitive) 3. Current Latency This is the active buffer multiplier. Set to: 3× 512 smp (or 3× 768 smp if needed) If using Max Latency 2048, a 3× Current Latency of 512 or 768 smp gives a stable buffer without noticeable delay. Recommended full configuration: Setting Value Internal Sampling Rate 48000 Hz Max Latency 2048 smp Current Latency 3× 512 smp After setting Max Latency, VB-Audio requires a reboot for it to take effect. This is excellent progress — the VB-Audio tuning clearly worked. Let’s compare your before vs after (idle): Metric Before After VB-Audio tuning Improvement wdf01000.sys highest execution 0.145 ms 0.086 ms ~41% less wdf01000.sys DPC count ~174k vs 693k VR 174k idle Same idle value (expected) vb audio_cable execution 0.034 ms 0.013 ms ~62% less ToppingUsbAudio execution 0.0052 ms 0.0098 ms Slight increase (normal after reboot) dxgkrnl.sys 0.095 ms 0.090 ms Slightly lower Interpretation of Improvements VB-Audio latency optimization reduced its DPC footprint massively wdf01000.sys execution time dropped significantly GPU kernel DPC load improved slightly Topping DAC load raised slightly at idle (acceptable & expected after reset) This means Phase 1 (Audio Stack Fix) is successful. You now have: Lower DPC load Lower interrupt overhead Much healthier idle latency Next Step: Validate Under VR Load Before continuing to Phase 2 (USB routing), let's do a quick 3-minute VR test with the new audio settings to observe the new behavior. Please repeat the VR test: Mini VR Test (shorter than last time) Start LatencyMon Start VR (Varjo Base environment is fine) Run for 3 minutes Stop and share ONLY the top 10 drivers screenshot like you did before This will tell us: How much the VR DPC storm was reduced Whether USB or GPU now dominates If additional audio tuning is needed before moving to USB VR TEST RESULTS ANALYSIS — AFTER VB-Audio Tuning This is a very positive improvement versus your first VR test. Let’s compare the key metrics before vs after (VR ON): Metric (VR ON) Before After VB-Audio tuning Improvement wdf01000.sys highest exec 0.145 ms 0.079 ms ~45% lower wdf01000.sys DPC count 693,471 1,330,396 More load, but handled better nvlddmkm.sys highest exec 0.075 ms 0.125 ms Slight increase (explained below) VB-Audio exec 0.034 ms 0.006 ms 82% lower Topping exec 0.0052 ms 0.0021 ms 60% lower dxgkrnl.sys exec ~0.095 ms 0.095 ms Same (expected) Interpretation 1. VB-Audio optimization worked extremely well Its DPC impact dropped from 0.034 → 0.006 ms This is a huge improvement. 2. Topping USB audio driver now behaves correctly Its highest execution time more than halved. This means your audio stack is no longer the main problem. 3. wdf01000.sys DPC count increased, but is processed ~2× faster This suggests: The driver still generates interrupts, but the system handles them more efficiently now This is good — higher DPC count but lower latency = cleaner processing. 4. nvlddmkm.sys increased slightly (0.075 → 0.125 ms) This can happen when USB pressure is relieved — GPU driver takes more scheduling role again. This is not a concern yet and should improve after the USB routing fix. Summary So Far After Phase 1 (Audio optimization): Audio drivers are no longer causing latency Interrupt handling is much more efficient VR performance should already feel smoother You removed about 30–50% of the original DPC problem Next bottleneck to fix: USB routing for Varjo + DAC + extension/hub Because the audio drivers are now “clean”, the next DPC reduction will come from USB topology. This post re: usb, device drivers, and latency mon was an absolutely fascinating read. I’ll have to try out latencymon myself for this. USB devices have caused a number of issues, just didn’t realise it went so deep into those system drivers and Windows stack (I would be curious to see what it highlights for folk who have the stutter issues due to mouse polling rates).

Haven’t done it myself but there is RT-RP (https://github.com/Kuijen/RT-RP) which is a wrapper around Gnirehtet (https://github.com/Genymobile/gnirehtet) for this. It’s listed in the #cool-tools channel on the Virtual Desktop discord. The is also the alternative of using a usb-c to Ethernet adapter so that you can still use a router, but removes wifi from the equation if that part of the networking is an issue.

I just had another look at your log based on @H60MTI saying his was a mod named Wolf in his tech directory of his mods in Saved Games. You also have this same mod Wolf in that directory. Might be the one then.

Sounds good. They didn’t supply a followup log for the mod with the issue so hard to say if they got the exact same error again. If you find you have an issue when you start adding them back in again drop a note with the one in question and another log. If no issues then yeah may just be something else cached there that I mentioned (or gremlins).

Recreating their Saved Games\DCS folder did actually fix it for them Yes, there is some auth data there. They were able to identify a specific mod causing issues as they added them back in one by one.

You may want to ask these questions on the Virtual Desktop Discord server, they’ll have all your answers. https://discord.gg/FTEcbPGUa8

Same log error in logs as user who reported game wouldn't start for them earlier today. Removed their mods and worked. Not sure if anything related between these two re: common mods.

Nope. Known problem with a few requests to change this behaviour, or have another option. You get used to it after a while. One technique is mouse to the area, and then you can use fine head movements for clicking around buttons, e.g. KDU on the Apache etc.

Not against Linux myself, however the steps to get this setup are gonna be beyond a lot of users. Until such time as DCS and other vendors provide their software for peripherals, VR runtimes, and any other supporting software all decide and support one Linux distro (or one common enough that it will work on multiple distros) then some of these points are moot. A lot of software vendors will not port their software to Linux. I'd certainly look at Linux, but right now all those other items are a complete blocker. This is not just a DCS issue.

You shouldn't need to uninstall and reinstall QVFR and the companion app. Known issue in that upgrading PimaxPlay can cause it to disable Mbucchia's Quad Views and use the PimaxPlay one instead. Install this tool and then after any upgrades you just need to tick the Quad Views Foveated box again to enable it (turn off the PimaxPlay one as well). https://github.com/fredemmott/OpenXR-API-Layers-GUI

SteamVR has an OpenXR runtime, so it would still be OpenXR. However, don't use SteamVR for Pimax headsets.

Whichever one doesn't say "MT".

Your problem is ReShade. Either wrong version or not installed properly. Install this tool and untick the ReShade API layer and then it will work. https://github.com/fredemmott/OpenXR-API-Layers-GUI Also run DCS from bin and not bin-mt You've also set an affinity mask on your processes so a bunch of cores are unusable by DCS, this can cause stutters or other perf issues. From the log, ReShade layer: 2025-11-03 05:19:59.107 INFO VISUALIZER (Main): [00:19:59.240][Info ] OpenXR: Available Layers: (1) 2025-11-03 05:19:59.107 INFO VISUALIZER (Main): [00:19:59.240][Info ] OpenXR: Name=XR_APILAYER_reshade SpecVersion=1.0.0 LayerVersion=2 Description=crosire's ReShade post-processing injector for 64-bit 2025-11-03 05:19:59.107 INFO VISUALIZER (Main): [00:19:59.240][Info ] OpenXR: Available Extensions: (13) 2025-11-03 05:19:59.107 INFO VISUALIZER (Main): [00:19:59.240][Info ] OpenXR: Name= SpecVersion=0 Error killing your runtime. Known ReShade issue due to where it stores files, not accessible to OpenXR runtimes. 2025-11-03 05:19:59.108 ERROR VISUALIZER (Main): OpenXR failure XrResult failure [XR_ERROR_FILE_ACCESS_ERROR] Origin: xrCreateInstance(&createInfo, &instance) Source: Projects\Visualizer\Source\OpenXR\openxr_program.cpp:410 2025-11-03 05:19:59.108 ERROR VISUALIZER (Main): OpenXR exception: XrResult failure [XR_ERROR_FILE_ACCESS_ERROR] Origin: xrCreateInstance(&createInfo, &instance) Source: Projects\Visualizer\Source\OpenXR\openxr_program.cpp:410 If you still want ReShade then follow the instructions in this comment. This post is also over a year old and is unrelated to your problem. You should raise your own post going forward if you have issues.

Not entirely sure if this is related, but there is VR Recenter keybind in DCS, by default this is Numpad 5. So just look straight ahead and press that. Hand tracking in DCS is janky and largely a gimmick. Switches are difficult, and knobs are almost impossible. Enabling this in Virtual Desktop should be pretty easy. I'd need to recheck my settings from when I did this earlier but essentially in the VD settings in the headset you want to tick the box to forward tracking data to your PC, and enable hand tracking.

You could fork it and experiment to see what results you get. The intention was to be $0 (so local) and near-instantaneous response with the improvements made. The latter is really important in the context of gaming. For example, a 2 second sentence on my machine takes about 100ms, this isn't linear so an 11 second sentence can be 170ms. A number of folk also use with Vaicom, this has a very short window from when you release the PTT button until it receives the command. So if the processing takes too long and falls outside this window then Vaicom will discard the command. I haven't look into, or used the online Whisper API, so have no idea what the processing time + round trip latency for this would be. For use cases where this doesn't need to be near-realtime then it might be acceptable.

Lots of people, this is how I use it as well. VR or 2d doesn’t matter.

Not sure if it helps but you don’t have to pull the trigger, or rotate the controller. If you just push the joystick on the controller up it does a left click, and down is a right click. Moving the joystick on the controller right and left turns dials as well.

Works fine for me. I'm on a Quest headset though (though it shouldn't make a difference), and I'm still on ReShade 6.3.3. I'll upgrade it (have been putting off as it just works) and see if I have any problems. Was this working for you in the past? Any changes / upgrades since then? Seeing as how you selected OpenXR in the dropdown now and not Auto Detect for DCS in OKB can you repeat and drop another log file with a crash, just to see whether or not it's in the same place. For additional comparison can you drop a DCS log file and ReShade log file (just attach as files) for when this is working without OKB. I also had a look on the OKB Discord server for ReShade issues. Some mentions of the auto-detect around D3D11 and if it's been tampered with, e.g. ReShade. When I installed my ReShade at the time I believe I only chose the OpenXR option and not to also use DirectX11/12. Do you recall if you also selected that option as well? Could try uninstall and reinstall of it without selecting that option, just select OpenXR only. It will actually still work in 2D, as long as you launch the game with VR enabled but no headset connected. This is because the OpenXR layer will still trigger it, but DCS will automatically start in 2D as it doesn't detect a headset. Side-note, I see you have the `--force_OpenXR` parameter on your shortcut. That's now redundant as DCS is an OpenXR game completely so you can remove that.

Lots of people play DCS with G2.

Yes. You buy VD in the Quest store in your headset, and then install the free Windows streamer app on your PC. Can do, once I switched I've never looked back. And doesn't have the continual problems that plague a lot of folk with the Meta app. Need a dedicated router beside you for best results, but there are adapters etc. if your Wifi isn't quite up to it. Really feature rich as well and super easy to use.

Seeing as how you're using DLSS/DLAA you could also add the entries for the DLSS preset to use, and the flag to remove DLSS from the HUD and MFDs to remove ghosting there. (unless already there and these were just on top). Thanks for the list of additional ones, looks like there's some good stuff in there.

The initial points 2, 3, and 4 are irrelevant as well and cannot be repaired, these are redherrings and just part of the general DCS core game. Point 4 also states to run in an elevated command prompt. Just running a repair using the standard DCS shortcut for repair, or from within the launcher, should take care of this. I'm also curious about the "elevated" prompt, does this mean it's going to run that as an administrator, have no clue why it recommends this, and if this alters file permissions. As you mentioned though, ChatGPT is not completely reliable. Glad you mentioned you asked it a bunch of feedback questions.

Your log file is spammed with the following error: 2025-10-28 08:06:47.957 ERROR DX11BACKEND (14872): Failed assert `false && "failed to create vertex buffer"` 2025-10-28 08:06:47.957 ERROR DX11BACKEND (7904): failed to create index buffer. Reason: DXGI_ERROR_DEVICE_REMOVED This can be caused by overclocking on your video card or corrupted drivers. Remove all overclocking from your GPU. See also this page on this issue. Errors or Crashes on startup or gameplay of DCS World I would also recommend using DDU to clean up your existing driver and install the latest one. In addition to this you have numerous mods, some of which have errors. Remove your mods, run a slow repair of the game, then deleted the Saved Games\DCS\fxo and metashaders2 folders and try again. You are also running DCS from the bin-mt folder. Run DCS from the bin folder and bin-mt are multithreaded and bin-mt will be removed in the future. Additionally open a command prompt as administrator and run the below two commands separately and then restart your PC. This will repair any corrupted Windows systems files. dism /online /cleanup-image /restorehealth sfc /scannow A large number of your zip files were corrupted as well and couldn't opened. This can sometimes happen when you run out of memory. Given that you have 64Gb this should be fine, but can also occur due to the fxo and metashaders2 folders if not cleaned up causing GPU memory issues. As per instructions above deleting those may help.