How to Enable MSI Mode in Windows 11, and What It Actually Changes

Every Windows latency guide has the same step: open a tool called MSI Util, tick your graphics card, reboot, enjoy lower input lag. The tweak switches a device from old line-based interrupts to message signaled interrupts, MSI mode for short. We wanted numbers instead of forum quotes. So we traced every interrupt on a real desktop, with three devices in both modes. Here is what changed, what did not, and how to check your own PC in 30 seconds.

What MSI mode is supposed to do

A device gets the CPU’s attention with an interrupt. The old way uses a physical line, and there are only a few of them, so devices end up sharing. When anything on a shared line fires, Windows has to call the interrupt routine of every driver on that line and ask each one whether the interrupt was theirs.

Message signaled interrupts were added in PCI 2.2 to get rid of the lines. The device writes a small message to a memory address instead. Every device gets its own vector, nothing is shared, and the driver knows at once who is calling. MSI-X, the later version, allows up to 2,048 messages per device and lets each one target a different core.

The tweak itself is one registry value. Under the device’s key in HKLM\SYSTEM\CurrentControlSet\Enum\PCI, the subkey Interrupt Management\MessageSignaledInterruptProperties holds a DWORD named MSISupported. Microsoft documents it as the switch a driver’s INF file sets at install time. One means MSI, zero means a legacy line. MSI Util v3, the closed source tool from a 2013 guru3D thread, flips that same value.

What Windows had already done on our desktop

The testbed is the same PC as in our core parking test: Intel Core i9-14900F, AMD Radeon RX 7800 XT, Windows 11 Pro 25H2, Memory Integrity on. Before touching anything we listed every PCI device that can do MSI and the mode it was running in.

Fourteen of sixteen devices were already message signaled. The GPU and the USB controller, the two devices every guide tells you to switch, had nothing left to switch. The only legacy devices were the two audio controllers, and they shared one line.

How we measured

LatencyMon is the usual tool for this, and it would not run here: Windows Memory Integrity blocked its kernel driver. So we built the measurement from parts that ship with Windows. The NT Kernel Logger records every interrupt routine (ISR) and deferred procedure call (DPC) with its start and end time, and tracerpt decodes the log. A PowerShell script then bills each one to its driver. While the trace runs, a time-critical thread pinned to CPU 1, the core that serves the legacy lines on this board, spins on the clock and logs every gap over 10 microseconds. PresentMon captured frame times.

The load was the same in every run: a WebGL scene with 10,000 fish held at 180 fps by the 180 Hz monitor, plus a quiet tone played through the monitor’s DisplayPort audio so the audio controller stayed busy. Each state got two 30 second runs. The script is msi-bench.ps1 in the utility’s repo, and the raw output of every run sits next to it. To repeat a run, start your load and call it from an elevated PowerShell, once per state:

.\msi-bench.ps1 -Phase stock -Seconds 30 -Cpu 1

Nothing to install. It prints the tables below and saves the numbers as JSON.

Audio: two controllers on one shared line

This is the one real change the tweak could make on this PC, so we made it: both audio controllers from the shared IRQ 17 to MSI.

The first three rows are the textbook cost of a shared line, caught in a trace. Only one controller was playing sound, yet the driver’s routine ran almost twice per interrupt, because every interrupt on the line woke both devices’ routines. In MSI mode it ran exactly once. The audio interrupts also left CPU 1, so that core was interrupted a third as often.

Now the scale. Each wasted call cost about 11 microseconds, 100 times a second. That is a tenth of a percent of one core. Frame pacing did not move.

GPU: forced back to a legacy line

The GPU was already in MSI mode, so we ran the experiment backwards. We set its MSISupported to zero and rebooted, which is the state an owner of a card without MSI lives in. Windows gave it IRQ 16 with no neighbors.

On a legacy line the routine has to read the card’s status register to confirm the interrupt is its own, so theory predicts a longer routine, and this pair shows one: about 6 microseconds more per call. We would not bet on that number. Across all ten runs we recorded with the GPU in MSI mode, its mean routine time ranged from 18.9 to 25.9 microseconds, and the legacy result sits inside that spread. The DPC got shorter by almost the same amount, so the total per interrupt barely moved. Frame times were flat: p99 within 0.2 ms of stock, no missed frame in either mode. One gap in our data: the MSI frame times come from a session with a long uptime, because PresentMon delivered nothing in the fresh-boot MSI session.

