Yes, I have had similar experience. It also remains unsolved for me. It is either related to network connectivity (that might drop and thanks to bugs in Windows - trying to reconnect in a failing manner) or issues in the block of the OS that is responsible for the underlying part.
However, one workaround is to tunnel your SMB daemon port via SSH. Not only is that going to provide encryption, but it will also solve your stability problem (at least it did for me). Take a look at Tunnelier. It is one piece of mature software. What I do is tunnel a port to my SMB server (a Client-to-Server rule) - this way the connection remains pretty much static (TCP/IP) and disconnects are handled automatically. This enables me to bind a port on the localhost Windows machine, that i can use to map a network drive with - so, a pair of 127.0.0.1 and 445. Once accessed - the traffic is tunneled and arrives at the remote endpoint. That's it.
But, as with everything, there are particular caveats. The real problem, is that port 445 is already bound on localhost by the OS and the bad news is - it is not possible to unbind it the easy way. Also, it is NOT possible to map a network drive to any other port but 445 (let's leave out 139/NetBIOS out of this).
So, what I really do, is actually bind this port on my router (thanks to dd-wrt) and just map the IP of my router for a network drive. This way I can circumvent the limitations outlined above.
Another workaround, OS wise, is using a "bruteforce" method to free up the bound port. Inspect ncpa.cpl and navigate to your adapters properties. You would have to sacrifice a service - File and Printer Sharing for Microsoft Networks: remove/uninstall it. Then, download this utility. What it does is apply a series of registry changes to deliberately force the OS to free up the needed port. Once everything is done - you can now bind 445 on localhost through Tunnelier or some netsh goodness. Good luck!