DeepSeek Harness Windows install_dir_access ACL crash fix

7-Zip exit code 2, event log Exception 0x80000003, and double-clicking that does nothing are the same chain on Windows: the install directory DACL contains an AppContainer package SID without a matching ALL APPLICATION PACKAGES entry, so Chromium's install_dir_access check kills the main process outright. After checking the source, the community confirmed this is an Electron/Chromium check, not the DSH sandbox itself; the repair script ships with the package, but neither reinstalling nor clearing AppData touches it (#10863, #10983). The order below is: collect evidence, run three single-variable comparisons, and only then edit the ACL.

DeepSeek Harness: Experiment 1: add --enable-logging and catch the verdict

--enable-logging is the only evidence-gathering step that changes no system state: it writes one extra stderr stream and tells you whether the crash is really install_dir_access.

1. Quit DSH completely, including the tray icon and any leftover process in Task Manager.
2. Launch from the command line: "<install-dir>\DeepSeek Harness.exe" --enable-logging.
3. Watch stderr for the install_dir_access line. A hit looks like this:

FATAL:electron\shell\browser\win\install_dir_access.cc:52]
Sandboxed processes cannot read D:\deepseekherness:
its ACL has an entry for an AppContainer package SID
but none for ALL APPLICATION PACKAGES...

4. Also check Event Viewer → Windows Logs → Application for Event 1000. The shape the community recorded is Exception 0x80000003, with the exe itself as the faulting module.
5. If stderr contains no install_dir_access, this article does not apply; stop and change direction.

Keep one premise in mind: "packages cannot read" refers to the sandboxed renderer being unable to read install-tree files such as icudtl.dat, not to a problem with your project directory.

DSH plugin: Experiment 2: treat --no-sandbox as a signal, not a solution

Starting with --no-sandbox proves the problem sits in Chromium's install-directory access check; it is a triage signal, not a fix.

1. Launch once with --no-sandbox and confirm the window appears.
2. Then try --disable-gpu and --disable-gpu-sandbox; the community found both ineffective — which is itself useful, because it rules out GPU issues and pins the sandbox's directory access check.
3. After repairing the ACL, remove --no-sandbox and verify again; do not leave it in the shortcut.

DeepSeek Harness: Experiment 3: install to a writable path to separate "installer" from "directory"

When installation itself fails, reinstalling to a different path is the cleanest single-variable test: if it installs, the permissions on the target chain are at fault; if it still fails, suspect the installer or the temp directory.

1. Try installing into a new drive or a newly created directory, such as D:\DSH\, and make sure you created it manually as an ordinary directory.
2. If the original path was an inherited location like %LOCALAPPDATA%\Programs, switching is especially worthwhile — the community saw install logs with Cannot create folder : access denied pointing at locales and resources, with 7-Zip stopping on the first extraction step.
3. If both paths fail, suspect the installer; if only the original fails, inspect the ACL on that chain. Also point TEMP at an empty directory on another drive so the temp folder is not tagged at Low integrity.

DSH Plugin: Experiment 4: compare icacls output between two machines

Put the icacls output from the failing and working machines side by side and the difference is obvious: the failing machine's parent directory has extra S-1-15-3-1024-* and package SID S-1-15-2-<hash> entries, but no ALL APPLICATION PACKAGES entry at all.

1. On the failing machine, run icacls "D:\Application" and save the output to a file.
2. Run the same command on the working machine and save that too.
3. Align them line by line and focus on three entry types: S-1-15-3-* (orphan AppContainer SIDs), S-1-15-2-<hash> (specific package SIDs), and S-1-15-2-1 / S-1-15-2-2 (well-known groups).
4. The failing machine typically has the first two and lacks the last two; a working machine usually has no AppContainer entries at all, because its install directory inherited a normal DACL and never triggers this check.

DeepSeek Harness: Repair: run the bundled script first, then consider manual icacls

The official script is the first choice because it removes foreign package ACEs in ancestor-first order and fills in WRITE_DAC/WRITE_OWNER along the same chain; every change is backed up, read back, and rolled back with a printed command.

1. Open a non-restricted PowerShell window (not a shell inside the DSH sandbox).
2. Work out which layer actually carries the package SID: if icacls D:\ already shows it, -Path should be D:\, not the install directory.
3. Run:

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' `
  -Path '<install-dir-or-volume-root>' `
  -AllowRoot '<same-or-higher-dir>' `
  -Out '<recovery-dir>'

4. Read the output: the script removes explicit S-1-15-2-* allow ACEs (except the well-known groups ending in 1 or 2) and adds the missing permissions.
5. If it refuses to proceed (reparse point, managed app directory), prepare the rollback command it prints, export the ACL with icacls <dir> /save, and edit manually.

The minimal manual repair is to add the missing entry, granting both well-known groups:

icacls "<install-dir>" /grant "*S-1-15-2-1:(OI)(CI)(RX)" "*S-1-15-2-2:(OI)(CI)(RX)" /T

The community confirmed the script exists on the rc.3 tag (1f81c047) and master (22ddee3); after running this command, the reporter started normally with no launch flags at all.

DSH plugin: Why reinstalling is guaranteed to fail

ACLs belong to directories, not program files; an in-place update inherits whatever ACL it finds, and the uninstaller cleans app data rather than parent-directory ACLs, so a reinstall just lays the same broken environment down again.

1. First rule out "the files were not fully written": that is a different problem (an empty runtime directory) whose symptom is ENOENT, not 0x80000003.
2. Do not test by deleting app data under %LOCALAPPDATA%; the community was explicit that the uninstaller only touches that part.
3. After fixing the ACL, reboot and verify again with --enable-logging; you are done only when install_dir_access no longer appears in stderr.
4. Record which layer you changed; if it comes back after an update, check first whether the updater re-inherited the bad ACL.

Cautions

Export the ACL before touching it, and expect the updater to inherit it again.

1. Do not run a broad icacls /T on a volume root. Export with icacls /save first so you can roll back before changing anything.
2. S-1-15-2-1 and S-1-15-2-2 are two different well-known groups; in the community case both had to be added before recovery.
3. A script refusal is not a script defect. It deliberately refuses reparse points and managed app directories; handle those manually as instructed.
4. Do not put --no-sandbox into your daily shortcut. It disables the entire renderer sandbox.
5. Check again after upgrading. The updater currently does not grant the AAP ACE, so a bad ACL travels along with the files.

If your log has no install_dir_access at all, this crash is not the ACL one — go back to the 0xC0000142 article and re-triage by host shape.See DSH plugin: Windows subprocess fails with 0xC0000142 for the related case.