How to Fix: Attempted to load @next/swc-win32-x64-msvc, but an error occurred: Invalid access to memory location. \\?\D:\PROJECT\pondokkopi\node_modules\@next\swc-win32-x64-msvc\next-swc.win32-x64-msvc.node

This error usually means Next.js successfully found the native SWC binary for Windows, but Windows refused to load the compiled module at runtime. In this specific setup, the failure is commonly triggered by the combination of Bun, Next.js dev mode, Turbopack, and the platform-specific package @next/swc-win32-x64-msvc on Windows.

Understanding the Root Cause

@next/swc-win32-x64-msvc is the native Rust-based compiler binary used by Next.js on 64-bit Windows systems built with the MSVC toolchain. When you run next dev –turbopack, Next tries to load this native .node module directly.

The message “Invalid access to memory location” indicates the native module was located, but failed during loading or initialization inside the Windows process. That usually happens for one of these reasons:

• Runtime compatibility issues between Bun and Next.js native binaries. Bun can run many Node.js workflows, but native addons are stricter than normal JavaScript packages.
• A corrupted or incomplete install inside node_modules, especially if the optional native package was not installed cleanly.
• Turbopack-specific startup behavior exposing a bug that may not appear with the classic webpack dev server.
• Windows environment problems, including security software, broken Visual C++ runtime dependencies, or filesystem-level issues affecting native module loading.

In short: this is not a normal syntax or application-code bug. It is a native binary loading problem involving the Windows SWC package.

Step-by-Step Solution

The most reliable fix is to verify whether the issue is caused by Bun, Turbopack, or a broken native install, then switch to a supported path.

1. Confirm your environment versions

Check your Bun, Node.js, and Next.js versions first.

bun --version
node --version
npx next --version

If Node.js is missing, install the current LTS release from the official Node.js website.

2. Remove installed artifacts and reinstall dependencies

Delete the lockfile and dependency folder, then reinstall cleanly.

rmdir /s /q node_modules
del bun.lockb
del package-lock.json
del pnpm-lock.yaml
del yarn.lock

Then reinstall using Bun:

bun install

After that, try the dev server again:

bun run dev

If the same error appears, continue with the isolation steps below.

3. Test with Node.js instead of Bun

This is the most important diagnostic step. Install dependencies with npm and run Next using Node’s ecosystem.

rmdir /s /q node_modules
npm install
npm run dev

If npm run dev works but bun run dev fails, the root problem is likely Bun compatibility with the native Next.js SWC/Turbopack stack on Windows.

In that case, use Node.js for development on Windows until Bun support for this path is stable.

4. Disable Turbopack and test the classic dev server

If your dev script is using next dev --turbopack, remove the Turbopack flag temporarily.

{
  "scripts": {
    "dev": "next dev"
  }
}

Then run:

npm run dev

or

bun run dev

If disabling Turbopack fixes the issue, then the crash is likely tied to the Turbopack + Windows + Bun/native SWC combination rather than your application code.

5. Force reinstall the SWC native package

Sometimes the platform package exists on disk but is damaged or incomplete. Reinstall it explicitly.

npm remove @next/swc-win32-x64-msvc
npm install @next/swc-win32-x64-msvc --save-dev

Then reinstall the rest if needed:

npm install

Retry the dev server:

npm run dev

Note: in many projects, this package is managed transitively by Next.js, so the main value here is forcing a fresh binary download.

6. Update Next.js and Bun

Native loading issues are often fixed in patch releases. Upgrade to the latest stable versions.

bun add next@latest react@latest react-dom@latest

Also update Bun from the official Bun website and retry.

7. Check Windows security and runtime dependencies

If the module still fails to load under both Bun and Node, the operating system may be blocking or failing to initialize the binary.

• Temporarily disable antivirus or Windows Defender real-time scanning for the project folder.
• Move the project to a simpler local path such as C:\dev\project.
• Install or repair the Microsoft Visual C++ Redistributable from the official Microsoft documentation.
• Make sure you are on 64-bit Windows.

8. Recommended stable workaround

For Windows developers hitting this exact issue after running bun create next-app and then bun run dev, the most practical workaround is:

npm install
npm run dev

Or keep Bun for package management but run the dev server with Node:

bun install
npx next dev

This avoids the most fragile part of the toolchain while preserving your project setup.

Common Edge Cases

• Issue only happens with Turbopack: If next dev works but next dev --turbopack fails, the bug is likely Turbopack-specific.
• Issue only happens with Bun: If npm works and Bun does not, treat it as a runtime compatibility issue rather than a broken app.
• Corporate antivirus blocks native binaries: Security tools sometimes quarantine or sandbox .node files inside node_modules.
• Broken optional dependency install: Some native platform packages are installed as optional dependencies and may be skipped or corrupted during install.
• Network or cache corruption: If package downloads were interrupted, clear caches and reinstall.

You can clear npm’s cache with:

npm cache clean --force

And Bun’s cache with:

bun pm cache rm

FAQ

Is this a Next.js bug or a Bun bug?

It can be either, but in this reproduction the strongest signal is the Windows native SWC module failing during a Bun-driven Next.js dev startup. If the same project works with npm or Node.js, Bun compatibility is the likely trigger.

Why does the file exist if Next.js still cannot load it?

The file being present only proves the package was downloaded. Windows still has to load the native binary into the process, resolve dependencies, and initialize it successfully. The error occurs during that loading phase.

Can I safely keep using Bun in this project?

Yes, but the safest approach on Windows is often to use Bun for installation and Node.js for running Next dev until the native loading path is stable in your environment.

If you want the shortest path to productivity, use Node.js LTS, remove –turbopack temporarily, reinstall dependencies cleanly, and verify the app starts with npm run dev. That sequence resolves most cases of this exact @next/swc-win32-x64-msvc memory-access load failure.