I just experienced an issue where WinBox kept closing over and over, and I had the issue a few weeks ago as well. AFAICT, it's caused by having an active simple queue set up to limit bandwidth when the bandwidth is maxing out the queue. I had the problem both on a previous version (firmware 6.40.4, WinBox 3.17) and the current one (6.42.11, 3.18). I'm not sure if this is a bug or simply a side-effect of how queues work, but the connection between WinBox and the router should have priority and shouldn't be so easily broken.

is it IP or MAC connection?
when connecting via IP, winbox uses unicast TCP packets.
when connecting via MAC, winbox uses broadcast UDP packets.

TCP does not really care about some small packet loss (which is typical result of queues) but UDP does and I noticed that winbox with MAC connection has much higher tendency to get disconnected. (same applies for ROMON connections which are not TCP based)

IP

Also, I don't get how queues limit bandwidth by dropping packets. If a download is going and driving the bandwidth past the cutoff causing it to start dropping packets to limit it, wouldn't those just have to be redownloaded, which means you'll actually use more bandwidth? I'm sure I'm misunderstanding something, but it never made sense.

Also, I don't get how queues limit bandwidth by dropping packets. If a download is going and driving the bandwidth past the cutoff causing it to start dropping packets to limit it, wouldn't those just have to be redownloaded, which means you'll actually use more bandwidth? I'm sure I'm misunderstanding something, but it never made sense.

As @vecernik87 nicely described: TCP performs retransmissions already on protocol level, so the application does not notice it. When using TCP, receiver has to acknowledge received data to the sender. This is base mechanism for retransmissions (if sender sees a negative acknowledge, it know it needs to retransmit that packet). Sender will only transmit up to "TCP Window Size" data before getting back acknowledgements. If acknowledgements are delayed, this will lower average throughput between sender and receiver. Successful acknowledgements will increase Window size making average throughput higher. If acknowledges don't arrive in timely manner or if sender receives a negative acknowledgement, then sender will re-transmit some data, at the same time retransmissions will shrink TCP window size which in turn quite directly affect connection throughput (which is what we want to achieve by dropping packets).
UDP, on the other hand, doesn't do retransmissions so application has to deal with it. If app doesn't care about lost packets, then it's obviously fine to drop surplus packets anyway. If app does care about lost packets, then it would have to throttle down on Tx side or else the practical throughput will just drop to underground. Which servers fine those rogues apps not caring about others.

Yes, either way some more data will have to pass the connection to make up dropped packets. But probably it will do so with lower throughput which will make room for other connections to get some data as well.

Thanks for the explanation, makes much more sense now.