DOTNET_BUNDLE_EXTRACT_BASE_DIR is not set, and a read-write cache directory couldn't be created.

Create a private, writable extraction folder and set DOTNET_BUNDLE_EXTRACT_BASE_DIR to it so Wabbajack does not depend on the currently unusable temporary directory.

Set a dedicated extraction directory

1. Open Windows PowerShell normally—not as Administrator.
2. Run:

$bundleDir = Join-Path $env:LOCALAPPDATA "DotNetBundleExtract"
New-Item -ItemType Directory -Path $bundleDir -Force | Out-Null

$testFile = Join-Path $bundleDir "write-test.tmp"
Set-Content -Path $testFile -Value "test"
Remove-Item $testFile

[Environment]::SetEnvironmentVariable(
    "DOTNET_BUNDLE_EXTRACT_BASE_DIR",
    $bundleDir,
    "User"
)

3. Sign out of Windows and sign back in, so newly started applications receive the environment variable.
4. Start C:\Wabbajack\Wabbajack.exe normally.

DOTNET_BUNDLE_EXTRACT_BASE_DIR explicitly selects where a .NET single-file application extracts its embedded files.^1^ Without it, a Windows single-file application extracts under %TEMP%\.net; therefore, an invalid or non-writable temporary directory produces this type of startup failure.^2^

Do not grant Everyone access to this directory. It should remain writable only by your account and administrators because .NET recommends preventing modification by users or services running with different privileges.^2^

Repair TEMP and TMP as the broader fix

The dedicated directory should allow Wabbajack to start, but other applications may still fail if your user temporary-directory configuration is broken.

1. Press Windows key + R, enter sysdm.cpl, and select OK.
2. Open Advanced → Environment Variables.
3. Under User variables, examine TEMP and TMP.
4. Set both to:

      %USERPROFILE%\AppData\Local\Temp
   

   This is the typical per-user location for both variables.^3^
5. In File Explorer, enter %LOCALAPPDATA% in the address bar. Create the Temp folder if it does not exist.
6. Right-click Temp → Properties → Security. Your account should have Modify, Read & execute, List folder contents, Read, and Write.
7. Sign out and back in, then test in a normal PowerShell window:

$env:TEMP
$env:TMP
Test-Path $env:TEMP

$test = Join-Path $env:TEMP "write-test.tmp"
Set-Content $test "test"
Remove-Item $test

The final two commands should complete without an “Access denied” or “path not found” error. Windows temp-path resolution checks TMP, then TEMP, then USERPROFILE, but selecting a value does not itself verify that the directory exists or is accessible.^4^

Why the read-only checkbox did not help

The read-only checkbox shown for a folder is not the effective Windows write-permission control. The FILE_ATTRIBUTE_READONLY attribute is not honored on directories; actual access is controlled through the folder’s Security permissions.^5^ It is therefore normal for changing that checkbox not to resolve this error.

If the write test still fails after correcting TEMP and TMP, inspect the permissions without changing them:

icacls "$env:LOCALAPPDATA\Temp"

icacls displays the directory’s access-control list.^6^ Avoid using /reset or recursively changing permissions across AppData; if the ACL is damaged, test Wabbajack from a newly created Windows user account. If it works there, the problem is isolated to the original user profile.

References

1. .NET environment variables
2. Single-file deployment
3. Recognized environment variables
4. GetTempPathW function (fileapi.h)
5. File Attribute Constants
6. icacls