Q:

The problem of dependencies management

Let's consider the next situation:

We have a module A which has a class Crt570 intended to interact with a device.
We have a module B which uses Crt570 in the class called M100Communicator.
We have two applications C and D and both of them wants to use module B.
Application D wants to use B, but doesn't want to use Crt570 and reference module A, therefore.

"Module" here means dll.
So we decided to extract an interface from Crt570 and called it ICrt570.
But what to do with that now? It's just very strange to move ICrt570 into the domain module (let's call it module E) or somewhere else because after that Crt570 has to reference the module which will contain ICrt570!
How to solve the puzzle?
UPDATE
In order to make the question more clear for readers in the future I'll add a bit more details.
Module A is the dll which contains nothing but Crt570 class (with it's infrastructure). So this dll is dedicated to manage a device absolutely, nothing more.
Module B is the dll which contains models specific for several applications in our domain.
At least 3 applications want to use this module and they, of course, don't want to pull dll's they don't need.
One of the models that C and D apps want to use is the M100Communicator model. And, in particular, this class (M100Communicator) depends on module A (Crt570 class).
Module E which I mentioned is a domain module. It contains many classes and interfaces, so module A doesn't want to use it, apparently.

A:

As david.pfx writes in his comment, there is a bit of info missing, but I am willing to give it a shot.
I am making an assumption in my answer.

The reason that C and D both want to use B is, at least in part, to use M100Communicator

Thereafter it kinda depends on if other modules are around that want to use the ICrt570 interface.
Scenario A
If it is only module B that needs to interact with your interface, you could define it there. Then the two C and D, could give M100Communicator each an implementation of ICrt570. 

C References A and B Giving Crt570 from A to M100Communicator as the implementation of ICrt570 to be used. (A would also have to reference B since it is implementing an interface defined there)
D References only B. Since M100Communicatorneeds an ICrt570implementation it still has to supply this. Either it has to make an implementation itself or reference another module with an implementation.

Scenario B
If, on the other hand other modules than B are going to have a dependency on ICrt570, then you would need to move it to some other module, maybe even its own.
You could define the module Eas you mention, containing ICrt570. This module's reason for living is to be the "Device communications interface module". This module defines interfaces, nothing else.
Then all the others can reference this module: A to implement the interface, Bto have a dependency on it. C and D so they know what ICrt570 is. Since this module is only interfaces there isn't much "harm" in referencing it.
C and D are now free to choose whichever implementation of ICrt570 that they want. Same goes for X, Y, Z who also use ICrt570 in some way. 
A couple of points

References are not necessarily bad, only if the modules you reference have a lot of different stuff you don't want. Then you might have a problem with The Single Responsibility Principle, your modules might be doing too much.
Something that helped me better understand dependency management with low coupling, was to study the Onion Architecture by Jeffrey Palermo. He takes the whole thing very far, some might say too far. But the principles of low coupling, dependency injection etc. are explained very well in his blog posts.

