Sandboxie is often described in a single sentence: it runs programs in an isolated environment so that they cannot make permanent changes to the real file system or registry. That sentence is accurate, but it conceals a good deal of engineering. There is no guest operating system, no hypervisor and no second copy of Windows. Instead, Sandboxie persuades ordinary programs, running on your ordinary desktop, that they are writing to your disk and your registry when in fact their changes are being diverted elsewhere. Understanding how Sandboxie works, in mechanical terms, is the best way to judge what it protects against and what it does not. This article follows a sandboxed program from the moment it is launched, through each layer that constrains it, to the limits of the whole design.
The Three Components and Their Roles
Both the Plus and Classic editions share an identical core made of three parts. The interfaces differ, with SandMan in Plus and Sandboxie Control in Classic, but the machinery underneath is the same. Each part operates at a different level of privilege, and the design depends on their division of labour.
| Component | Where it runs | Principal responsibilities |
|---|---|---|
SbieDrv.sys | Kernel mode, as a driver | Creates sandboxed processes with heavily restricted tokens; enforces the rules on system calls redirected to it |
SbieSvc.exe | A Windows service running with high privileges | Performs privileged helper tasks on behalf of sandboxed programs; injects the DLL into them |
SbieDll.dll | Inside each sandboxed process | Virtualises the file system and registry; merges sandbox contents with the real system so the program sees a coherent view |
It helps to think of the driver as the enforcer, the service as the trusted intermediary and the DLL as the illusionist. The driver decides what is permitted. The service carries out the few privileged operations that a heavily restricted program legitimately needs but cannot perform for itself. The DLL, living inside the program, rewrites the program's view of the world so that it continues to function despite the restrictions placed on it.
Restricted tokens: starting with almost nothing
Every Windows process carries a security token, which describes who it is and what it may do. When Sandboxie starts a program in a Standard Isolation box, the driver creates that process with a heavily restricted token, one that grants almost no rights at all. This is the foundation on which everything else rests.
The significance of this choice is easy to underestimate. Hooking functions inside a process can always, in principle, be circumvented by code determined enough to avoid the hooked paths. A restricted token cannot be talked around in the same way, because it is enforced by Windows itself. Even if a program bypasses every piece of Sandboxie's user-mode machinery, it remains bound by the meagre rights of the token it was given.
The cost of restriction
A process with almost no rights would, left to itself, fail at nearly everything: opening files, reading settings, communicating with other components. The rest of the design exists to restore enough capability for programs to work normally while keeping their effects contained. That is the central tension of the model, and the reason the remaining layers are needed.
How Sandboxie Works at the System-Call Boundary
Windows programs ultimately reach the kernel through native system calls, typically via small stub functions in system libraries. Sandboxie redirects selected native syscall stubs so that the calls pass through SbieDrv. The driver then applies the sandbox's rules: it refuses writes outside the sandbox and refuses reads of resources that have been closed.
This arrangement has an important property. A program that issues direct system calls, deliberately avoiding the redirected stubs, does not escape. It simply finds itself operating under the restricted token, with all the limitations that implies. Redirection makes the sandbox usable; the token makes it hold.
Hooks and workarounds above the kernel
Not every Windows facility can be handled by redirecting system calls. For other functions in Windows DLLs, Sandboxie installs hooks and implements workarounds, frequently delegating the privileged part of the work to SbieSvc. The service acts on the program's behalf only where the request is consistent with the box's rules. Some functionality, where no safe workaround exists, is disabled outright, and the program must manage without it.
The Plus edition's Security Hardened box type tightens this boundary further. Among its settings is SysCallLockDown=y, alongside dropping administrator rights and restricting device access. That mode requires a supporter certificate, but it illustrates how the same machinery can be configured to permit less.
Copy-on-Write File Virtualisation
The illusion that a sandboxed program is working on your real disk is produced by copy-on-write. The rule is simple, and SbieDll applies it on every file access:
- If a sandboxed copy of the file already exists, the program uses that copy.
- If no sandboxed copy exists and the program is only reading, it reads the original.
- If the program writes to the file, a copy is created inside the sandbox and the write goes there.
The consequence is that the original is never modified. The program, meanwhile, sees a merged view: its own changes layered on top of the untouched real files. Delete the sandbox contents, and every change vanishes at once, because none of it ever reached the original locations.
Copy-on-write governs writing, not reading. In a Standard box a sandboxed program can still read most of your files, because reading an original is permitted. Privacy Enhanced boxes exist to close precisely that gap, presenting empty folders in place of user data.
Where the copies live on disk
All those redirected copies have to live somewhere. Each box has a root folder, set by FileRootPath, and by default located at C:\Sandbox\<user>\<box>. Inside it, Sandboxie organises redirected content according to where it would otherwise have gone.
C:\Sandbox\<user>\<box>\
drive\C\... files written to locations on drive C
user\current\ the current user's profile
user\all\ all-users profile locations
user\public\ public profile locations
share\server\share\ files written to network shares
RegHive the box's registry hive
RegHive.LOG its transaction logSeparating the user profile from the general drive tree is a deliberate choice. It means a box's contents remain sensible even if the profile lives at an unusual path, and it allows recovery features to find documents and downloads easily. Immediate Recovery watches recovery folders such as Desktop, Documents, Downloads and Favourites, and offers to copy new files out of the box as they are written. Quick Recovery offers the same when you empty a box. In either case, a recovered file is a copy leaving the sandbox, and it should be scanned before use.
Registry Hives and IPC Namespaces
Mounting the registry hive
The registry is handled in a parallel fashion. The RegHive file in the box folder is a registry hive, and while the box is in use it is mounted at HKEY_USERS\Sandbox_<user>_<box>. Writes that a sandboxed program directs at HKEY_LOCAL_MACHINE are redirected into a machine key within that hive; writes directed at HKEY_CURRENT_USER go into a user\current key. As with files, the program sees its changes merged over the real registry, while the real registry remains as it was.
This is why software installed inside a box appears fully installed to programs in the same box but leaves no trace in the real registry. When the box is emptied, the hive goes with it.
Separating IPC objects
Files and the registry are the obvious targets, but Windows programs also communicate through inter-process communication objects: events, mutexes, RPC ports and similar. Sandboxie gives each box its own namespace for these objects. A sandboxed program cannot reach IPC objects outside its box, not even for reading, unless a rule allows it.
This separation has a practical benefit beyond security. Many programs use a named mutex or similar object to ensure only one copy runs. Because the sandboxed copy lives in a different namespace, the same program can run sandboxed and unsandboxed side by side, each believing itself to be the only instance.
Access Rules: Open, Read, Closed, Write and Normal
The default behaviour described above can be adjusted per resource through access rules in the Sandboxie configuration file. Each rule names a path and changes how the sandbox treats it.
| Rule | Effect on the named path |
|---|---|
OpenFilePath | Direct access: the program reads and writes the real location, bypassing virtualisation |
ReadFilePath | Read-only access to the real location |
ClosedFilePath | No access at all |
WriteFilePath | Write-oriented access to the location, as defined by the rule |
NormalFilePath | The ordinary sandboxed treatment, useful to restore default handling for a subset of a path |
Equivalent rules exist for registry keys and IPC objects, with Key and Ipc in place of File in the name. A typical use is to open a single folder so that a sandboxed program's output persists, or to close a sensitive folder entirely:
OpenFilePath=C:\Exports\
ClosedFilePath=C:\Users\me\Private\Open rules deserve caution. Every path opened is a hole in the boundary through which a sandboxed program can make permanent changes. The Security Hardened mode's use of UseRuleSpecificity=y reflects the fact that, once rules overlap, the precise way they are resolved matters a great deal.
Why This Design Differs From a Virtual Machine
A virtual machine, whether Hyper-V, VirtualBox or VMware, runs an entire guest operating system on virtualised hardware. Windows Sandbox is a lightweight version of the same idea: a disposable virtual machine with a clean desktop that is destroyed on close. These approaches isolate by duplication. Everything inside the guest is separate, which gives them the strongest boundary, at the cost of weight and of needing hardware virtualisation.
Sandboxie isolates by interception instead. It runs each program on the host, using the applications you already have installed, and constrains it through tokens, syscall redirection, hooks and virtualised storage. That is why a box starts instantly, why many boxes can run at once, why boxes persist until you empty them, and why Sandboxie works on Windows Home without virtualisation hardware. It is also why its boundary is weaker than a virtual machine's: the sandboxed program shares the host kernel, and any flaw in the enforcing layers sits on the host itself. Researchers handling hostile code commonly run Sandboxie inside a virtual machine, combining convenience with a stronger outer wall.
The Limits of the Model
Knowing how Sandboxie works also clarifies where it stops working. The limits are not defects so much as consequences of the design.
- It is not antivirus. The sandbox contains behaviour; it does not identify malicious software.
- Reading is broadly allowed in Standard boxes. Copy-on-write protects originals from change, not from being read. Privacy Enhanced mode addresses this.
- Recovered files leave the box. Once copied out, a file has no protection beyond what the real system provides.
- App Compartment is not a boundary. It disables token-based isolation while keeping file and registry virtualisation, trading security for compatibility, and should never hold untrusted programs.
- Kernel dependence. Because the driver works so close to Windows internals, Windows updates and Insider builds can temporarily break it.
- Some software cannot be boxed. Programs that install drivers, and games protected by anti-cheat systems, often refuse to run sandboxed.
- The enforcing code can contain flaws. Release 1.17.3 fixed a local denial-of-service issue, CVE-2026-32603, and a bypass of EditAdminOnly protection; 1.18.8 fixed an out-of-bounds read in the GUI proxy; and the 1.19.0 pre-release applies broad hardening after an AI-assisted audit. Keeping current matters.
Frequently Asked Questions
Does Sandboxie use virtualisation hardware?
No. It isolates programs through restricted tokens, system-call redirection, hooks and file and registry virtualisation on the host, so no hypervisor or hardware virtualisation is required.
Can a program escape by making direct system calls?
Direct system calls avoid the redirected stubs, but the program still runs under the heavily restricted token created by the driver, so it remains confined by those minimal rights.
Where are sandboxed changes stored?
In the box's root folder, by default under C:\Sandbox\<user>\<box>, split into drive, user and share folders, with registry changes in the RegHive file.
Why can the same program run inside and outside a box at once?
Each box has its own namespace for IPC objects such as mutexes and events, so a single-instance check in the sandboxed copy does not see the unsandboxed copy.
Is Sandboxie as safe as a virtual machine?
No. A virtual machine runs a separate guest operating system and offers a stronger boundary. Sandboxie shares the host kernel, which makes it faster and lighter but less isolated.
What does an OpenFilePath rule do?
It gives sandboxed programs direct access to the real location, so changes there are permanent. Use it sparingly, since every opened path weakens the sandbox.
Conclusion
Sandboxie achieves isolation without a second operating system by layering several mechanisms, each covering the weaknesses of the others. The driver starts programs with a token that grants almost nothing and enforces rules on redirected system calls. The service performs the privileged tasks that a confined program genuinely needs. The injected DLL virtualises files and the registry through copy-on-write, merging sandboxed changes over an untouched original, while separate IPC namespaces keep boxes from interfering with the rest of the desktop. Access rules then let you widen or narrow that boundary path by path.
Seen this way, the model's strengths and weaknesses become predictable rather than surprising. It is fast, light and works with the software you already have, because it runs on the host. It is weaker than a virtual machine for the same reason, and it protects originals from change rather than from being read unless you choose a stricter box type. Anyone who understands how Sandboxie works in these terms can configure it sensibly: generous where convenience matters, strict where trust is low, and paired with a virtual machine and an antivirus product where the stakes are highest.