Data loss (layout): workspace.json wiped to 0KB when closing Obsidian; all tabs and windows lost

Steps to reproduce

  1. Open multiple notes in tabs in the main window, and open multiple notes in tabs in a second window.
  2. With the main window focused, click the close button in a tab in the second window.
  3. In File Explorer, observe that .obsidian/workspace.json exists and contains content.
  4. On the Windows taskbar, right-click obsidian and choose “Close all windows”.
  5. In File Explorer, observe that .obsidian/workspace.json now has filesize 0KB and is empty.
  6. Open Obsidian: all previous tabs and windows are closed (the files themselves still exist).

Did you follow the troubleshooting guide? [Y/N]

Y
This occurs with restricted mode enabled, no snippets, default theme. It can’t be tested in the sandbox vault as saving to workspace.json is essential.

Expected result

Opening Obsidian, previous tabs and windows should be loaded.

Actual result

Opening Obsidian, all previous tabs and windows are lost.

Environment

SYSTEM INFO:
Obsidian version: v1.8.10
Installer version: v1.8.10
Operating system: Windows 11 Pro 10.0.22631
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on

RECOMMENDATIONS:
none


Additional information

Also: for perhaps as long as multiple years I have intermittently had a layout partial-wipe problem where all secondary windows would be lost, and only the main window tabs would be restored. Perhaps also a race condition writing-while-closing situation affecting workspace.json.

Vault size: several thousand notes, 350MB including some images and PDFs.

Related posts

SysInternals ProcessMonitor logs

A record of events involving workspace.json:

# Autosaves
# ...
3:37:58.8634480 pm	Obsidian.exe	13984	CreateFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
3:37:58.8634683 pm	Obsidian.exe	13984	QueryBasicInformationFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	CreationTime: 19/10/2022 7:10:01 am, LastAccessTime: 17/06/2025 3:37:58 pm, LastWriteTime: 17/06/2025 3:37:58 pm, ChangeTime: 17/06/2025 3:37:58 pm, FileAttributes: A
3:37:58.8634776 pm	Obsidian.exe	13984	CloseFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	

# Manually closed Obsidian
3:42:29.7179104 pm	Obsidian.exe	13984	CreateFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Overwritten
3:42:29.7406801 pm	Obsidian.exe	13984	CloseFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	

The workspace.json wiping event may have been the second-to-last event: AllocationSize: 0, OpenResult: Overwritten

No other processes touched workspace.json in the preceding 4 minutes.

More complete log for the last two events, adding columns “Command Line” and “Parent PID”:

3:42:29.7179104 pm	Obsidian.exe	13984	CreateFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Overwritten	"C:\Users\user\AppData\Local\Obsidian\Obsidian.exe" --type=renderer --user-data-dir="C:\Users\user\AppData\Roaming\obsidian" --standard-schemes=app --secure-schemes=app --fetch-schemes=app --streaming-schemes=app --code-cache-schemes=app --app-path="C:\Users\user\AppData\Local\Obsidian\resources\app.asar" --no-sandbox --no-zygote --node-integration-in-worker --video-capture-use-gpu-memory-buffer --lang=en-GB --device-scale-factor=1 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1750124456820229 --launch-time-ticks=6994669446 --field-trial-handle=2652,i,7297147118279264881,15565033714741024382,262144 --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess,WinDelaySpellcheckServiceInit,WinRetrieveSuggestionsOnlyOnDemand --variations-seed-version --mojo-platform-channel-handle=2648 /prefetch:1	25064
3:42:29.7406801 pm	Obsidian.exe	13984	CloseFile	C:\Users\user\vault\.obsidian\workspace.json	SUCCESS		"C:\Users\user\AppData\Local\Obsidian\Obsidian.exe" --type=renderer --user-data-dir="C:\Users\user\AppData\Roaming\obsidian" --standard-schemes=app --secure-schemes=app --fetch-schemes=app --streaming-schemes=app --code-cache-schemes=app --app-path="C:\Users\user\AppData\Local\Obsidian\resources\app.asar" --no-sandbox --no-zygote --node-integration-in-worker --video-capture-use-gpu-memory-buffer --lang=en-GB --device-scale-factor=1 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1750124456820229 --launch-time-ticks=6994669446 --field-trial-handle=2652,i,7297147118279264881,15565033714741024382,262144 --enable-features=SharedArrayBuffer --disable-features=SpareRendererForSitePerProcess,WinDelaySpellcheckServiceInit,WinRetrieveSuggestionsOnlyOnDemand --variations-seed-version --mojo-platform-channel-handle=2648 /prefetch:1	25064

Stack for the createFile event:

