Resource Access Monitor exclusions?

[btm]

I recently revamped my sandboxie.ini and tried adding a few new reg paths to be blocked. With one specific key blocked I found that Origin seemed to think it couldn't connect through the internet even though my firewall showed that connectivity was fine and there were connections. The change that ended up being the culprit was ClosedKeyPath=HKEY_CURRENT_USER\SOFTWARE\Policies\ but the resource access monitor never showed any attempts to access this area (in fact it never showed any registry areas being denied/blocked with an X) so I was only able to isolate it through trial and error. After setting it to read only (as a test) it got further along and finally showed another path that was also being blocked. After that I decided to run a test and added some key blocks I knew should cause issues and resource access monitor did show those as blocked from the start. Which leads to my exclusion question.

Are there certain paths/registry entries that are ignored, excluded or otherwise not shown in the resource access window?

If there are certain areas that are explicitly not shown, any chance we could get a list? Having this information may help troubleshoot other programs when they are not shown accessing locations this way through resource access monitor. If there aren't exclusions, it looks like there's a bug someplace...

Other misc possibly relevant info:
Windows 7 x64
Sandboxie 5.05.3 beta
Origin was launched from an admin account using runas to run under a limited account
Drop Rights enabled

[Curt@invincea]

There are no paths/keys ignored by the AM. A while back, I too suspected some blocks were not being reported. So I ran it under the debugger. In every case where I suspected something was not being logged, it was either being blocked by Windows or was never reached for other reasons.

ProcMon is useful for finding these situations. Also, the old Sandboxie Trace still works. You may prefer that format better. But, if you allow ('a') something like KeyTrace you will get a lot of output.

[Syrinx]

You ran 'it' under a debugger. Would that be the program in question or did that include the SBIE modules? [Kind of confused how you could tell where the fault lay if 'it' was the program you debugged and not SBIE...] but that's because what you said could be taken a few ways...(tho I'm inclined to think you knew what you were doing) Is there a way I could get permission to run the SBIE modules through a debugger for my own tests on this matter? [I'll admit my efforts wouldn't likely amount to much.]

I will resort to procmon or the trace as you suggested if the answer is no but it's not as likely to be very productive. Those logs are a horror show even with filters sometimes (in procmon anywho; not so sure about the sbie trace yet - haven't tried that)!

Either way I think it's nice to see I wasn't the only one to find something odd / off w the way it reported.

[Curt@invincea]

SbieDrv.sys is where the resources are blocked. I stepped through the driver code in the kernel debugger. That won't be easy to do without the source code.

We routinely go through 1GB PML files. Sometimes as big as 2GB. It can take hours or days to go through them to find a problem.