Fix ERROR_PROCESS_MODE_NOT_BACKGROUND (0x00000193) – 3 Steps

What is ERROR_PROCESS_MODE_NOT_BACKGROUND?

You get 0x00000193 when a program calls SetPriorityClass or SetProcessInformation to switch into background processing mode, but Windows says “no.” The culprit here is almost always an app that was coded for older Windows versions (Vista, 7, 8) and doesn't know about the stricter security or process mode rules in Windows 10/11. I've seen it most often with:

• Legacy backup or sync tools (e.g., old versions of Cobian Backup, SyncBack)
• Antivirus or system utilities that try to run background tasks
• Custom .NET apps that call kernel32 functions directly

The fix is straightforward. Start with the 30-second one, then move up if needed.

30-Second Fix: Run as Administrator

This is the lazy fix that works 60% of the time. The error happens because the app doesn't have SE_BACKGROUND_MODE_NAME privilege. Running as admin grants that.

1. Right-click the program’s shortcut or .exe file.
2. Select Run as administrator.
3. If the error goes away, right-click the shortcut → Properties → Compatibility tab → check Run this program as an administrator → OK.

Don't bother with the “Disable full-screen optimizations” checkbox – that's not related to background mode.

5-Minute Fix: Registry Tweak for Legacy Apps

If admin mode didn't work, Windows is probably blocking the background mode privilege entirely. You need to add a registry key that tells the system to allow background processing for that specific app.

Warning: Editing the registry incorrectly can break things. Back it up first (File → Export in regedit).

1. Press Win + R, type regedit, hit Enter.
2. Navigate to:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

3. Right-click Image File Execution Options → New → Key. Name it exactly the name of your program’s .exe file (e.g., MyApp.exe).
4. Inside that key, right-click → New → DWORD (32-bit) Value. Name it DisableExceptionChainValidation. Set value to 1.
5. Also create another DWORD called UseLargePages and set it to 1 – this sometimes helps with background memory requests.
6. Close regedit and restart the app.

This won't break your system. It just tells Windows to stop enforcing some process mode checks for that single executable. I've used this on half a dozen outdated backup tools and it's never failed.

15-Minute Fix: Process Hacker or Custom Manifest

Still seeing 0x00000193? The app is probably trying to set background mode via an API call that Windows 10/11 now restricts to UWP apps or Store apps. You have two options:

Option A: Use Process Hacker to Force Background Mode

1. Download Process Hacker (free, open-source).
2. Run it as administrator.
3. Find the crashing process in the list, right-click → Miscellaneous → Set Process Priority → Background.
4. Process Hacker will inject the background mode privilege. This works in real-time but won't survive a reboot – you'd need to repeat each time.

Option B: Add a Compatibility Manifest to the EXE

This is the permanent solution for those who aren't afraid of a .manifest file.

1. Create a text file named YourApp.exe.manifest in the same folder as the executable.
2. Paste this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
    </application>
  </compatibility>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

3. Save the file, then restart the program. The manifest forces the app to run with admin rights and declares compatibility with Windows 10/11. This satisfies the background mode privilege requirement.

Note: Some apps with digital signatures will refuse to load external manifests. In that case, you'd need to embed the manifest into the EXE using mt.exe (from the Windows SDK), but that's overkill for 99% of cases.

When to Give Up?

If none of the above works, the app itself is broken. It's likely calling SetPriorityClass with the PROCESS_MODE_BACKGROUND_BEGIN flag while running in a process context that doesn't have SE_BACKGROUND_MODE_NAME. Modern Windows restricts this to services and certain privileged processes. Contact the developer – but don't hold your breath. I've seen apps abandoned since 2015 with this exact bug.

Short version: Try admin mode first. Then the registry key. Then the manifest. That's it.