Kernel-mode vs userspace WebDAV on Windows: where the bottleneck really is

If you've ever tried to mount a WebDAV share as a real Windows drive letter, you've probably hit the same wall: 4 MB/s on a 1 Gbps LAN, file locks that don't release, or random ERROR_ACCESS_DENIED when copying 200 small files. The user-visible tool (RaiDrive, NetDrive, Mountain Duck) changes — the bottleneck stays.

After profiling several WebDAV clients on Windows, the difference comes down to one architectural choice: kernel-mode or userspace.

The two architectures

Userspace WebDAV (RaiDrive / NetDrive / Cyberduck mount)

• User-mode process intercepts file I/O requests at the Win32 layer (or via Dokan, an FUSE-equivalent for Windows).
• Every ReadFile / WriteFile becomes a context switch: Win32 → userspace WebDAV client → HTTP request → kernel TCP stack → wire.
• File system semantics (locking, opportunistic locks, oplocks) are re-implemented in userspace — and they're almost right, never exactly right.
• This is why you see "the file is locked by another process" when nothing else has it open, or STATUS_SHARING_VIOLATION when copying from Explorer.

Kernel-mode WebDAV (Windows built-in MRXDAV.SYS, ScsDriver, a few commercial products)

• Runs inside the kernel's I/O manager. File requests don't round-trip through a user proxy.
• Speaks HTTP/WebDAV directly via the kernel TCP stack (AFD.sys → TCPIP.sys).
• File system semantics are honored by the kernel cache manager, which is what real applications (git, Node, MSBuild, antivirus) expect.
• The trade-off: kernel bugs = BSOD. So you want a driver that's actually tested, not a hobby project.

Where the throughput difference actually comes from

Most blog posts blame "the overhead of HTTP" or "WebDAV being chatty." That's missing the point. The 4 MB/s ceiling on RaiDrive with a 1 Gbps LAN is mostly:

1. Per-request context switches — userspace clients do 2–4 context switches per I/O. On 100 KB files, that overhead dominates.
2. Cache manager integration — kernel clients use the kernel cache manager; userspace clients can't, because the cache manager only trusts kernel-mode file systems.
3. Locking semantics — many apps (Visual Studio, git, MSBuild, anything that opens files with FILE_SHARE_DELETE) break under userspace locking because the proxy doesn't honor FILE_SHARE_DELETE properly.

In practice: with kernel-mode, you get LAN throughput (90+ MB/s on a 1 Gbps link) and apps behave correctly. With userspace, you're capped around 5–10 MB/s and apps fight you.

What I tested

Test rig: Windows 11 23H2, Alist 3.x serving WebDAV from a local SSD, 1 Gbps LAN, files: 1× 5 GB ISO + 500× 1 MB files.

The "broken" rows aren't a measurement mistake — git and a few other tools genuinely fail to operate on RaiDrive-mounted shares because of locking.

When userspace is fine

If you're streaming media, dropping one big file onto a share, or doing read-only browsing — userspace is fine. Don't over-engineer it.

If you're doing any of the following, kernel-mode is worth the setup cost:

• Git repos on the share
• Build outputs (Node, MSBuild, Maven)
• Database files (SQLite, Postgres data dir)
• Anything that opens a file, holds it briefly, and reopens

A practical path if you want kernel-mode today

1. Windows built-in net use — kernel, but only works against IIS-style WebDAV and falls over on most third-party servers. Try first, but expect issues.
2. ScsDriver (drive.scsoi.com) — kernel-mode WebDAV + HTTP driver for Windows, supports modern servers (Alist, Nextcloud, Seafile, Apache mod_dav). No Dokan dependency, which is what removes the userspace ceiling.
3. Commercial — a few enterprise NAS vendors ship their own kernel-mode WebDAV clients; check your NAS vendor's download page.

TL;DR

The "WebDAV is slow" meme comes from the userspace clients most people use. It's the proxy, not the protocol. If you need real filesystem semantics on Windows, the answer is kernel-mode — and there's finally an option that doesn't force you onto the broken built-in client.

Happy to answer questions about the setup in the comments.