Some additional information and clarification now that I've had time to do some testing and digging. I apologize if I posted too soon and with too little detail - my concern was just that it might be something big that somehow slipped through.
First, to fix a mistake, I said 12.12 worked fine - but I was on 12.11 until I went straight to 12.14. And that's when all heck broke loose for me.
When I say hang I do not mean forever - although it was at least 45-60 seconds. Because my first reaction was to make sure those drives were powered up and then run Windows Explorer (remember I am on Win7) and then Powershell. All the drives appeared there, so I killed the DO process (I had only 1 lister open but approx 8 tabs) and shut the machine down. I figure it took 45-60 seconds for me to do those things.
To clarify my use of SUBST, I have a .bat in C:\ that does the SUBST and also which execs a .reg file with registry entries that allow me assign labels that make sense instead of the default which is to duplicate the source drive label. This .bat has no shortcut and is not executed with elevated perms - at least I don't think so. As I wrote that I realized I was not 100% certain that the HKLM reg key "Run", but I am fairly certain it runs as the user that logs in (since it executes at login not boot and does so every time a user logs in).
I did a bit of testing and set up a VirtualBox VM (still Win7.64) and loaded DO 12.14 and experienced the same results (although I doubt I let it go 60 seconds). Again though, Explorer saw the drives no problem.
Worth pointing out here - though - is an old post of mine where I described DO showing network mapped drives with red X's - where Explorer did not - and where DO would allow me to access the drives eventually but never changed those X's. Which I -highly- suspect relates to another post I made, I think including a screenshot, where the DO treeview was (and still doesn't) update properly for some network drives - even when the listview shows folders and with all hiding disabled - and I've tried every Refresh/RebuildTree command I could. So possibly these are all related to my config?
When you say unavailable network drives often cause delays - Do you mean even if I have NOT tried to access it in ANY way? Is DO querying every drive in the tree? If so, perhaps I can delve more into scripting and turn on/off a filter to remove those drives from the tree? Sound feasible?
I will test out the question of whether going into a folder in Explorer makes DO faster after that. Also, I cannot say for sure whether this happens more than once - which seems silly of me as I write it, so I will test that on the VM as well. I just get real nervous real quick when anything involving any of my drives seems to be weird! LOL
And I don't know if this will help - but I wrote some c# code to enumerate drives and read from them, but of course this is managed dotnet code and not winapi stuff. But I will run it anyway and see what I find.
Manual crash dump - check - I'll do that. And I can get the ProcMon log as well.
One last clarification, not sure if it matters or not, but my OS is Win7Ultimate64 --SP1-- only, I have NOT installed updates beyond that (I think one is called "platform update"?) and I have this stripped bare naked - no automatic updates of any kind, no windows defender or anything else. The barest minimum OS. Which I will add is blazingly fast on a core i7 with 16gb of ram and fast drives. Only thing faster is Kubuntu and I'm betting I won't see DO on that anytime ever! LOL