“.NET 8 Desktop Runtime” Error: Fix for BG3 Mod Manager (2026)

The .NET 8 Desktop Runtime is the Windows-only redistributable that includes Windows Presentation Foundation (WPF) and Windows Forms support on top of the cross-platform .NET 8 base runtime. BG3 Mod Manager is a WPF application, which means it uses the desktop UI libraries that ship exclusively in the Desktop Runtime package. The cross-platform runtime that powers ASP.NET Core web servers does not contain those libraries, so it cannot host a WPF app even though it shares the same base CLR (Common Language Runtime).

Up to and including v1.0.11.x, BG3 Mod Manager targeted .NET 7 (and originally .NET Framework 4.7.2 in the very early builds). The migration to .NET 8 happened in late 2024 alongside Patch 7 compatibility work, partly because Microsoft retired security support for .NET 7 in May 2024 and partly because .NET 8 is a Long Term Support (LTS) release that the maintainer can rely on through November 2026. The change is documented in the project’s release notes and was discussed at length in GitHub issue #73 and the related runtime migration thread #213, where users running older .NET 6 / .NET 7 desktop runtimes reported the manager refusing to start.

What this means in practical terms: the BG3 Mod Manager binary is roughly 11.1 MB precisely because it does not bundle the runtime. A self-contained build that included .NET 8 would weigh closer to 80–90 MB. The maintainer chose the framework-dependent deployment model so that a single Microsoft-supplied runtime can serve all .NET 8 applications on the machine, including future BG3 Mod Manager updates, without each tool shipping its own copy. The trade-off is that the runtime becomes a hard prerequisite, and a missing runtime produces the error this article exists to fix.

Before downloading the installer, users should verify the current state of .NET on the machine. Three independent checks (a CLI command, the Apps list, and a registry key) will tell users with certainty whether the Desktop Runtime is present and at what version.

Check 1: dotnet –list-runtimes

Open PowerShell or Command Prompt and run:

dotnet --list-runtimes

A correctly configured machine will list at least one entry beginning with Microsoft.WindowsDesktop.App 8.0.x. If the only output is Microsoft.NETCore.App 8.0.x or Microsoft.AspNetCore.App 8.0.x, the Desktop Runtime is not installed even though .NET 8 itself is. That single distinction explains the majority of “but .NET 8 is already installed” support questions raised in the LaughingLeader repository.

If the dotnet command itself is not recognised, no .NET runtime is installed at all and the next sections apply directly.

Check 2: Apps & Features (or Settings > Apps)

Open Settings > Apps > Installed apps on Windows 11, or Control Panel > Programs and Features on Windows 10. Search the list for Microsoft Windows Desktop Runtime. The required entry is Microsoft Windows Desktop Runtime - 8.0.x (x64). Entries that read .NET Runtime - 8.0.x (x64) (without the word “Desktop”) are the cross-platform runtime and will not satisfy the BG3 Mod Manager requirement on their own.

Check 3: Registry Confirmation

For full certainty, users can confirm the install through the Windows registry. Run the following from an elevated PowerShell prompt:

Get-ChildItem 'HKLM:\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedhost' -ErrorAction SilentlyContinue
Get-ChildItem 'HKLM:\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedfx\Microsoft.WindowsDesktop.App' -ErrorAction SilentlyContinue

The second key is the authoritative location for Desktop Runtime versions. If the key does not exist or returns no values, the Desktop Runtime is not installed regardless of what other .NET-related entries appear elsewhere on the system.

The installer ships exclusively from Microsoft’s official .NET site. Third-party mirrors should be avoided because the package is signed and any tampered copy will fail signature validation during install.

1. Open https://dotnet.microsoft.com/download/dotnet/8.0 in any browser. The page lists three runtime flavours per architecture: .NET Runtime, ASP.NET Core Runtime, and .NET Desktop Runtime.
2. Locate the row labelled .NET Desktop Runtime 8.0.x in the list. The current LTS patch level as of May 2026 is 8.0.14 or later; any 8.0.x release will work for BG3 Mod Manager.
3. Click the x64 link in that row. The downloaded file is named in the form windowsdesktop-runtime-8.0.x-win-x64.exe and is roughly 58 MB.
4. Right-click the downloaded installer and choose Run as administrator. Administrator rights are required because the runtime files are written to C:\Program Files\dotnet\, which is protected by Windows’ standard ACLs.
5. Accept the licence terms and click Install. The installer typically completes in 30–60 seconds. A success screen confirms the installed version, for example .NET Windows Desktop Runtime 8.0.14 was installed.
6. Close the installer and reboot. A reboot is not strictly required by the .NET installer itself, but it ensures that any partially-loaded BG3 Mod Manager process from the previous attempt is cleared from memory and that PATH changes propagate to all sessions.

After the reboot, double-click BG3ModManager.exe from the extracted folder (typically C:\Tools\BG3ModManager or wherever the user extracted the archive). On a healthy system the manager window opens within two to three seconds and begins enumerating the BG3 Data folder. Users who still cannot launch the application should not assume the runtime install failed silently and instead consult the next section.

A frustrating subset of users report that the Microsoft installer reaches its success screen yet BG3 Mod Manager still produces the same dialog or fails to open at all. Three patterns explain almost all of these cases.

Pattern 1: Wrong Architecture (x86 Installed Instead of x64)

