TMR (Test Memory R)

TMR is short for Test Memory R, the R for Rust. It's a remake of TM5 (TestMem5 by Serj, https://testmem.tz.ru), the memory tester highly acclaimed by memory overclockers. I contacted Serj, who was kind enough to fix a broken link on his website that gave me TM5's original assembly source. I then used Claude AI (with a little bit of Astra/Codex) to reimplement TM5 in Rust for modern Windows and hardware, with DDR5 systems in mind.

Status: 0.1.1, an early release. TMR works, but it is young: its settings and files may change between versions until 1.0. An unstable overclock can freeze, crash or restart your PC while TMR runs, as any memory test can: save your work and close other programs first.

Screenshots

The window, during a stability run: the throughput chart, each finished step, and a step's report.

The window is WinUI 3, through Reactor (windows-reactor, from Microsoft's windows-rs). It was chosen because it proved very light in testing, even in a VM with no GPU, so it leaves the machine to the test. The trade-off is that Reactor is young: some things the window would like, such as monospaced text in its controls and a log that follows its end, aren't there yet. The window will gain that polish as Reactor does.

The console, with its progress ticker at the bottom.

The console looks best in a modern terminal, which shows its emoji and table lines in a font such as Cascadia Mono: Windows Terminal (it ships the Cascadia fonts) with PowerShell 7.6 or later. In the classic Windows console, which draws the emoji as boxes, TMR says so at a run's start and end. Both install with winget:

winget install --id Microsoft.WindowsTerminal --source winget
winget install --id Microsoft.PowerShell --source winget

Install and run

• The installer, tmr-<version>-setup.exe from GitHub Releases: for all users (in Program Files, after a UAC prompt), or for you only. It adds TMR to the Start menu and tmr to the PATH.
• winget, once TMR's package is accepted there: winget install Petz.TMR.
• The bare tmr.exe from the same releases, in a folder of its own that you can write to.

Then grant the large-page privilege once, from a console run as administrator: tmr --setup-large-pages grants it to you (Group:Administrators, or another Group: or User: name, to a group or another account), and sign out and back in. From then on TMR has it in every run, run as administrator or not. Double-click TMR for its window, or type tmr plan=stability in a console for the stability plan, 3 cycles: any setting starts a run, tmr alone lists every setting, and config=file.cfg runs a TM5 config. The user guide, which the installer puts in TMR's docs\ folder, has the rest.

TMR keeps its files beside tmr.exe: configs\, results\ (one JSON file a run, saved as it goes), logs\ and tmr-cfg.json (its calibrations). TMR_HOME puts them in another folder. A results file describes the system it came from: the CPU, the BIOS, the memory modules (their part and serial numbers) and the motherboard's system UUID, so mind that before you post one.

Key changes from TM5

• Fixed allocations instead of a sliding window. TM5 slides an AWE window over the memory it tests; TMR gives each thread its own fixed allocation, with native 64-bit addressing.
• Huge (1 GB) and large (2 MB) pages, locked in memory (non-pageable). Both are faster than regular 4 KB pages. No driver: TMR runs in user mode, and tmr.exe --setup-large-pages (elevated) grants the privilege they need once, to you, or with Group:Administrators to a group.
• Wider SIMD: most tests come in 128-bit, 256-bit (AVX2) and 512-bit (AVX-512) widths, the widest the CPU has by default (width= picks one). An experimental tile test runs on AMX (Intel Xeon); ACE is next to look at.
• TM5 configs still work: TMR loads TM5 .cfg files and runs the equivalent tests.
• TM5's test 0 becomes the seal: all memory is sealed at the start of a cycle and checked at its end, and each block a checking test works on is checked before and resealed after it, so an error in memory no test is touching is still caught.
• Errors say more: a failed check is rescanned to tell a misread from a wrong stored value, failures are counted by bit position (one bit failing everywhere points at one data line), and Windows' hardware error log (WHEA) is watched for errors the tests can't see themselves.
• Built for today's CPUs: threads are pinned to physical cores and take their memory from their own NUMA node while it has room, CPUs beyond 64 (processor groups) are used, and checks can bypass the caches (non-temporal stores, CLFLUSHOPT) so they read DRAM.
• Patterns aimed at the memory bus, alongside TM5's. A switching family inverts each beat of a burst at the bus's own width, so every data line toggles on every transfer, the most switching noise the data can make: 64-bit for DDR4, 32-bit for DDR5's subchannels, 16-bit for LPDDR4/5, picked from the memory type SMBIOS reports, and models of LPDDR6's 12-bit and DDR6's 24-bit, chosen with beat=. A random family feeds every line every short bit sequence, which DDR5's receive equalisers react to. Both aim to make a marginal overclock fail sooner.
• Built-in test plans (plan=; stability by default), results as JSON saved during the run and comparable between runs, and a console (CLI) and a window (GUI) in one tmr.exe.

Supported Windows OSes

tmr.exe opens its window when double-clicked, and runs in the console when started from a shell, a script or a remote session; --gui and --cli choose explicitly. Where the window can't open, --gui says why and runs nothing.

Windows	Build	Console (CLI)	Window (GUI)
Server 2022	20348	Yes	No: a double-click leaves you at a prompt in TMR's folder, after its help, in a Windows Terminal window when it's installed, with the newest PowerShell; --gui says why and stops
Windows 11 21H2, 22H2, 23H2	22000–26099	Yes	Yes, but a double-click flashes a console window briefly before the window opens
Windows 11 24H2 and later, Server 2025	26100 and later	Yes	Yes, fully supported

Windows 10 and Server 2019 aren't supported: TMR isn't tested on them, and the window needs Windows 11.

Supported hardware

CPU. TMR is compiled for x86-64-v3 (AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE) and also needs CLFLUSHOPT, which pushes a cache line out to DRAM so that a check reads the memory, not a cached copy. It checks for both at startup, and stops on a CPU without them.

	Intel	AMD
Required: x86-64-v3 and CLFLUSHOPT	6th gen Core (Skylake, 2015, e.g. i5-6600K) and later	Ryzen 1000 and EPYC 7001 (Zen, 2017) and later
Optional: AVX-512, for the 512-bit tests	Core X (Skylake-X), Xeon Scalable and Xeon W, 10th gen mobile (Ice Lake), 11th gen (Tiger Lake, Rocket Lake); no consumer chip since 12th gen	Ryzen 7000 and EPYC 9004 (Zen 4) and later
Optional: AMX, for the experimental tile test	4th gen Xeon Scalable (Sapphire Rapids, 2023) and later	None

Haswell and Broadwell (4th and 5th gen Core, e.g. i5-4670K) have AVX2 but not CLFLUSHOPT, so TMR doesn't run on them, nor on Pentium, Celeron and Atom models without AVX2. A test the CPU can't run (a 512-bit test without AVX-512, the tile test without AMX) is left out of the run, never stepped down to a narrower width.

Memory. TMR reads the memory type from SMBIOS and aims its switching patterns at that type's bus width (see Key changes):

Memory type	Bus width the switching patterns flip at
DDR4 (and DDR3L, on some 6th and 7th gen Core boards)	64-bit: one channel per DIMM
DDR5	32-bit: two subchannels per DIMM
LPDDR3	32-bit
LPDDR4, LPDDR5	16-bit
DDR6, LPDDR6	24-bit and 12-bit, models of the drafts: not detected, chosen with beat=ddr6 or beat=lpddr6

When SMBIOS reports no type TMR knows (a VM often reports none), TMR says so and the switching patterns alternate their 64- and 32-bit forms; beat= sets the type.

Caches. TMR reads the size of each cache tier (L1, L2, L3) from the CPU. The cache bandwidth and latency tests are sized to fit their tier, and tests aimed at DRAM size their blocks past the L3, so they reach it.

Requirements

• Windows and a CPU from the lists above.
• The Microsoft Visual C++ runtime (VCRUNTIME140.dll), for the console and the window alike. tmr.exe is built with Microsoft's C++ toolchain, which keeps part of its C runtime in that DLL rather than in each program, so without it Windows won't start tmr.exe ("VCRUNTIME140.dll was not found"). tmr.exe takes it, as it takes Windows' own DLLs, from Windows' System32 folder only, where the runtime installs it: a copy beside tmr.exe is never used, so no other program can put its own there for an elevated tmr.exe to run. Most PCs have it already: games and many apps install it. Get it from https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist, or: winget install Microsoft.VCRedist.2015+.x64
• The Windows App Runtime 2 (2.4 or later), for the window only: the window's controls (WinUI 3) are in that runtime, which Microsoft ships apart from Windows. The console runs without it. When the window can't find it, TMR offers to open the download page, https://learn.microsoft.com/windows/apps/windows-app-sdk/downloads. Or: winget install Microsoft.WindowsAppRuntime.2 (not Microsoft.WindowsAppRuntime.2.0, an older 2.0 release).
• Neither runtime is bundled with TMR, on purpose: both are shared by many programs, so each PC should keep its one copy up to date (winget upgrade --all, or each package by its name above), and it keeps tmr.exe and this repository small.
• Optional: the "Lock pages in memory" privilege, for huge and large pages: run tmr.exe --setup-large-pages once from an elevated prompt (Group:Administrators, or another Group: or User: name, grants it to a group or another account), then sign out of Windows and back in (a privilege reaches your programs at your next sign-in). From then on TMR has it in every run, run as administrator or not. tmr.exe --remove-large-pages takes it away again. Without it TMR warns, and asks before running on regular 4 KB pages, which are slower: it runs on them only when you say so, or with minpage=regular maxpage=regular, and no answer quits.

Building from source takes Rust nightly (rustup toolchain install nightly) and Microsoft's C++ build tools for the linker (Visual Studio Build Tools, "Desktop development with C++"). cargo +nightly build --release builds both frontends into the one target\release\tmr.exe, as each release is; --no-default-features leaves the window out. A built tmr.exe keeps its configs, results and logs beside itself, in target\release\, which cargo clean empties: set TMR_HOME to another folder to keep them there ($env:TMR_HOME = "$PWD" in the repository keeps them in its results\ and logs\, which git ignores). A development machine, with the tests and checks as CI runs them: doc/dev_setup.md (tools\setup_dev.ps1 installs what's missing). The crates are on crates.io too: test-memory-r, the exe, and its parts, test-memory-r-engine, -cli (the console) and -gui (the window). The exe's page shows how to cargo install it built as the releases are.

License

This project is licensed under either of:

• MIT License (LICENSE-MIT)
• Apache 2.0 License (LICENSE-APACHE)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in TMR by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Credits

TMR was inspired by TM5, and wouldn't exist without it. Many thanks to Serj for his kind donation of TM5 to the community.

• Serj's work: https://testmem.tz.ru
• TM5 page: https://testmem.tz.ru/testmem5.htm