SBIE1241

Message: SBIE1241 Cannot mount registry hive: [xxxxxxxx / yy]

Explanation:

When a sandboxed program starts, Sandboxie may need to prepare the sandboxed registry for that sandbox. The registry hive file, RegHive, resides beneath the resolved sandbox file root (see FileRootPath for its configuration and fallback behavior). It is mounted at the Registry destination determined by KeyRootPath. Existing mounted hives can be shared and reused by subsequent sandboxed processes; a new process does not necessarily load the hive again.

SBIE1241 reports a failure during hive initialization, mount-association verification, or related security handling. It does not necessarily mean the hive was never loaded. Hive mounting is separate from the logical Registry view described in Registry Virtualization.¹

In the message, xxxxxxxx is a hexadecimal NTSTATUS value and yy is a hexadecimal diagnostic stage. Displayed 11 means 0x11, not decimal 11. Leading zeros are formatting padding. Interpret the two fields together: NTSTATUS is not a decimal Win32 error and is not automatically equivalent to GetLastError(). Stage numbers identify failure points, not chronological steps.²

These diagnostics originate in the shared driver used by Sandboxie Classic and Sandboxie Plus. The Popup Message Log link above describes the Classic interface; Sandboxie Plus's SandMan presents the same diagnostic family through its message and notification handling.

Diagnostic stages

Stage	Meaning
`0x11`	An existing mount association uses the same Registry destination but a different hive-file path, and still has active references. Reports `STATUS_CANNOT_LOAD_REGISTRY_FILE` (`C0000218`).
`0x22`	The ordinary native hive-loading operation, `ZwLoadKey`, failed. Its returned NTSTATUS is preserved.
`0x23`	The alternate system-thread mounting workflow failed. It can be selected for certain app-package-associated processes after a destination-open failure. Failure can occur before or during loading, or afterward while opening or securing the mounted key.
`0x33`	The Registry destination already exists, but verifying its hive association failed. This includes opening or querying the system hivelist, allocating query storage, or detecting a different backing hive-file path. The mismatch reports `STATUS_OBJECT_NAME_COLLISION`; other inspection failures retain their own status.
`0x41`	Opening the process token failed before ordinary hive loading. The native NTSTATUS is preserved.
`0x42`	Retrieving the original token default discretionary access-control list (DACL) failed. Reports generic `STATUS_UNSUCCESSFUL` (`C0000001`), not necessarily the underlying query error.
`0x43`	Applying the temporary token default DACL failed. The native NTSTATUS is preserved; ordinary hive loading has not yet been attempted.
`0x44`	Restoring the original token default DACL failed after the native load attempt. The restoration status is preserved, even if loading succeeded.

Stages 0x23 and 0x44 can occur after successful native loading. For 0x44 following load success, a service notification has already been attempted, but this does not confirm delivery or successful service processing. Do not assume that failed initialization rolled back a successful load.¹

Not every hive-initialization failure emits SBIE1241. Earlier path or storage preparation, memory allocation, or mount-record and Registry-root length checks can fail separately. A failed hive mount during process initialization can also produce SBIE1231 with initialization subcode A3; this is separate from the SBIE1241 stage.³

Troubleshooting

Save the complete message, including the full NTSTATUS and stage, the affected sandbox name, application/process context, and nearby Sandboxie messages. The log message does not always identify the initiating application or sandbox directly.

For stages 0x11 and 0x33, check the effective KeyRootPath and FileRootPath, recent changes to either path, and whether other processes still use the affected box or mount association. Check for overlapping destinations between boxes. An association conflict involves one Registry destination and a different hive-file path, not necessarily invalid setting syntax.
For stages 0x22 and 0x23, interpret the NTSTATUS in the actual loading and storage context. Corrupt or invalid hive data and a full drive remain possible causes, but path/accessibility problems, unavailable storage, and other native failures are also possible. Consider image-backed or RAM-backed storage prerequisites when applicable.
For stages 0x41-0x44, preserve related token or security diagnostics. SBIE1222 may provide additional token-query context; SBIE1231 concerns process initialization, while SBIE2208 concerns hive unloading. These are separate diagnostics, not interchangeable errors.

Stopping affected processes can help when investigating shared mount state, but restarting one application does not necessarily clear an active association. Configuration reload does not guarantee immediate remounting of an active hive.

Do not delete, rename, or reset RegHive as a default fix. Before any operation that could modify or remove sandbox data, arrange appropriate backup and preservation measures. Avoid blindly changing Registry ACLs, taking ownership, disabling security restrictions, or treating reinstallation as a universal remedy.