Rhinoceros3d crashes at certain points; SBIE2101

[chytheche7]

Describe the problem
When invoking certain functions within the 3d modeling application Rhinoceros3d ("Rhino"), the program crashes abruptly, with Sandboxie giving the Message:
WerFault.exe (5552): SBIE2101 Object name not found: Unnamed object, error OpenProcess (C0000022) access=001FFFFF initialized=1

As an example I describe the crash as it happens when trying to "Save layer states" within Rhino. Other functions that cause this sort of crash are: Saving a "Named View", saving a "Snapshot" of the model's current configuration, applying "Box Edit". There are probably many other functions causing this crash. These are a few I identified in a short time.

To Reproduce

1. You enable the "Layer States" tab within the toolbar to the right by pressing the gearwheel symbol and selecting "Layer States" from the dropdown menu:
   
2. You navigate to the tab "Layer States":
   
3. The crash happens when you click the "save" icon. It happens instantaneously and no further changes within Rhino are visible.
   

Expected behavior
A new item should appear in the table below, starting off with name editing active and the default name being highlighted.

System details and installed software
Clean Windows 10 guest VM on VirtualBox 6.1.30 r148432 (Qt5.6.2)
Windows 10 Education
10.0.19043 Build 19043
Intel Core i5-8265U (8th generation)

Installed Software: Sandboxie Plus x64 1.0.3
Rhinoceros 3d 7.13.21348.13001

If you had a compatibility issue or a crash
Prerequisite: Install Rhino 7.13.21348.13001 directly onto the system (meaning not sandboxed).

1. Download the installer: https://files.mcneel.com/dujour/exe/20211214/rhino_en-us_7.13.21348.13001.exe (trial installer).
2. Within the installer, change the license method to "This computer":
   
   
3. Enter the license key RH70-RQ00-LG04-9H0U-8HW4-109Q (anonymous trial license); Press "Install now":
   
4. On program start (sandboxed), click away the request for entering an email address:
   
5. A popup should appear. Press "Ask me later":
   

Sandboxie traces and dmp file
Sandboxie log with basic logging options: basic log hosted on gist

sandboxie.ini basic logging

IpcTrace=ad
PipeTrace=ad
GuiTrace=ad

Sandboxie log with "complete" logging options: extended log file hosted on github ~40MB

sandboxie.ini "complete" logging

FileTrace=ad
KeyTrace=ad
PipeTrace=ad
IpcTrace=ad
GuiTrace=ad
ClsidTrace=ad
NetFwTrace=ad
LogAPI=ad

Dmp file as created by Rhino: dmp file hosted on github

Guide on reading Rhino dmp

    Open Visual Studio
        From the Tools menu, click Options
        Select the Debugging > Symbols tab
        In the Symbol file (.pdb) locations box, add:
            http://s3.symbols.rhino3d.com/symbols/dujour
        Optionally add these symbol servers if you need symbols for OpenGL driver related crashes:
            https://download.amd.com/dir/bin_2018
            https://download.amd.com/dir/bin
            https://driver-symbols.nvidia.com

Additional context

1. The application is installed outside the Sandbox directly onto the system in order to avoid potential further complications with dotnet and Visual C++ redistributables.

2. After experiencing the crash on the host machine, I switched to a VM guest OS for the purpose of trying different Sandboxie settings and combinations thereof. The crash happens just the same in both setups.

3. The only Sandboxie configuration I found which prevented the crash from happening is the following with minimal isolation, which, to my understanding, is similar to not running sandboxed at all:

sandboxie.ini minimal isolation

BoxNameTitle=-  
NoAddProcessToJob=y  
NoSandboxieDesktop=y  
OriginalToken=y  
NoSysCallHooks=y  
OpenIpcPath=*  
OpenWinClass=*

4. Also, the "Box Type" presets recently introduced to Sandboxie ("Application compartment" and so forth) could not prevent this crash.

Sandboxie configuration
The Sandboxie configuration used is the default one.

sandboxie.ini

[GlobalSettings]
FileRootPath=\??\%SystemDrive%\Sandbox\%USER%\%SANDBOX%
SeparateUserFolders=y
KeyRootPath=\REGISTRY\USER\Sandbox_%USER%_%SANDBOX%
IpcRootPath=\Sandbox\%USER%\%SANDBOX%\Session_%SESSION%
NetworkEnableWFP=n
EnableObjectFiltering=n
EnableWin32kHooks=n
EditAdminOnly=n
ForceDisableAdminOnly=n
ForgetPassword=n
Template=WindowsRasMan
Template=WindowsLive
Template=OfficeLicensing

[UserSettings_0C9801F1]
SbieCtrl_AutoStartAgent=SandMan.exe
SbieCtrl_EnableAutoStart=y

[DefaultBox]
Enabled=y
AutoRecover=n
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00FFFF,ttl
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=Chrome_Phishing_DirectAccess
Template=Firefox_Phishing_DirectAccess
Template=AutoRecoverIgnore
ConfigLevel=9

PS
Edit 21-12-23: Changed filehost and access links for larger (~40MB) log files.

[isaak654]

Sandboxie log with "complete" logging options: https://we.tl/t-Lt8RLtAs6I (too large for gist)
sandboxie.ini "complete" logging

Dmp file as created by Rhino: https://we.tl/t-G2px1JYmMi

I would upload them into another file hosting service, because these links are set to expire in 6 days.
The developer can't assure you that he will take a look at them before expiration.

[isaak654]

Sandboxie log with "complete" logging options: extended log file hosted on github ~40MB
sandboxie.ini "complete" logging

Dmp file as created by Rhino: dmp file hosted on github

The new links you uploaded return "Page not found" errors when I try to open them...

[DavidXanatos]

I have downloaded the dump and teh log file

[DavidXanatos]

I think i found the issue it will be fixed in the next build 1.0.5
thank you very much for the great and detailed bug report.

[chytheche7]

Great!

Thank your isaak654 for checking the links again. I had the repo at the target set to "private". It should be fixed now.
Thank you, davidxanatos and everyone involved, very much for your magnificent work on sandboxie plus. Writing the issue report with some thoroughness was the least I could do - I'm glad it was satisfactory. Keep it up!