STATUS_LONGJUMP 0X80000026: What It Means and How to Fix It

When This Error Strikes

You’re working on a project, running a legacy app, or maybe a game, and suddenly it crashes with STATUS_LONGJUMP (0X80000026). The exact error message reads: “A long jump has been executed.” I saw this one two weeks ago on a client’s Windows 11 machine running a custom inventory tool they’d had since Windows 7. The app would load fine, then die during a save operation. Another scenario: a developer compiling C code using setjmp/longjmp—the program exits with this exact code. It’s not a driver crash or hardware fault; it’s a user-mode exception meaning something went wrong with a non-local jump.

What’s Really Happening

Under the hood, longjmp is a C/C++ function that jumps back to a saved program state, bypassing normal function returns. Windows translates that into a structured exception—STATUS_LONGJUMP—when the jump succeeds. So why does it crash? The application called longjmp with a corrupted or invalid jump buffer. Common triggers:

• Memory corruption—a buffer overflow or use-after-free trashes the jmp_buf structure.
• Stack corruption—stack overflow or mismatched setjmp/longjmp calls (like jumping across threads).
• Bad update—a Windows Update or app patch changed how memory is managed.

It’s rare, but when it hits, it’s almost always in older software or custom code that uses non-local jumps. The OS isn’t broken; your app is doing something illegal.

How to Fix It

Step 1: Identify the Culprit App

1. Open Event Viewer (press Win+R, type eventvwr.msc, hit Enter).
2. Go to Windows Logs > Application.
3. Look for an Error event with 0X80000026 in the details. Note the crashing executable name (e.g., inventory_app.exe) and module.

If you don’t see it, run the app again and refresh Event Viewer. Had a client last month whose print queue died because of this—turns out a third-party print driver was corrupting the jump buffer.

Step 2: Check for Memory Corruption

Memory issues are the #1 cause. Run a memory test:

mdsched.exe

Restart and let it run. If it finds errors, replace your RAM. But 90% of the time, it’s not hardware—it’s software corruption. Next, use System File Checker to fix OS files:

sfc /scannow

Then run DISM for a deeper repair:

DISM /Online /Cleanup-Image /RestoreHealth

This won’t fix a broken app, but it’ll rule out OS corruption.

Step 3: Roll Back or Reinstall the App

If the error started after an update:

• Windows Update: Go to Settings > Windows Update > Update history > Uninstall updates. Remove the most recent update (note the KB number from Event Viewer).
• App update: Uninstall the app completely, reboot, then reinstall the previous version from backup or vendor site.

For the client with the inventory tool, the fix was rolling back a .NET Framework update that broke the app’s garbage collection.

Step 4: Debug with WinDbg (Advanced)

If you’re a developer or IT pro, grab the crash dump. When the app crashes, a .dmp file is saved to %LOCALAPPDATA%\CrashDumps. Open it with WinDbg:

.symfix
.reload
!analyze -v

Look for the stack trace—specifically the function that called longjmp. If the buffer address looks garbage (e.g., 0x41414141), that’s a buffer overflow. If you see ntdll!RtlLongJumpWorker, the jump itself succeeded but the target code crashed—often a null pointer dereference afterward. Patch the code with proper error handling or use setjmp/longjmp only within the same thread and same stack frame.

If It Still Fails

After all that, still crashing? A few things to check:

• Antivirus interference: Temporarily disable real-time protection. I’ve seen Norton hooking into longjmp and corrupting the stack.
• DLL hell: Use Process Monitor (procmon.exe) to see which DLLs the app loads. A mismatch between 32-bit and 64-bit DLLs can cause this.
• Hardware fault: Under very rare conditions, a failing CPU or motherboard can corrupt memory. Swap in known-good hardware if possible.

Bottom line: STATUS_LONGJUMP is a sign your app has a memory bug or a bad update. Start with Event Viewer, run SFC, roll back changes, and only break out WinDbg if you’re comfortable. Most people fix it in the first three steps.