0	FLTMGR.SYS	FltGetStreamContext + 0x20cb	0xfffff806538b963b	C:\WINDOWS\System32\drivers\FLTMGR.SYS
1	FLTMGR.SYS	FltGetStreamContext + 0x1b51	0xfffff806538b90c1	C:\WINDOWS\System32\drivers\FLTMGR.SYS
2	FLTMGR.SYS	FltRequestFileInfoOnCreateCompletion + 0x4ef	0xfffff806538f1fef	C:\WINDOWS\System32\drivers\FLTMGR.SYS
3	ntoskrnl.exe	IofCallDriver + 0x55	0xfffff806546650d5	C:\WINDOWS\system32\ntoskrnl.exe
4	ntoskrnl.exe	PsReferenceImpersonationToken + 0x1fe3	0xfffff80654abecb3	C:\WINDOWS\system32\ntoskrnl.exe
5	ntoskrnl.exe	ObOpenObjectByNameEx + 0xf21	0xfffff80654aca301	C:\WINDOWS\system32\ntoskrnl.exe
6	ntoskrnl.exe	ObOpenObjectByNameEx + 0x1f2	0xfffff80654ac95d2	C:\WINDOWS\system32\ntoskrnl.exe
7	ntoskrnl.exe	NtCreateFile + 0xba7	0xfffff80654aace47	C:\WINDOWS\system32\ntoskrnl.exe
8	ntoskrnl.exe	NtCreateFile + 0x79	0xfffff80654aac319	C:\WINDOWS\system32\ntoskrnl.exe
9	ntoskrnl.exe	setjmpex + 0x90b5	0xfffff8065482a505	C:\WINDOWS\system32\ntoskrnl.exe
10	ntdll.dll	NtCreateFile + 0x14	0x7ffe3fd50e44	C:\Windows\System32\ntdll.dll
11	KernelBase.dll	CreateFileW + 0x710	0x7ffe3d3fa650	C:\Windows\System32\KernelBase.dll
12	KernelBase.dll	CreateFileW + 0x7c	0x7ffe3d3f9fbc	C:\Windows\System32\KernelBase.dll
13	Obsidian.exe	node::EmitAsyncDestroy + 0xb723	0x7ff6e592e523	C:\Users\user\AppData\Local\Obsidian\Obsidian.exe
14	Obsidian.exe	uv_cancel + 0x24a	0x7ff6e5af683a	C:\Users\user\AppData\Local\Obsidian\Obsidian.exe
15	Obsidian.exe	uv_thread_create_ex + 0x197	0x7ff6e53afa97	C:\Users\user\AppData\Local\Obsidian\Obsidian.exe
16	Obsidian.exe	Cr_z_adler32 + 0x58950a	0x7ff6e792826a	C:\Users\user\AppData\Local\Obsidian\Obsidian.exe
17	kernel32.dll	BaseThreadInitThunk + 0x1d	0x7ffe3eb7259d	C:\Windows\System32\kernel32.dll
18	ntdll.dll	RtlUserThreadStart + 0x28	0x7ffe3fd0af38	C:\Windows\System32\ntdll.dll

Claude 4 Opus may or may not be right but it suggests:

The enhanced trace confirms this is a *bug in Obsidian itself*, not caused by plugins or external software. The smoking gun is clear:

**The Problem**
The CreateFile operation with `OverwriteIf` and `AllocationSize: 0` immediately truncates the file to 0 bytes. Then Obsidian closes the file WITHOUT writing any data. This is happening in a worker thread (based on the stack trace showing `uv_thread_create_ex` and Chromium internals).

**Root Cause Analysis**
Based on the evidence:
1. **Worker thread race condition during shutdown** (90% likelihood)
  * The stack shows this is happening in a background thread
  * The thread is likely being terminated during app shutdown before it can write
  * The `Cr_z_adler32` in the stack suggests compression/decompression operations
2. **Corrupted Electron/Chromium shutdown sequence** (70% likelihood)
  * The renderer process (note the `--type=renderer` in command line) is failing to complete its write

Hopefully that information provides a good start for finding out whether this is a bug or just something affecting me! Many thanks for your help.

Following your steps, I tried a few times with my work vault (~4000 notes) and a copy of the Sandbox on the desktop, but couldn’t manage to zero out the workspace.json file and everything re-opened as expected.

Obsidian v1.9.2, installer 1.8.9, Windows 11.

I haven’t been able to reproduce this either.

If you can, post a screen recording of this happening in the sandbox vault. Thanks

Thank you ariehen and WhiteNoise! It’s helpful to know that (even with all plugins and snippets disabled) it is something about my vault or my system.

My understanding had been the sandbox vault doesn’t save to disk (when opened through the Obsidian command), so it wouldn’t be possible to check this save-to-disk-on-close issue:

However, I’ve now found the sandbox vault repo, so I can work with a copy of it that will save workspace.json.

Next steps

Sounds like the next two steps are for me to see whether I can:

  1. replicate the problem with a copy of the sandbox vault on my device
  2. replicate the problem with my vault on a fresh install of Obsidian on other devices

Clarification of ProcessMonitor logs

Something that makes me think it’s Obsidian (rather than an external program) causing the problem is the Process Monitor event log. Only Obsidian.exe interactions during the time the file got zeroed.

