Thanks Daniel. Much appreciated.
I see this on Windows when I try to eject my USB external drive and never worked out what caused it. But what works usually is cancelling the request, maybe 2 or 3 times and it works after that.
Thanks Jasper. I have tried that a dozen time and it still does not work. Only force quitting WSA or restarting lets me remove it. But thanks for the tip.
What I suspect is that WSA leaves a reference to the drive open after the scan, and that makes the drive look busy. Common mistake when people access drives in a program.
Should be an easy fix if they looked for it.
@MajorHavoc Following-up on my response to your other post - I would expect a running scan by SecureAnywhere to lock a mounted DMG or drive if it’s being actively scanned by our Daemon. If the inability to eject a drive or un-mount a DMG occurs with no scan running and just the real time shield functions are active, I would consider this to be outside of our expected behavior.
Do you mind sharing the MacOS and SecureAnywhere versions that are installed on your system? The version of SecureAnywhere can be located by opening the main user interface, clicking the gear next to “My Account”, and then navigating to the “About SecureAnywhere” tab. You can also private message me with those details if you prefer.
I fully agree, if a scan was active I would expect the drive to be locked in. Although I would argue that the scan should immediately stop if an eject is requested, but maybe you are not given that system info alert?
But this is long past the end of the scan.
I am running the latest MacOS Sonoma 14.6 (23G80), but this has been going on for several generations of MacOS.
WSA is 9.6.4.85:1727. But agin, this has been happening for quite some time and several versions
Happy to provide any other info you need But I’m not allowed to give remote access due to private client info kept in this machine
thanks for the response
@MajorHavoc Thanks for sharing. I’ll be back at the office tomorrow and have time to start testing this further. I’ll let you know what I learn. What you’ve described sounds to me like a potential bug; so if this is easy to replicate or we can get enough information to take action on it, I will make sure it gets documented and addressed. I cannot make any promises or guarantees at this moment regarding an ETA, but we will definitely be looking into this further as a team. Thanks for bringing it into focus.
That is all I can ask. Thank you.
I removed the Solved from this thread and it’s great that we have some communication from @JDeBerry nice to meet you! 
Thanks!
I’m good with the private talk on this now. I’ll post an update when I have one. Thanks Daniel.
Just wondering who keeps marking this thread as solved? I have not given the best answer… so I unmarked it once again. @MajorHavoc choose another that’s best.
A quick update - our investigation so far suggests that a background scan of the removable media’s volume may be running and is incomplete at the time the ejection occurs. We are now pursuing this as a potential root cause, but as the behavior does not occur consistently, our goal is to try and find any variables that are consistent which might be a contributing factor we can evaluate in testing. I haven’t identified a specific pathway to replicate this, so any/all information is welcomed.
If anyone else is experiencing similar behaviors, I’d request they contact Support and we’ll be certain to collect all the necessary information to aid in our investigation. A huge thanks to @MajorHavoc for all the information and help he’s provided thus far. I will continue to share updates as I learn more.
