I built a user-mode memory compressor that intercepts Win32 APIs to force applications to use an NVMe SSD as a Tier-2 RAM swap.
Hey everyone,
thats a test video
https://vimeo.com/1198162508?share=copy&fl=sv&fe=ci
I’ve been working on a custom virtualization utility called **NVMeRAM**, and I wanted to share the architecture. It essentially weaponizes the Windows Memory Manager to heavily compress the physical RAM footprint of target applications (like Chrome or game servers) and forces them to page out to a custom NVMe-backed sparse file.
**How it works under the hood:**
* **The Shim:** A `launcher-gui.exe` injects `shim.dll` into target processes via `CreateRemoteThread` → `LoadLibraryW`.
* **Working Set Hijacking:** The shim calls `SetProcessWorkingSetSizeEx` using the `QUOTA_LIMITS_HARDWS_MAX_ENABLE` flag, placing a strict hard limit (e.g., 32 MB or 2 GB) on the app's physical memory residency.
* **Aggressive Eviction:** A background thread calls `EmptyWorkingSet()` every 1.5s while forcing the process memory priority to **Very Low** via `NtSetInformationProcess`. This paints a giant target on the app, forcing the OS to immediately page it out to the NVMe disk.
* **The Sandbox Bypass:** To catch Chromium renderers, the shim hooks `CreateProcessW` in the browser process. When a child is spawned, it forces `CREATE_SUSPENDED`, injecting the shim at medium-integrity *before* the Chrome sandbox drops privileges to CIG.
I also experimented with hooking `RtlAllocateHeap` to map large allocations directly to `%TEMP%\NVMeRAM_backing.bin` via a linear bump-allocator, though it fights heavily with PartitionAlloc in Chromium.
It’s a brutal, aggressive way to manage memory entirely in user-space, but Gen4/Gen5 NVMe drives are actually fast enough to handle the page-fault thrashing for certain workloads.
I'd love to hear your thoughts on the architecture or ways to optimize the page-fault hits.
**GitHub:** [https://github.com/elouardighi/NVMeRAMLauncher](https://github.com/elouardighi/NVMeRAMLauncher)