I realised I trimmed the log in my previous post too much - I showed a read operation and the failed final write operation. Below I have included a more complete log that shows a successful autosave write, and the failed final write on close.

The difference between the successful write and failed write:

Successful autosave write pattern (e.g., 3:37:58.8180899):

1. CreateFile (Generic Write, OverwriteIf, AllocationSize: 0)
2. WriteFile (Length: 124,432) ← ACTUAL CONTENT WRITTEN
3. Multiple file attribute checks
4. CloseFile

Failed final write on close pattern (3:42:29.7179104):

1. CreateFile (Generic Write, OverwriteIf, AllocationSize: 0)
2. CloseFile ← NO WriteFile OPERATION!

More complete log

ProcessMonitor log of workspace.json file interactions from before until after the file is zeroed

# 1. while resizing obsidian window - interleaved autosave and refresh operations?
3:37:58.8180899 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Overwritten
3:37:58.8413775 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
3:37:58.8414068 pm	Obsidian.exe	13984	QueryBasicInformationFile	SUCCESS	CreationTime: 19/10/2022 7:10:01 am, LastAccessTime: 17/06/2025 3:37:58 pm, LastWriteTime: 17/06/2025 3:37:58 pm, ChangeTime: 17/06/2025 3:37:58 pm, FileAttributes: A
3:37:58.8414185 pm	Obsidian.exe	13984	CloseFile	SUCCESS	
3:37:58.8421614 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
3:37:58.8421840 pm	Obsidian.exe	13984	QueryBasicInformationFile	SUCCESS	CreationTime: 19/10/2022 7:10:01 am, LastAccessTime: 17/06/2025 3:37:58 pm, LastWriteTime: 17/06/2025 3:37:58 pm, ChangeTime: 17/06/2025 3:37:58 pm, FileAttributes: A
3:37:58.8421941 pm	Obsidian.exe	13984	CloseFile	SUCCESS	
## crucially, this successful write operation has a Length: 124,432:
3:37:58.8429096 pm	Obsidian.exe	13984	WriteFile	SUCCESS	Offset: 0, Length: 124,432, Priority: Normal
3:37:58.8623732 pm	Obsidian.exe	13984	CloseFile	SUCCESS	
3:37:58.8627489 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
3:37:58.8627807 pm	Obsidian.exe	13984	QueryBasicInformationFile	SUCCESS	CreationTime: 19/10/2022 7:10:01 am, LastAccessTime: 17/06/2025 3:37:58 pm, LastWriteTime: 17/06/2025 3:37:58 pm, ChangeTime: 17/06/2025 3:37:58 pm, FileAttributes: A
3:37:58.8627914 pm	Obsidian.exe	13984	CloseFile	SUCCESS	
3:37:58.8634480 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
3:37:58.8634683 pm	Obsidian.exe	13984	QueryBasicInformationFile	SUCCESS	CreationTime: 19/10/2022 7:10:01 am, LastAccessTime: 17/06/2025 3:37:58 pm, LastWriteTime: 17/06/2025 3:37:58 pm, ChangeTime: 17/06/2025 3:37:58 pm, FileAttributes: A
3:37:58.8634776 pm	Obsidian.exe	13984	CloseFile	SUCCESS	

# 2. manual close of Obsidian - this write zeroed the file
3:42:29.7179104 pm	Obsidian.exe	13984	CreateFile	SUCCESS	Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Overwritten
## MISSING any content to write!
3:42:29.7406801 pm	Obsidian.exe	13984	CloseFile	SUCCESS	

The next steps are probably still for me to try to replicate this with different vault / on a different device - because even if it is Obsidian doing this (rather than something external), we don’t know why.

Thanks again.

You can use the sandbox vault. It does reset if you open it in the vault switcher.

I did more or less did the same when I checked – I manually copied-pasted the Sandbox (from ~/Library/Application Support/obsidian/) to my desktop and opened that as a vault.

On Windows, it will be in %APPDATA%\Obsidian\ somewhere.

Alright, I’ve replicated the issue on my computer using the sandbox vault (mostly: loss of all secondary windows, rather than all tabs in all windows).

  • First, I tried it with a local copy of the sandbox repo. This enables workspace.json saving to disk.
  • Second, I also tried it with the Obsidian built-in “Open sandbox vault”, and found workspace.json inC:\Users\%user%\AppData\Roaming\obsidian\Obsidian Sandbox\.obsidian

In both cases, I could see that workspace.json shrunk in size upon closing Obsidian. Not to zero (so slightly different from my main vault problem), but still losing all secondary windows.

  • When I used the local copy of the sandbox repo, reopening Obsidian confirmed that the main window tabs remained, but the secondary window was lost.
  • When I used the built-in “Open sandbox vault”, the sandbox reset upon reopening.

Here are screen recordings for both scenarios:

Local copy of sandbox repo

https://i.imgur.com/zlFdQTZ.mp4

Built-in “Open sandbox vault”

https://i.imgur.com/MFoIsms.mp4