Fix Windows Stop Code 0x00000039: SYSTEM_EXIT_OWNED_MUTEX

Quick Answer

SYSTEM_EXIT_OWNED_MUTEX (0x00000039) occurs when a Windows kernel worker routine finishes while it still owns a mutex it should have released. A mutex controls access to a shared resource. Microsoft says a debugger is required to identify the driver responsible. If crashes repeat, record recent driver changes and preserve a crash dump; an IT professional can use its first bug-check parameter to locate the worker routine in WinDbg. Microsoft Learn

What the Error Means

A worker thread can carry out queued tasks for drivers. When a worker routine acquires a mutex, it must release ownership before returning. With bug check 0x39, the routine returned while still owning one. The thread would otherwise move on to unrelated work, leaving that mutex unreleased, so Windows stops. This describes a kernel driver programming error; the stop-code name does not identify the driver. Microsoft Learn

The four bug-check parameters help a debugger investigate it:

Before You Begin

Save important work and back up data before making driver or recovery changes. Record the crash time, any driver or device named on the stop screen, and updates or hardware installed shortly before the first crash. Driver rollback requires administrator permissions. On a managed computer, coordinate driver changes with IT support. Microsoft Support

Initial Troubleshooting

These steps can isolate a recent change. They do not replace dump analysis when the responsible driver is unknown.

1. Check whether the crash repeats. Record the code after a one-time crash. If it recurs, note the activity preceding each occurrence.
2. Disconnect recently added hardware. Shut down first, remove the new device, then restart and test. Microsoft recommends this as an initial check for recurring stop errors. Microsoft Support
3. Inspect Device Manager. Right-click Start > Device Manager and check for devices marked with an exclamation point. Note drivers changed just before the crashes. Microsoft Support
4. Roll back a plausible recent driver update. Right-click the affected device and select Properties > Driver > Roll Back Driver. Follow the prompts and restart if requested. If rollback is unavailable, Windows may not have a previous driver to restore.
5. Update an identified suspect if rollback does not apply. Check Windows Update or obtain a driver matching the device and Windows version from its manufacturer’s official site. Change one suspected component at a time. Microsoft Support

If Windows cannot start normally, use Safe Mode to investigate or reverse a recent change. If a driver change creates a new problem, roll it back where possible or reinstall the appropriate manufacturer driver. Microsoft Support

Advanced Troubleshooting with WinDbg

For recurring 0x39 crashes, preserve the newest dump. Small dumps, when configured and successfully created, are stored in %SystemRoot%\Minidump; several larger dump types use %SystemRoot%\MEMORY.DMP. Microsoft Learn

1. Open the relevant dump in WinDbg and run:

   !analyze -v

2. Find Arg1, the address of the worker routine. Then run:

   ln <address-from-Arg1>

   Replace <address-from-Arg1> with the actual address shown for the first bug-check parameter. Do not type the angle brackets. The ln command shows symbols at or near that address and can help identify the routine’s module. Microsoft Learn

3. Compare the identified module with its vendor, version, call stack, and the PC’s recent changes. An incomplete dump or unavailable symbols can limit the conclusion. If a third-party driver is implicated, seek a compatible update or provide the findings to its vendor.

Avoid enabling Driver Verifier casually on a production PC. Microsoft warns that it can cause additional crashes and recommends it for systems used in testing and debugging. learn.microsoft.com

How to Verify the Fix

Restart after a targeted driver change and repeat the activity associated with the crash. Confirm that the device still works and 0x39 does not return. If it does, preserve the new dump and compare it with the earlier one; do not assume a change worked solely because the PC restarted successfully.

Frequently Asked Questions

Does “system exit” mean a user account logged off?

No. This bug check concerns a kernel worker routine returning while it owns a mutex. Microsoft Learn

Is the mutex itself defective?

A mutex is a software synchronization object. The error concerns how a worker routine managed its ownership, not a physical component. Microsoft Learn

Can the stop code identify the faulty driver by itself?

No. Microsoft directs investigators to use a debugger and the worker routine address in parameter one. Microsoft Learn

Will a system file repair command fix 0x39?

There is no Microsoft repair command specific to this bug check. Identify the responsible routine and driver before choosing a correction.

What should I send to a driver vendor?

Provide the Windows version, the driver and device details, the crash time, the WinDbg findings, and the dump through the vendor’s approved support channel. A dump can contain information held in system memory, so follow your organization’s data-handling rules.

Conclusion

Stop code 0x39 has a specific programming cause: a worker routine returned without releasing its mutex. Recent driver changes offer a starting point, but a recurring crash calls for dump analysis. The first bug-check parameter and WinDbg’s ln command provide the most direct lead to the responsible routine.

Sources

• Microsoft Learn, Bug Check 0x39: SYSTEM_EXIT_OWNED_MUTEX. Microsoft Learn
• Microsoft Learn, Introduction to Mutex Objects. Microsoft Learn
• Microsoft Learn, ln (List Nearest Symbols). Microsoft Learn
• Microsoft Support, Troubleshooting Windows unexpected restarts and stop code errors. Microsoft Support
• Microsoft Support, Update drivers through Device Manager in Windows. Microsoft Support
• Microsoft Learn, Stop code error or bug check troubleshooting.