Sandboxie asks a great deal of Windows. It intercepts system calls, redirects file and registry writes, gives each box its own namespace for inter-process communication and starts every boxed program with a token that grants almost no rights. That it works as smoothly as it does for most software is a credit to the design, but it also means that when something goes wrong, the cause can sit in any of several layers: the installer, the kernel driver, the configuration, the program itself, or a recent change to Windows.
This guide is organised by symptom. Rather than listing every setting, it starts from what you are likely to see, a failed update, a program that will not open, a browser that crashes, a window that consumes processor time, a file that seems to have vanished, and works back towards the cause. The aim of good Sandboxie troubleshooting is not to try fixes at random but to narrow the problem down until the right fix becomes obvious.
When an update fails or the version looks wrong
A surprising number of problems begin at installation. Because Sandboxie installs a kernel driver and a service, an update has to stop running components, replace them and start them again. If something holds on to the old files, the update can stop half-way, leaving a mismatch between the driver and the user interface.
The project's own advice, repeated in every release note, is simple: if an update fails, uninstall the previous version while keeping the configuration file, then install the new build. The uninstaller offers to preserve your settings, and accepting that offer means your boxes and rules survive the reinstall. Installation requires administrator rights in any case, since the driver cannot be loaded otherwise.
Twin version numbers
Confusion over versions is common enough to deserve its own note. Plus and Classic share a core and are released together, but they carry different numbers. Plus 1.18.8 and Classic 5.73.8 are the same release; so are the 1.19.0 and 5.74.0 pre-releases. Download portals sometimes show only one of the pair, so a listing for "5.73.8" may lead someone to believe they are behind when they are not, or to install Classic when they meant to install Plus.
Stable releases, pre-releases and signing
At the time of writing, 1.18.8 is the current stable release, while 1.19.0 is a pre-release containing broad hardening work that followed an AI-assisted audit of the codebase. The project asks users to test the pre-release and to fall back to 1.18.8 if they hit regressions. Bear in mind that pre-releases are sometimes unsigned, and unsigned builds are more likely to be flagged by antivirus software. If a fresh install is blocked or quarantined, check whether you have installed a pre-release before assuming anything more sinister.
The download offered on this site is the GitHub archive of the project's master branch, which contains source code rather than an installer. Compiled installers for x64 and ARM64 are published on the project's GitHub releases page, together with SHA-256 checksums you can use to verify them.
Sandboxie troubleshooting when programs will not start
A program that runs normally outside Sandboxie but fails inside it is the most frequent complaint, and the most varied. The first rule is to look before you change anything.
Read the message log
SandMan keeps a message log, and when Sandboxie blocks something or encounters an error, it records a message identified by an SBIE code. These codes are the single most useful clue you have. They tell you whether the program was denied access to a resource, whether a component failed to load, or whether Sandboxie has recognised a known compatibility issue and is suggesting a remedy. Note the exact code and the text that accompanies it before you start adjusting settings.
Check the templates
Sandboxie ships with compatibility templates for many well-known applications, which open or adjust the specific resources those applications need. If the program you are running has a template, make sure it is enabled for the box. If it does not, the message log will usually point to the resource it is being denied, which tells you where an access rule such as OpenFilePath or OpenKeyPath might help. Open as little as possible: every rule that grants direct access is a small hole in the box.
Administrator rights
Some programs insist on elevation, and a box configured with DropAdminRights=y, which Security Hardened boxes use, will strip those rights regardless of how the program was launched. If a program complains about permissions, check whether the box drops administrative rights. Since the 1.17.6 release, Sandboxie Plus shows "(Administrator)" in a window's title when the boxed program is running elevated, which makes it easy to confirm what you are dealing with.
Test in an App Compartment box
A useful diagnostic, if you hold a certificate, is to try the program in an App Compartment box. This type disables the token-based security isolation while keeping file and registry virtualisation. If the program runs there but not in a Standard box, the restricted token is the obstacle, and you have learned something specific. Treat this purely as a test for trusted software: App Compartment is not a security boundary.
Programs that simply cannot be sandboxed
Some software will not run in any box. Games protected by anti-cheat systems and programs that install drivers are the usual examples. If a program fails in every configuration and the log shows it attempting something a sandbox cannot permit, the honest answer is that it needs a virtual machine or no isolation at all.
Electron applications and SBIE2189
Many desktop applications are built on Electron, which embeds the Chromium engine. Chromium-based programs have their own internal sandbox and need particular handling. From the 1.17.4 release, Sandboxie detects Electron applications automatically and applies that handling. If detection misfires and causes a problem, it can be turned off with UseElectronDetection=n. The same release changed message SBIE2189 so that it suggests a SpecialImage entry naming the program as Chromium-like:
[DefaultBox]
SpecialImage=chrome,program.exe
# or, to switch off automatic detection:
UseElectronDetection=nReplace program.exe with the actual executable name. If an Electron application crashes inside an App Compartment box, note that 1.18.5 fixed crashes of exactly that kind, so updating may be the whole solution.
Browser problems and the 1.18.x fixes
Browsers are the programs most people sandbox, and they change quickly, so they generate a steady stream of compatibility work. Before applying workarounds, check that you are running a current release, because several recent versions addressed browser problems directly.
- The 1.18.0 release made profile sharing reliable for Chromium browsers such as Chrome, Edge and Brave, and added support for the Chromium elevation service and DPAPI. Problems with saved passwords or profiles in sandboxed Chromium browsers are worth retesting after this release.
- The 1.18.3 release restored compatibility with Firefox 154 in Standard Isolation boxes.
- The 1.18.5 release fixed crashes of Chromium and Electron programs in App Compartment boxes.
- The 1.18.8 release fixed Firefox video playback on streaming sites and improved AppContainer handling.
If a browser still misbehaves on a current release, the message log is again the place to start. A browser that worked last week and fails today after an automatic browser update has very likely changed something the sandbox must account for; reporting it promptly, with the browser version, helps the project respond.
When Windows updates break the driver
Sandboxie's driver works closely with the Windows kernel, so changes to Windows can occasionally break it. Major feature updates and, in particular, Windows Insider builds are the usual culprits. The symptom is often that nothing sandboxed starts at all, or that the service reports it cannot communicate with the driver.
In this area, Sandboxie troubleshooting is mostly a matter of patience, because the fix is usually a Sandboxie update rather than a configuration change. The 1.18.2 release, for example, included compatibility work for Windows Insider builds. If you run Insider builds, expect to be ahead of the software occasionally, and check the project's releases and issue tracker before spending time on local fixes. If you rely on Sandboxie daily, it is reasonable to delay Windows feature updates briefly until compatibility has been confirmed.
On the platform side, note that Sandboxie targets 64-bit Windows 10 and Windows 11 on x64 and ARM64. There have been no 32-bit builds since the 1.16 series, and Windows 7 is treated as legacy: support was announced as dropped in 1.16.1 and later restored by compatibility patches in 1.16.3, but it is not a priority platform.
High CPU from DWM and display oddities
DWM high CPU and custom title bars
Some users noticed the Desktop Window Manager consuming unusual amounts of processor time while sandboxed programs with custom title bars were open. This was fixed in 1.17.6. For any remaining cases, 1.17.9 added a DisableCustomTitleOpt option that switches off the relevant optimisation. If you see DWM busy only while a particular sandboxed program is running, update first and then try the option for the affected box.
Display aliases and box names
Recent releases have given you more freedom over how boxes appear. 1.18.1 introduced GUID box names, and 1.18.2 added display aliases through BoxAliasDisplayMode. These are welcome, but they can confuse anyone troubleshooting from memory: the name shown in SandMan may not be the name used in the configuration file or in the sandbox folder on disk. When following instructions that refer to a box by name, or when searching for a box's files, check which name the box actually carries internally. The same release added a tray search, along with border options such as BorderInsideMaximized=y, which can help you identify which box a window belongs to.
Configuration mistakes
A misspelt setting or a misplaced section is an easy way to create mysterious behaviour. The 1.18.1 release added validation and auto-completion to the configuration editor, and 1.18.4 overhauled the auto-completion. If you edit settings by hand, use the built-in editor rather than an external text editor, and let it flag what it does not recognise. After editing, Start.exe /reload asks Sandboxie to reload the configuration.
Recovery confusion: where did my files go?
The single most common "bug" report is not a bug. A user downloads a file in a sandboxed browser, closes the browser, and cannot find the file in their Downloads folder. That is the sandbox doing its job: the download was written inside the box, not to the real disk.
Sandboxie offers several ways to bring files out. Immediate Recovery prompts you when a program writes to one of the recovery folders, such as Desktop, Documents, Downloads or Favourites. Quick Recovery offers recoverable files when you delete a box's contents. You can also browse a box's files directly in SandMan. The RecoverFolder setting controls which folders count for recovery, and since 1.18.0 it accepts wildcards, as does AutoRecoverIgnore.
If you need to find a file manually, it helps to know the layout. The default root is C:\Sandbox\<user>\<box>, and within it, files written to the C: drive appear under drive\C, while files written to your profile appear under user\current. The box's registry lives in a hive file called RegHive. Remember that recovered files are copies leaving the box, so scan them before you open them.
If a file disappeared entirely, check whether the box is set to delete its contents automatically, and whether you emptied it without recovering. Snapshots, if you took one, may hold an earlier state.
How to write a useful bug report
Sandboxie is maintained openly on GitHub, where the project carries hundreds of open issues. A report that the developer can act on quickly is far more likely to be fixed than one that requires a long exchange of questions. Good Sandboxie troubleshooting therefore ends, when the problem is genuinely in the software, with a clear report.
- Versions. Give the edition and version (Plus or Classic, and the exact number), the Windows version and build, and whether the system is x64 or ARM64. Mention if you are on a pre-release or an Insider build.
- The affected program. Name it and give its version. For browsers, the version matters a great deal.
- The box type. State whether the problem occurs in a Standard, Security Hardened, Privacy Enhanced or App Compartment box, and whether it happens in a freshly created box with default settings.
- Steps to reproduce. Describe the shortest sequence that reliably triggers the fault, in plain prose.
- The SBIE messages. Copy the relevant entries from the message log exactly.
- Crash data. Since 1.18.0, Sandboxie has a new crash reporter; include what it produces if a component crashed.
- Relevant configuration. Include the section for the affected box, with any personal paths removed.
- What you have tried. Mention any templates, rules or options you tested, and whether the problem appeared after a specific update.
Before filing, search the existing issues. Someone may already have reported the same fault, and adding a confirmation with your details to an existing report is often more useful than opening a new one.
Frequently Asked Questions
Will uninstalling Sandboxie delete my boxes and settings?
Not if you choose to keep the configuration file when the uninstaller asks. That is the recommended route when an update fails: uninstall while keeping the configuration, then install the new build.
What does an SBIE code mean?
SBIE codes identify messages that Sandboxie records in its message log. They indicate what was blocked or what failed, and some, such as SBIE2189, suggest a specific remedy. Always note the code before changing settings.
Why did my antivirus flag the installer?
Stable releases are digitally signed, but pre-releases are sometimes unsigned, and unsigned builds are more likely to be flagged. Verify the download against the SHA-256 checksum published with the release.
Should I install the 1.19.0 pre-release to fix a problem?
Only if you are happy to test. It contains broad hardening work, and the project asks users who meet regressions to return to 1.18.8, the current stable release.
Sandboxed programs stopped working after a Windows update. What now?
Windows updates and Insider builds can temporarily break the driver. Check for a newer Sandboxie release and look at the project's issue tracker for reports matching your Windows build.
My downloaded file is missing. Is it lost?
Usually not. It is most likely inside the box. Browse the box in SandMan or use recovery to copy it out, unless the box was emptied or deleted automatically.
Conclusion
Most Sandboxie problems fall into a handful of patterns, and in Sandboxie troubleshooting recognising the pattern is half the work. Installation faults usually yield to a clean reinstall that keeps the configuration file. Programs that refuse to start almost always leave an SBIE message explaining why, and templates, careful access rules, a check on administrative rights or a test in an App Compartment box will usually reveal the cause. Browser and Electron difficulties have been the focus of much recent work, so updating is often the quickest remedy, while driver failures after Windows updates generally need a new release rather than local fiddling.
The remaining cases are frequently misunderstandings rather than faults: a file sitting safely in a box, a display alias hiding a box's real name, or a setting typed slightly wrong. Work methodically, change one thing at a time, and keep notes of what you tried. If the problem survives all of that, you will have exactly the information a good bug report needs, and the project will be well placed to fix it.