If you are running a high-refresh-rate gaming monitor (240Hz, 360Hz, or higher), you might have noticed elusive micro-stutters, disrupted frame pacing, or sudden spikes in end-to-end latency, despite your FPS counter showing a rock-solid 240 FPS with flat frametimes in RivaTuner.
The hidden culprit is Windows Per-Monitor v1 (PMv1) DPI awareness. This legacy scaling layer was introduced back in October 2013 with Windows 8.1 . Astonishingly, even today, the vast majority of PC games—including modern releases—still ship utilizing this outdated v1 protocol by default. Crucially, Windows enforces this virtual resolution layering for PMv1 processes even if your desktop scaling is set to exactly 100%, meaning you cannot escape its performance penalties by simply disabling OS scaling.
On a modern low-latency gaming system, the absolute goal is to completely eliminate PMv1 from the active process tree. Ensuring that not a single background app, service, or driver utility runs in Per-Monitor v1 mode is mandatory, as it introduces massive input lag and breaks core frame presentation timing—regardless of your display mode, including exclusive fullscreen.
The Virtual DPI Scaling Loop & Presentation Interruption
• The Graphics Presentation Pipeline: With v1, even if the game itself is rendering completely natively at your panel's true resolution (e.g., native 4K), Windows intercepts the swap chain presentation at the OS level. It processes the application context inside a forced virtual resolution scaling loop (scaling down internally and blowing it back up for display), which leads to spatial pixel interpolation (blurriness) and presentation lag despite high native GPU allocation.
• The Mouse Cursor Input Loop & Massive Input Lag: Your precise hardware mouse input gets funneled through this virtual coordinate subsystem. Even with Raw Input enabled in your game settings, the OS constantly translates and re-maps absolute hardware mouse coordinates between the desktop space and the game viewport to maintain cursor state consistency across the active DWM composition layers. This virtualization process bypasses standard low-latency hardware paths, injecting massive, sluggish input lag and noticeable cursor offset.
The 60Hz Virtual Refresh Rate Conflict & Frame Pacing Shatter
The most frustrating part is that your game engine can be perfectly optimized. A single active background process running Per-Monitor v1 is enough to corrupt your game's presentation timing and spike your end-to-end latency.
This occurs due to a hardcoded Windows power-saving and resource-allocation mechanism: Windows throttles everything except the active foreground application to run at a virtual refresh rate of 60Hz (or less) in the background to minimize CPU/GPU overhead.
Because modern Windows versions map even "exclusive fullscreen" via optimization layers (FSO) directly into the Desktop Window Manager (DWM) composition pipeline, the system is forced to sync your game with these 60Hz background elements. A PMv1 app breaks this pipeline in every display mode:
1. The Composition Delay: The DWM incurs irregular millisecond-level scheduling delays trying to compute the virtual DPI layer of that background process.
2. The Hardware Flip Queue Breakdown: Because the DWM attempts to align the throttled 60Hz background app with your game's 240 FPS on a single composition timeline, your frame pacing shatters. Game frames no longer reach the display at the perfect 4.16ms interval.
3. The Judder Illusion: Your 240Hz monitor is forced to drop or repeat frames due to the asynchronous composition queue. The game visually judders like it's running on 60Hz, compounding the feeling of massive input lag.
Direct Technical Comparison: PMv1 vs. Clean PMv2 Environment
• Introduced In:
-> PMv1: October 2013 (Windows 8.1)
-> PMv2: April 2017 (Windows 10 Creators Update)
• Background Process Refresh Rate:
-> PMv1: Throttled to a virtual 60Hz for resource saving.
-> PMv2: Independent processes do not block the DWM composition timeline.
• Input Latency (Mouse/Controller):
-> PMv1: Funneled through virtual coordinate mapping. Causes massive input lag and floaty response even with Raw Input.
-> PMv2: Direct Hardware Input (Raw Input) bypassing the virtualization layer for ultra-low latency.
• Frame Presentation Timing:
-> PMv1: Asynchronous frame pacing and presentation judder due to the 60Hz DWM conflict.
-> PMv2: Synchronous, clean frame delivery at true, fluid 240Hz+ presentation intervals.
How to Expose PMv1 Bad Actors in Task Manager
To purge PMv1 processes from your system, you need to expose them via the Windows Task Manager:
1. Open Task Manager (Ctrl + Shift + Esc).
2. Navigate to the Details tab.
3. Right-click any column header (e.g., Name or PID) and click Select columns.
4. Scroll down, check DPI awareness, and click OK.
Analyze the new column in your process tree:
•
Per Monitor (v1) or Per Monitor: These are the critical performance killers destroying your 240Hz frame presentation and mouse response. They must be forced to PMv2 via Registry overrides.•
Per Monitor (v2): Clean. These apps natively support modern Windows scaling, bypass the virtual scaling layer entirely, and will not affect your latency.•
Unaware or Per System: These apps do not request dynamic DPI changes. If your Windows desktop scaling is set to 100%, they run in their true original size without any scaling layer. If scaling is above 100%, Windows stretches them as a static bitmap. However, since they do not perform dynamic, unpredictable millisecond-level virtual resolution calculations, they are harmless to your DWM frame presentation timeline.The Ultimate Fix: The IFEO Registry Override
If you identify a stubborn background app (such as Windows native apps, background services, legacy RGB software, peripheral companion tools, or anti-virus overlays) running in Per Monitor (v1), you can use Image File Execution Options (IFEO) in the Registry to force it into Per-Monitor v2 (PMv2). The absolute end goal is to ensure that absolutely nothing runs under Per-Monitor v1 anymore—completely eliminating this virtual 60Hz timing roadblock from your entire system.
1. Open regedit and navigate to the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
2. Create a new Key named exactly after the executable of the background app (e.g., stutteringapp.exe).
3. Inside that new key, create a new DWORD (32-bit) Value and name it dpiAwareness.
4. Set its value to 3 (this forces Per-Monitor v2 globally).
Restart the target application. Note on persistent background utilities or core system processes: If you apply this override to stubborn services, system tools, or processes tied directly to the Windows UI shell, a simple application restart won't suffice. You must restart the entire PC for the global environment context to reinitialize cleanly under Per-Monitor v2. Be aware that core critical system files like csrss.exe cannot be switched to PMv2 because Windows will strictly block it; however, this is perfectly fine since CSRSS does not generate any graphical display output and won't affect your presentation timing.
- Unbenannt.png (498.15 KiB) Viewed 421 times
