Hi,
Ah yes we actually uninstalled the scanner, and the notifications went away.
We added it again and they came back.
I am looking into disabling powershell in a Box registry key but have not had any luck with that yet. I need to pin down the exact name that powershell uses.
Here is what I have found from Box support but no luck seeing it work yet.
When we see this in the Streem logs through Box Drive, it indicates there's some program being used to traverse the user's content through Box, as mentioned before, but in this case, powershell.exe itself is not the individual program, so we can't be sure what the individual program is that needs to be added to the "BannedProcessNames" registry. What we can recommend, to be sure what's doing this, please use Process Explorer to help identify and confirm whether it is in fact Tenable or not, as this should also give you the full name to use in the process to add to the "BannedProcessName" registry key section. This could even help provide the full name of Tenable, and whether it's Tenable.IO (as we've seen for other customers encountering this), or something else. It could also provide a whole different program at fault, for you to add with this.
Please note however, if you would instead want information on banning powershell.exe instead, this decision would need to be made by your IT Team, and any more details surrounding why these processes are behaving in this way would be better directed at Microsoft Support as the issue stems from their programs/processes traversing your user's Box content.
I think we actually do use Nessus too, so that would make sense.
We ended up having to (for the few affected users) exclude Powershell as a "banned process" for Box, for a workaround:
Close Box completely and set the following registry key:
- Create the regkey
HKEY_LOCAL_MACHINE/Software/Box/Box/BannedProcessNames
and set to a REG_MULTI_SZ
type.
- Then add the name of the process to the list,
powershell.exe
I also added DBUtilRemovalTool.exe to the list as well, since the affected users were all on Dell Laptops. After a restart and exiting and then signing back in to Box, the error notifications stopped.
No word yet on a more direct fix.
powershell.exe
I will add that to the list right now. I had powershell but was not sure if it would work.
Thanks for that!
My information security might not like banning the entire powershell process from the folder, but I'll bring it up with them.
Thanks!

Does that look right?
Yup! Then have them restart (close out of Box, restart the computer, then sign back in to Box) and see if that resolves it for now.
I am also having this issue which started recently. I have been using Adobe Media Encoder. The constant notifications are driving me crazy.
I would try the steps below per Jessica Winsett. It worked for us!
I think we actually do use Nessus too, so that would make sense.
We ended up having to (for the few affected users) exclude Powershell as a "banned process" for Box, for a workaround:
Close Box completely and set the following registry key:
- Create the regkey
HKEY_LOCAL_MACHINE/Software/Box/Box/BannedProcessNames
and set to a REG_MULTI_SZ
type.
- Then add the name of the process to the list,
powershell.exe
I also added DBUtilRemovalTool.exe to the list as well, since the affected users were all on Dell Laptops. After a restart and exiting and then signing back in to Box, the error notifications stopped.
No word yet on a more direct fix.
I am having the same issue. Very frustrating and annoying. Is there a fix?
Have we confirmed that adding the keys is the fix? We use Tenable.io and it seems that this happens to our users from time to time when a scan runs.
What does this actually do?
- Create the regkey
HKEY_LOCAL_MACHINE/Software/Box/Box/BannedProcessNames
and set to a REG_MULTI_SZ
type.
- Then add the name of the process to the list,
powershell.exe
The regkey option does not work for us, the errors are constant and the only real workaround is to "ignore it" - this needs to be addressed.
Below is what ours looks like. Are you using tenable as well?
Once we implemented this GPO and rebooted the pop ups went away.
I have people still having this issue. Does anyone know what causes this yet or if Box is planning on patching this issue? I have tried things people have suggested here. We have Win10 machines deployed if that helps.
hawkeyeba
Do you have any vulnerability scanning tool installed on your machines?
Bryan, we do have a AntiVirus software installed not sure if that does vulnerability scanning or not specifically.
You need to look through the Box Drive logs and see which processes are accessing the files. And then exclude that .exe with the registry key outlined here. We were able to fix the issue by excluding powershell.exe for the tenable scanner.
So, I'm getting this today - over and over again. This is on Windows 10. It's clearly a defect in the Box Drive design - don't they have any intention of fixing it? There is no reason I should have to remove or disable programs or their access to certain directories. Box should work OK with the same things every other program is OK with.
At a minimum, can't Box give us a way to reduce the number of messages? For example, why can't I get just ONE notification each time Box goes through all the folders, instead of a notification for each of the (many) folders I have?
While the registry keys worked for my enterprise, I totally agree that it shouldn't be necessary. When a company is debating between Box and OneDrive, the little things like this make a big difference.
Box Support provided the following explanation: "This is a behavior that we have seen in the past and our Engineering Team has identified that this is caused by 3rd party programs traversing through the filesystem. When scanning files in the Box Drive folder, this triggers a download of any non-cached documents. For users with a large number of files, you'll see high CPU usage, network degradation, and if the download requests exceed a rate limit, you'll start receiving these notifications. Since the software continues to scan, the user gets hit with a bunch of notifications in quick succession."
They recommend creating the "Banned Processes Name" registry key as others have mentioned previously...not the answer I was hoping for :(
I'd bet that hiding any directory from scanning by any program is against my company policy, since it would prevent any of their security or compliance related scan programs from seeing things there.
Agree with the last post. This is not a fix it's more of a workaround/band-aid to the problem.
Your company shouldn't be relying on tools that scan the users' PC's for Box security. You should be relying on Box's built-in virus scanning and/or using other tools that scan Box directly.
429462762034 I don't think anyone is relying on a tool to scan the users PC for box security, it's endpoint security that's the concern. The Box Drive folders are still on the users endpoint and adding an exception is one place that you won't be looking for malicious content that could harm the computer.
I had this issue as well. Looking at the Box logs, Git was bombarding Box. For some reason, there was an open Git repository in the same folder as the Box Drive app scanning all of the files. After deleting the repository, the notices seem to have stopped.
I found the culprit in my environment. Review the Streem file located in %localappdata%\Box\Box\Logs\Box_Stream_DATE.log
To fix I remotely ran this command to fix. (Keep in mind for my environment it was EmUser.exe (Related to an Ivanti product we use)
REG ADD "HKLM\SOFTWARE\Box\Box" /v BannedProcessNames /t REG_MULTI_SZ /d EmUser.exe
Here is a sample from log file...
2022-09-21 12:06:11.577 ERROR 0x00004494 4winfs:647]7onEnumerateDirectory] ]EmUser.exe] ..\streemfs\filesystem\folderfetch\folderfetcher.cpp(114): Throw in function void __cdecl box::throwAppropriateFetchErrorIfNecessary(const class std::shared_ptr<class box::BaseFSFolder> &)
Dynamic exception type: struct boost::wrapexcept<class box::FSTimeoutException>
std::exception::what: Unknown exception
/struct box::exceptionInodeIdObject * __ptr64] = 43553