How we research Windows

In the “Windows Research” section, we verify specific technical claims. In each article, we explain what was tested, under what conditions, and which systems the result applies to.

The presence of a setting, its effect on system operation, and the performance gain each require separate evidence.

What counts as evidence

We use several independent types of evidence:

1. Primary documentation. Official Microsoft documents, specifications, and documentation from the hardware or application vendor.
2. Static observation. Signs of implementation in a specific version of a component. Such an observation is limited to the build studied and by itself does not prove that the path executes at runtime.
3. Dynamic observation. System events, component state, and traces obtained in the described scenario.
4. Controlled measurement. Comparison of a pre-selected metric under a known change and a verified return of state.
5. Reproduction. Repeating the result in an independent run, on another system or build.

Internal methods of automating collection and processing are not published. This does not change the requirement to disclose the question under test, the configuration, the metrics, the number of runs, and the limitations.

Material statuses

Status	Meaning
Documented	Behavior is described in a primary public source.
Observed	An event or state was detected in the specified environment.
Measured	A numerical difference was obtained using the described methodology.
Reproduced	The result was repeated independently.
Not reproduced	The claimed effect was not detected under the specified conditions.
Insufficient data	The methodology or sample does not allow a conclusion to be drawn.

A status applies to an individual claim, not automatically to the entire article. We do not use an arbitrary confidence percentage and do not call a result universally proven without verification on other systems.

How an experiment is structured

Before measurement, the following are fixed:

• one question under test;
• the independent variable;
• the primary metric and its unit;
• Windows build, relevant hardware, drivers, and application versions;
• a practically significant threshold;
• the method for restoring the original state.

We compare the original and modified states, then verify the return. Where possible, we alternate the order of paired runs. We control warm-up, power, temperatures, and background load; if this is impossible, we state the limitation.

Separate intervals of a single trace show changes over time but are not considered independent repetitions. A virtual machine result cannot be automatically transferred to a physical computer. To draw a conclusion about all devices of one class, testing one device is not enough.

Physical click-to-photon rig

For gaming research we use our own hardware rig. It physically measures the full latency from the electrical signal of the mouse button to the change in pixel brightness on the screen, without software estimation of this interval.

The main path is arranged as follows:

1. A wire is soldered to the left button line of a first-generation Logitech G PRO X SUPERLIGHT. The electrical edge starts an Arduino Uno timer.
2. The same click passes through the mouse controller, USB, Windows, the game, the render queue, the GPU, and the monitor.
3. A photodetector mounted on the screen stops the timer when the brightness of the test area crosses a pre-selected threshold.
4. One result contains the full click-to-photon interval in milliseconds.

This start deliberately includes processing by the mouse controller and its click debounce, but does not include the mechanical travel of the button until the contact closes. We do not subtract the mouse latency from the final value. In the current methodology of independent measurements, RTINGS states 2.5 ms over cable and 3.1 ms via receiver for the G PRO X SUPERLIGHT. The low measured click latency makes this mouse a suitable stable part of the rig, but does not turn the result into pure Windows or game latency.

A separate HID microcontroller in the Arduino Nano format can send clicks to Windows automatically. This route is used when the differences of a manual press need to be removed and the input signal repeated at a controlled rate. It answers a different question and is not mixed with series that start from the physical mouse button line.

In CS2, the workshop map BXLAT is used, where a click causes a predictable change in the test area. A similar visual scenario is used in Valorant. The photodetector position, resolution, monitor refresh rate, FPS limit, display scaling mode, presentation mode, and light threshold are fixed for the entire series being compared.

The current standard requires at least 300 valid clicks per state. In new series we store the mean, standard deviation, minimum, maximum, percentiles including P90, and the distribution for plotting. False triggers, timeouts, and values outside a pre-established range are flagged and taken into account when checking the suitability of the series.

Research on this rig has been conducted for several years, and the storage format has changed over that time. The public table of historical measurements contains series of 300 clicks and earlier series of 100. For some older tests, only AVG, STDDEV, MIN, and MAX are preserved; missing P90 or plots cannot be reconstructed from aggregates and are explicitly marked as unavailable. New series will be published with extended statistics.

What is published as a result

An article contains:

• a short answer;
• the claim under test;
• the scope of the research;
• the methodology and the number of independent traces;
• metric values and spread;
• confirmed and unconfirmed conclusions;
• excluded or contaminated metrics;
• limitations;
• a practical recommendation without a guarantee of the same result;
• confirmation of state restoration;
• primary public sources and the verification date.

If a result did not confirm a popular recommendation or a BoosterX feature, it can still be published. The presence of a setting in the product is not proof of its effectiveness.

How to verify it yourself

A significant portion of the dynamic observations from our research can be reproduced with public tools: Sysinternals ProcMon for system traces and WinDbg with public Microsoft symbols. The basic verification path looks like this.

1. Reading a setting — ProcMon. Open Options → Configure Symbols and specify the public Microsoft symbol server so that stacks show module and function names. Then add a Path contains filter — for example SystemResponsiveness from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. From the read events you can see whether the value is read, when, and by which process.
2. Who reads it — the call stack. Double-clicking an event opens its properties; the Stack tab shows the chain of modules — this is the “reader” of the setting. For example, a chain from user32.dll to win32kfull.sys means that the Win32k subsystem is responsible for the value.
3. Runtime behavior — WinDbg. With public Microsoft symbols, you can set a breakpoint on a function from the stack and see how the read value is applied.
4. Synthetic tests. Change the value and measure the observed behavior. For example, mouse input intervals are measured by public polling rate testers.

An honest boundary. Static analysis of binaries and full traces are not published in the articles. The path above reproduces the dynamic part of our observations but does not replace static analysis — its conclusions apply to the build studied.

Boundaries of latency measurement

Software latency, queue depth, the audio engine period, thread scheduling time, and full physical latency describe different quantities. For example, the XAudio2 queue does not determine the entire interval from a user action to sound from the speaker. Measuring it requires external hardware.

Similarly, the CPU time of an individual process is not equal to the overall effect on FPS, frametime, power consumption, or system responsiveness. Such conclusions are verified with separate metrics.

Data protection

Raw ETL, PML, event logs, memory dumps, and registry exports are not published by default. System traces may contain user names, paths, command lines, network addresses, and other sensitive data. Microsoft warns about this separately in the Sysinternals terms.

Only manually selected and anonymized tables are posted on the site. We remove unique device and installation identifiers, user paths, account data, network identifiers, credentials, and information about processes unrelated to the research.

Correcting conclusions

Windows, drivers, and applications change. Each article receives a last verification date and a scope of applicability. If a new measurement contradicts an old conclusion, the article is updated with an explanation of the reason. An old result is not automatically carried over to a new build.

Independence and trademarks

The research is published by the BoosterX team and may relate to product features. This potential conflict of interest is addressed by separating the methodology, measured values, limitations, and negative results from the product recommendation.

BoosterX Wiki is an independent publication and is not affiliated with, authorized, sponsored, or endorsed by Microsoft Corporation. The names Microsoft and Windows are used only to accurately describe the subject of the research. More details: Microsoft Trademark and Brand Guidelines.

Change history

• 2026-08-24: methodology published.
• 2026-09-20: added the “How to verify it yourself” section; fixed the link to the mouse data source.

Last verification of the methodology: 2026-09-20.