I used to have this problem a TON, and it drove me absolutely batty.
One thing I've found that's drastically cut down on the frequency (possibly eliminated it? not sure) is this: Always wait ten seconds between display state changes. Waking the computer up from sleep? Wait ten seconds before you dock it or connect an external monitor. Undocking it? Wait ten seconds before putting it to sleep.
Also: never make more than one state change at a time. For example, don't put the computer to sleep while docked, then undock it. Undock it first, wait ten seconds, then put it to sleep.
YMMV, but like I said: I think this has eliminated this problem for me. I've been using this process for some months now, and I'm doing much better at the uptime game (28 days since my last restart, right now).
>Always wait ten seconds between display state changes
Yes, that's a good thumb rule when dealing with hardware+software. Not just for displays either. Seen many cases of it. I have a USB modem for mobile Net, for which I wait for a few seconds after it shows the login dialog, to make sure it has fully initialized, even though the dialog seems to indicate it is ready. If I click Connect in the dialog a few seconds too early, it connects but often then the speed comes down to zero quickly. Disconnecting, closing the dialog, removing the modem, waiting 5 seconds, plugging it back in, waiting for the dialog to come up again, and then waiting an extra 5 or so seconds, fixes the issue.
Remember issues like this from my system engineer days too (Unix and related support to customers in the field). Once a Unix minicomputer was not booting. (Was working for a large Indian Unix hardware vendor then - India got Unix early and became a Unix country, because of an RBI mandate on bank computerization.) This was at a hospital and they had a lot of critical patient and billing data on it. Backups could have been restored after changing the hard disk, but that would mean machine downtime on a live hospital system. Maybe a lot of time to get a replacement hard disk too, from head office.
Others had tried - hardware engineers. I was called in (I was a system engineer, aka software troubleshooter). Tried rebooting. Did not work - hung before kernel boot messages. Rebooted again. No luck. Did it again. Nope. Others said, drop it, lets try something else. I said - wait. Rebooted it again. It came up fine. End of story :)
Of course, I did a lot of other (and some harder) kinds of troubleshooting stuff in that role too, not just rebooting boxes :) But the point is that this kind of experience and common sense often worked when sometimes other things didn't. So it takes all kinds of skills ...
>Also: never make more than one state change at a time.
Yes, good point, and a fundamental tenet of troubleshooting in general. Also to make each change reversible, as far as possible. You can bork a system by one innocent / ignorant change to a config file in /etc, for example. A lot of us learned it on our own (sometimes the hard way, ha ha, got a few stories there), later I also saw it mentioned in an early part of the O'Reilly book Unix System Administration by Aileen Frisch. Very good book, as is another book (thick one) by Nemeth et al - the Unix System Administration Handbook (later there was a Linux edition too).
What OS are you using? I'm on an x260, I had issues on Ubuntu 14 and 16, but since moving to Fedora Workstation 25 I've had an extremely pleasant experience from a hardware/docking point of view.
Fedora has changed the game for me as well. I am a very happy user so far. Although sometimes i see some notifications about a software crash somewhere.
I really enjoy my time on Gnome3, there are very few annoyances as compared to windows/osx. Although i feel osx is way more polished in terms of gestures/ui etc. windows had been an absolute nightmare since windows8.