USB: a fast mouse on a legacy line

Same backwards test for the USB host controller, with a mouse circling hard enough to raise about 7,500 interrupts a second.

The legacy line added 0.9 microseconds to each mouse report. An 8,000 Hz mouse sends a report every 125 microseconds, so the penalty is under 1% of the gap between two reports. No hand can feel that. Unlike the GPU result, this one repeated in every run, so it is real. It is also a rounding error. We have frame times for the legacy run only, and it missed one frame out of 10,800.

What the numbers mean

MSI mode is not a speed boost. It is the removal of one specific kind of waste: devices stacked on a shared interrupt line, each paying for the other’s traffic. On a current Windows 11 PC the drivers have already done the work for the devices that matter. Where a shared line was left, the fix worked exactly as designed, and the cost it removed was too small to see in a frame time graph.

That changes when a shared line carries something heavy. The classic case, documented by igor’sLAB, is a sound card sharing a line with a busy GPU: crackles and dropouts under load that vanish once both devices move to MSI. Our audio controllers shared a line with each other, not with the GPU, so we saw the mechanism without the symptom.

Check your own PC in 30 seconds

Look before you change anything.

1. Press Win+R and run msinfo32. Open Hardware Resources, then IRQs. The top of the list holds the legacy lines: small numbers, usually under 24. A PCI device there, like a GPU, USB controller, network or sound card, is in line-based mode. Two devices on the same number share that line. Message signaled devices sit at the bottom of the list with ten digit numbers such as IRQ 4294967255.
2. For a single device, open Device Manager, double-click it and look at the Resources tab. A negative IRQ such as (-59) means MSI. A small positive number means a legacy line.
3. Or run msi-mode-utility and read the grid. It lists the latency-critical devices with their current state and changes nothing until you pick a device and click OK.

If everything that matters already says MSI, this tweak has nothing to give you, and your stutter lives somewhere else. Parked cores are one suspect, and our core parking test shows how to rule them out. Online, a connection that chokes under load looks the same on screen, and our bufferbloat guide has a two minute check for it.

Where MSI mode still matters

• Graphics cards left on a legacy line. Reports from NVIDIA owners vary by card and driver version, and a clean driver install can reset the value. Check after every driver update.
• Sound cards and USB cards in PCIe slots. Add-in cards are the devices most likely to land on a line with a neighbor, and audio is where a shared line becomes audible.
• Older platforms. On boards from the Windows 7 and early Windows 10 era, line-based devices were the norm, which is where this tweak earned its reputation.
• Audio controllers. Both of ours ran on one shared legacy line until we changed them.

Leave NVMe drives and modern network cards alone. They run MSI-X with many vectors out of the box, and forum reports describe network cards that behaved worse after a forced change.

How to enable it, when the check says you should

We wrote msi-mode-utility for this: one readable PowerShell file, MIT licensed, no installer. Paste this into a terminal:

irm https://github.com/vadyaravadim/msi-mode-utility/releases/latest/download/msi-mode-utility.ps1 | iex

It asks for admin rights and shows the grid. Pick the devices, click OK, and it saves a .reg undo file next to itself before it writes MSISupported. Reboot to apply. To go back, double-click the undo file and reboot. That works from Safe Mode too, and the README covers the details.

Prefer doing it by hand? Find the device’s instance path on the Details tab in Device Manager, open that key under HKLM\SYSTEM\CurrentControlSet\Enum, and create Device Parameters\Interrupt Management\MessageSignaledInterruptProperties with a DWORD MSISupported set to 1. MSI Util v3 does the same from a closed source executable.

After the reboot, rerun the 30 second check. Then confirm nothing got worse where you can see it: move the mouse through our polling rate test and make sure the rate still matches what your mouse is set to.

What can go wrong

Change one device, reboot, check. A driver that cannot handle the new mode leaves its device dead until you undo the value, and with a GPU that means a black screen and a trip to Safe Mode.

Apply the change with a reboot, not with a device restart. Restarting our two audio controllers in place switched them to MSI in seconds with no reboot. Restarting the display adapter the same way froze the whole PC: black screen, no crash dump, a fatal hardware error in the event log after the hard reset. After a normal reboot the same setting worked fine.

Don’t expect the tweak to survive forever. The value belongs to the driver’s installer, so look at the grid again after major driver updates.