Vite ERR_DLOPEN_FAILED: specified module could not be found
When reinstalling node_modules changes nothing, read the [cause] line: the Rollup binary is there, Windows just cannot load one of its DLLs.
TL;DR#
The error says Cannot find module @rollup/rollup-win32-x64-msvc, but the module is there. Read the [cause] at the bottom of the stack trace: if it is "The specified module could not be found" with code: 'ERR_DLOPEN_FAILED', Windows found Rollup's native binary and could not load a DLL that the binary depends on. Rollup x64 builds from 4.0.0 to 4.9.4 import VCRUNTIME140.dll, which comes from the Microsoft Visual C++ Redistributable. Run npm update rollup so the lockfile picks a newer Rollup, or install the x64 Visual C++ Redistributable. Reinstalling from the same lockfile, or copying node_modules from another machine, brings the same old Rollup back. Deleting package-lock.json as well, as the message suggests, only helps because the fresh resolve picks a newer Rollup, and it moves every other dependency at the same time.
The Stack Overflow question is a React project on Vite 5, Node v20.10.0 and Windows 11. The same project works on a colleague's Windows 11 machine, and it keeps failing even after the working machine's whole node_modules folder was copied across. That detail is what rules out the usual cause: the files are identical, so the difference is in Windows itself.
The failure was reproduced on 10 October 2026 with Vite 5.0.0 pinned to Rollup 4.6.0, on Windows 11 with Node v26.7.0 and npm 11.19.0. The missing DLL was simulated by renaming the binary's VCRUNTIME140.dll import, so the loader could not find it. The trace below is trimmed to the headline and the error code:
Error: Cannot find module @rollup/rollup-win32-x64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
code: 'ERR_DLOPEN_FAILED'The trace pointed at native.js:64:9 and native.js:73:48, the same two lines as the trace in the question.
Two causes behind one message#
Rollup 4 parses code with a native binary that ships as a separate npm package per platform. At start-up, rollup/dist/native.js requires the package for the current platform inside a try, and when that fails it throws its own error with the original one attached as cause. Before Rollup 4.7.0, every failure got the same text, the one about the npm optional dependency bug. So two different problems look identical until you read the last lines. With the package folder moved out of node_modules, as a control on the same machine, the headline was unchanged and only the cause differed (trace trimmed to the headline, cause and code):
Error: Cannot find module @rollup/rollup-win32-x64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
[cause]: Error: Cannot find module '@rollup/rollup-win32-x64-msvc'
code: 'MODULE_NOT_FOUND',The two cases side by side:
[cause] line | What it means | Where to go |
|---|---|---|
Cannot find module '@rollup/rollup-win32-x64-msvc', code MODULE_NOT_FOUND | The package is not in node_modules (installed on another OS, WSL, Docker) | the missing-binary fix |
"The specified module could not be found" with the path of rollup.win32-x64-msvc.node, code ERR_DLOPEN_FAILED | The binary is there; a DLL it imports is not | this page |
Node.js documents ERR_DLOPEN_FAILED as "A call to process.dlopen() failed": Node found the .node file and asked Windows to load it. On a Windows installed in another language, the cause text is translated. On the French Windows used for the reproduction it read "Le module spécifié est introuvable", with the same ERR_DLOPEN_FAILED code.
Why the DLL is missing#
A .node file is a Windows DLL, and it lists the DLLs it needs in its import table. Rollup's Windows x64 binary is built with Microsoft's MSVC toolchain. Listing the imports of the published binaries shows what changed. Rollup 4.6.0 imports, among others (C-runtime entries only):
VCRUNTIME140.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dllMicrosoft's page on which DLLs to redistribute explains the two families. The api-ms-win-crt-* names belong to the Universal C Runtime, which "is now a system component in Windows 10 and later, managed by Windows Update". VCRUNTIME140.dll is the other half, the runtime library for native code, and it is not part of Windows. It is installed by the Visual C++ Redistributable, which Microsoft describes this way: "A Visual C++ Redistributable installs Microsoft C and C++ Runtime libraries."
Microsoft notes that many applications built with MSVC require these libraries, so whether a machine already has them depends on what was installed on it before. A fresh Windows install or a clean CI runner may not have them. That fits the question: the project runs on one Windows 11 machine and not on the other, and copying node_modules changes nothing, because the DLL lives in Windows, not in the project.
Two independent reports confirm the remedy. In the podman-desktop CI report, vite build failed on a Windows runner with the same ERR_DLOPEN_FAILED on rollup.win32-x64-msvc.node. The project then added a CI step that installs the Redistributable, and the follow-up comment reports that it works. In npm/cli#7045, opened two days after the question with the same message in its title, on Windows 11 and Node v20.10.0, the fix reported was installing the latest Visual C++ Redistributable.
Fix#
1. Confirm it is the DLL case#
Scroll to the end of the error and find the [cause] block. You need both: the message "The specified module could not be found" (or its translation) followed by the full path of rollup.win32-x64-msvc.node, and code: 'ERR_DLOPEN_FAILED'. Then check that the file really is there:
Test-Path node_modules\@rollup\rollup-win32-x64-msvc\rollup.win32-x64-msvc.nodeTrue puts you on this page. False means the package is missing, which is the other cause in the table above.
2. Update Rollup inside Vite's range#
Vite 5.0.0 declares rollup as ^4.2.0, so every Rollup 4 release from 4.2.0 up satisfies it. A lockfile written in late 2023 keeps the old one until you ask npm to move it:
npm update rollup
npm ls rollupIn the reproduction, the lockfile pinned Rollup 4.6.0 and package.json was left unchanged. One npm update rollup (npm 11.19.0) moved it to the current release:
`-- vite@5.0.0
`-- rollup@4.64.5The new binary no longer imports the Visual C++ runtime. Its full import list:
kernel32.dll
api-ms-win-core-synch-l1-2-0.dll
ntdll.dll
bcryptprimitives.dll
ADVAPI32.dll
KERNEL32.dllThe change came in Rollup 4.9.5, released on 12 January 2024. Its changelog lists "Fix issue where on Windows, Rollup would not load due to problems with the MSVC executable", and PR #5335 adds the crt-static target feature to the x86_64-pc-windows-msvc build, which links the runtime into the binary. Comparing the published binaries confirms the boundary: 4.9.4 still imports VCRUNTIME140.dll, 4.9.5 does not. Commit the updated package-lock.json so every machine gets the same Rollup.
3. Or install the Visual C++ Redistributable#
If you cannot change the lockfile today, install the missing runtime instead. Microsoft's permalink for the latest supported x64 package is aka.ms/vc14/vc_redist.x64.exe, listed on the Redistributable downloads page. On a machine with winget:
winget install --id Microsoft.VCRedist.2015+.x64 -eThen open a new terminal and run Vite again. This step was not reproduced: the test machine already had the runtime, which is why the missing DLL had to be simulated. It rests on Microsoft's documentation and the two reports above.
Verify the fix#
npm ls rollup
npm run buildnpm ls rollup should print 4.9.5 or later under vite, and the build should end on a line such as:
✓ built in 234msA green build on a machine that already has the runtime proves nothing about the DLL. On x64, the import list in step 2 is what shows the dependency is gone, so the binary no longer depends on the Redistributable.
One email a month — the latest explained errors
What the site published that month — mostly Next.js, Supabase and Node errors, explained. You confirm by email; unsubscribe any time in one click.
Windows on ARM, non-English Windows and the wasm build#
Windows on ARM still needs the Redistributable. The static linking in PR #5335 applies to the x64 build only. The current @rollup/rollup-win32-arm64-msvc 4.64.5 binary still imports VCRUNTIME140.dll. With an ARM64 build of Node, Rollup loads that binary, so step 2 does not help and step 3 is the fix. Microsoft notes that the x64 Redistributable package contains both the ARM64 and the x64 binaries.
A newer friendly message, in English only. Rollup 4.7.0 (changelog, PR #5284) added a dedicated message: "Required DLL was not found. This error usually happens when Microsoft Visual C++ Redistributable is not installed." The current native.js prints it only when the Windows error message includes the English sentence "The specified module could not be found". With Rollup 4.9.4 on the French Windows of the reproduction, the cause was translated, the check did not match, and Rollup fell back to the old text:
Error: Cannot find module @rollup/rollup-win32-x64-msvc. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.So on Rollup 4.7.0 to 4.9.4 with a non-English Windows, the misleading message is still what you see. The same applies today on a non-English Windows on ARM: the current native.js keeps the English-only check, and the ARM64 binary still imports the runtime. The ERR_DLOPEN_FAILED code is the reliable signal in every language.
The answers on the question. Two of the answers add @rollup/rollup-linux-x64-gnu to package.json. That is the Linux binary, and Windows never loads it, so it cannot fix a Windows DLL load. It belongs to the other problem, a Linux CI or Docker build missing its own binary. The third answer overrides rollup with npm:@rollup/wasm-node, Rollup's WebAssembly build, which has no native binary to load. A reporter in rollup#5571 used this override as a workaround for a different load failure, "The specified procedure could not be found", which updating the Redistributable did not fix. That issue is still open. The override swaps in the WebAssembly build for the whole project; it is a workaround, not the fix for a missing runtime.
Other native packages fail in their own ways when the binary does not match the machine running it: Node Sass could not find a binding is a binding installed under another Node version or OS, and the Exec format error in Docker Compose is a .node file built on the host and run unchanged inside a Linux container. Once Rollup loads, the next failure in a Vite build usually comes from the project's own files. If the build then reports that Rollup failed to resolve your entry script, continue with the Vite entry resolution fix, which covers an index.html placed inside src with a custom root.
Further reading: Fix Vite [commonjs--resolver] Failed to resolve entry.
Frequently Asked Questions
Still stuck? Paste your error.
Paste the error message or stack trace — we check it against every fix and tool on the site.
Continue Reading
Fix Cannot find module @rollup/rollup-win32-x64-msvc
Find out where your node_modules came from, reinstall it for the machine that runs Vite, and avoid the popular fix that breaks Linux CI and Docker builds.
Expected identifier but found "import" (define name) in Vite
Why a Vite 6 project stops before the dev server starts, why reinstalling from the same lockfile brings the error back, and the one-line update that clears it.
Fix Vite [commonjs--resolver] Failed to resolve entry
Reproduced on Vite 3, 4, 7 and 8: why a CommonJS dependency makes vite build stop on a package entry, why the odd "main" field is not the cause, and three fixes that each work on their own.


