A GlobalMutex that is abandoned due to a crash can leave an application in an un-runnable state (requires reboot) #1533

From Claude (regarding crash in Paratext 10):
How the original run got into "bad state"

The mutex is normally held only for a brief Save(), but the window widens during first-run / schema migration: the stack shows LdmlInFolderWritingSystemRepositoryMigrator.ResetRemovedProperties → Save() (:233-234), which rewrites LDML writing-system files under lock. Anything that hard-kills the data provider during that window abandons the mutex:

• A hang + force-kill (Task Manager), or the machine freezing / hard power-off / sleep-resume glitch.
• Multiple PT10 instances contending on the same global mutex — plausible given she has several test projects and possibly a dev build alongside the installed one; killing one mid-Save() abandons it for the others.

Why the reboot fixed it

Named Windows mutexes are kernel objects that live only as long as a handle is open (or until reboot). If an orphaned/hung process from the bad run kept the object alive in its abandoned state, every relaunch inherited the poison. The reboot destroyed the kernel object (and any orphan holding it), so the next launch created a fresh, un-abandoned mutex. Deleting projects wouldn't have helped; killing every lingering Paranext.DataProvider/PT10 process would have been the non-reboot equivalent.