This depends on the meaning/context of the exception.
For example, the current project I'm working on uses a
BusinessException class. This is used for any explicitly thrown exception with a message (in more layers than just the BLL - I'm aware that the name is misleading). The
BusinessException therefore lives in the domain layer (= where
IMyService is located).
For those interested, the main reason to use
BusinessException is that we allow these exception messages to be returned to the consumer of our web API, whereas all other exceptions get rephrased to "an error has occurred".
One of our business logic classes has a particular
UserIsInactiveException. This particular exception is only used as a particular business logic rule (inactive users are not allowed to update data). Therefore, we inherently know that it will only be used on the Business Logic Layer, and therefore it lives in the BLL project (= where
MyService is located).
UserIsInactiveException inherits from
BusinessException. But the location of the exceptions would be the same regardless of them having an inheritance or not.
My own thoughts on this are that the exception should probably live with the implementation, as the exception is most likely an implementation detail.
What you say isn't incorrect, but it's not universally applicable either. Some exceptions are part of your framework more than they are an implementation detail, for example when your framework is expected to handle certain (custom) exceptions differently.