BG3 Mod Manager is a 64-bit application and the .NET 8 Desktop Runtime it loads must also be 64-bit. Some users with older Windows machines accidentally download the x86 installer because it is listed first on certain mirror pages. The x86 runtime installs successfully but registers under HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\, which BG3 Mod Manager does not consult. The fix is to download the x64 installer from the Microsoft page and run it; both installers can coexist without conflict.

Pattern 2: Wrong Runtime Flavour (ASP.NET Core or SDK)

Developers who already have the .NET 8 SDK installed sometimes assume nothing more is needed. The SDK includes the cross-platform runtime but not the Windows Desktop libraries. Similarly, the ASP.NET Core Runtime is intended for web server hosts and omits WPF entirely. Running dotnet --list-runtimes will show entries without Microsoft.WindowsDesktop.App, confirming the gap. Installing the standalone Desktop Runtime resolves this without removing the SDK.

Pattern 3: Silent Antivirus Quarantine of BG3ModManager.exe

This pattern looks identical to a runtime failure but has nothing to do with .NET. Some heuristic-based antivirus products (Norton, Bitdefender, certain Windows Defender configurations on managed devices) flag unsigned WPF binaries that load native LSLib code as suspicious and either delete the executable outright or block process creation. The user sees no window and assumes .NET is the problem. Confirm by checking the antivirus quarantine log and by re-extracting the archive after adding the BG3 Mod Manager folder to the antivirus exclusion list. Issue #238 on the LaughingLeader tracker contains a representative thread covering this exact symptom.

Diagnostic: Read the Windows Event Viewer

When BG3 Mod Manager fails silently, Windows still records the failure. Open Event Viewer > Windows Logs > Application and filter for .NET Runtime or BG3ModManager.exe as the source. A genuine missing-runtime failure logs an event with the text You must install or update .NET to run this application. App: BG3ModManager.exe ... Architecture: x64 ... Framework: 'Microsoft.WindowsDesktop.App', version '8.0.0' (x64). An antivirus block, by contrast, logs an event from the security product itself with the BG3 Mod Manager path as the affected file.

A small percentage of users hit edge cases that the standard installer flow does not cover. Each of the following has been confirmed in real support threads and has a workaround.

Managed Work Laptops with Restricted Installer Rights

Domain-joined corporate machines often deny standard users the right to run MSI or EXE installers that write to C:\Program Files. The .NET 8 Desktop Runtime can still be deployed in those environments using either the IT department’s software distribution platform (Microsoft Endpoint Manager, SCCM) or the Microsoft-provided per-user install script. The Microsoft dotnet-install scripts documentation describes the --runtime windowsdesktop --version 8.0.x --install-dir $env:LOCALAPPDATA\dotnet invocation, which writes to the user’s profile and does not require administrator rights. BG3 Mod Manager will pick up that runtime if $env:LOCALAPPDATA\dotnet is added to PATH and to the DOTNET_ROOT environment variable.

Windows on ARM64 (Surface Pro X, Copilot+ PCs)

BG3 Mod Manager is distributed only as an x64 binary. On ARM64 Windows, the operating system runs x64 applications under emulation, which means the runtime that satisfies BG3 Mod Manager must also be the x64 build, not the ARM64 build. Installing the ARM64 .NET 8 Desktop Runtime alone produces the same “runtime not found” dialog because the emulator looks up the x64 sharedfx key. The fix is to install both: the ARM64 runtime for native apps and the x64 runtime for emulated apps including BG3 Mod Manager.

Leftover .NET 7 Installs After Auto-Update

Windows Update has been observed to remove end-of-life .NET 7 components automatically without notifying the user. Machines that previously ran BG3 Mod Manager v1.0.11 with .NET 7 installed may have lost the runtime entirely, which produces a confusing pattern where a tool that worked yesterday no longer launches today even though the user has installed nothing new. This is not a bug in the mod manager: it is the expected outcome of Microsoft’s end-of-life cleanup. Installing .NET 8 Desktop Runtime restores normal operation.

ASP.NET Core Runtime Already Installed (Common with Visual Studio Code)

Developers who installed Visual Studio Code’s C# Dev Kit, or who manually installed the ASP.NET Core 8 Hosting Bundle for local web development, frequently see .NET Runtime 8.0.x in their Apps list and conclude that the prerequisite is met. As covered above, the Hosting Bundle does not contain WindowsDesktop libraries. The standalone Desktop Runtime installer must be run additionally; it does not conflict with the Hosting Bundle and can sit alongside it.

After the runtime is installed and the system has been rebooted, three short checks confirm that BG3 Mod Manager is now binding to the expected .NET 8 Desktop Runtime rather than falling back to a stale registration.

1. Re-run dotnet --list-runtimes. The output must include a line of the form Microsoft.WindowsDesktop.App 8.0.x [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]. The path should be the system-wide install directory.
2. Launch BG3 Mod Manager and check the title bar. A working v1.0.12.9 install displays BG3 Mod Manager v1.0.12.9 at the top of the window and populates the Active and Inactive load order panes within seconds.
3. Open the Help > About dialog if the maintainer ships one in the current build, or examine BG3ModManager.exe via PowerShell: (Get-Item 'C:\Tools\BG3ModManager\BG3ModManager.exe').VersionInfo.FileVersion reports the exact build string.

Users who have completed all three checks but still see issues unrelated to the runtime (mods not detected, paths incorrect, load order resetting) should consult the configuration topics on the BG3 Mod Manager guide homepage or the download page for current version and prerequisite information. Those problems are not caused by .NET 8 and have separate diagnostic procedures.