NtFlushProcessWriteBuffers

Prototype

VOID NtFlushProcessWriteBuffers(VOID);

Arguments

Syscall IDs by Windows version

Syscall stub

4C 8B D1                  mov r10, rcx
B8 F3 00 00 00            mov eax, 0xF3
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03                     jne short +3
0F 05                     syscall
C3                        ret
CD 2E                     int 2Eh
C3                        ret

Undocumented notes

NtFlushProcessWriteBuffers (Win32 wrapper `FlushProcessWriteBuffers`) does not return a status and takes no parameters. Internally the kernel sends an inter-processor interrupt (IPI) to every CPU on which a thread of the calling process is currently runnable, forcing each one to execute a full memory barrier — the asymmetric-memory-barrier trick that lets lock-free algorithms in the calling thread skip an explicit `mfence` on the *fast* path and pay the full cost only on the rare *slow* path. .NET, Java HotSpot via its native wrappers, and high-performance lock-free queues (Boost.Lockfree, concurrentqueue) all use it. Cost is high — tens of microseconds — but it's amortised across many fast-path reads.

Common malware usage

Honestly, this syscall has almost zero offensive signal. It does not allocate, read, write, or otherwise touch process state in an attacker-useful way. The only theoretical abuse is **CPU-bound side-channel timing**: the IPI cost is proportional to the number of CPUs currently running threads of the calling process, which can leak gross scheduling information about other cores — but this is academic and not seen in real-world malware. A handful of obscure anti-debugger checks have used FlushProcessWriteBuffers to detect single-stepping (the IPI timing changes under a hardware debugger), but it's a marginal technique. Don't waste hunt time on this one.

Detection opportunities

Not a useful detection target. Legitimate use is widespread (any process with a .NET runtime, a JVM, or a modern lock-free library will call it). ETW providers do not surface this syscall, and there's no kernel callback worth hooking. If you find yourself writing a detection rule around NtFlushProcessWriteBuffers you've probably gone too deep — re-prioritise.

Direct syscall examples

// Fast path: a regular load, no fence.
// Slow path (writer): publish, then NtFlushProcessWriteBuffers to fence every
// reader CPU at once.
#include <windows.h>

static volatile LONG g_seq;

void writer_publish(void) {
    InterlockedIncrement(&g_seq);
    FlushProcessWriteBuffers();   // ntdll!NtFlushProcessWriteBuffers
}

LONG reader_fast(void) {
    return g_seq;   // no mfence — the writer's IPI guarantees ordering.
}

NtFlushProcessWriteBuffers PROC
    mov  r10, rcx
    mov  eax, 0F3h
    syscall
    ret
NtFlushProcessWriteBuffers ENDP

MITRE ATT&CK mappings

• T1106Native APImitre ↗