12.12 to 12.14 - hangs showing My Computer with lots of network drives

Help & Support
1

I upgraded to 12.14 today - I now get DO hanging in several various situations. 12.12 was working fine. That's the only change to the system. I have a fair number of drive letters, some are network mapped, some are not always available, and others are SUBST'd from local drives. One thing I noticed is clicking MyComputer will sometimes show half the drive letters, then hang. I don't have a lot of details to offer because I simply don't have time, and there's nothing in 12.14 I've been waiting for. So I'm uninstalling and going backwards, my apologies. Oh, and I am on Win7-64 on a machine that also runs other OSes using VirtualBox (one of the mapped drives points to a VM that is not always on). My setup is admittedly vastly more complex than most users - but again, I had no serious issues until installing 12.14 today.

If I can answer any questions or do any testing to help - I am willing to do what I can.
While I have been frustrated in the past by certain "issues" I faced in trying to configure DO to my personal liking - I do remain a big fan and supporter and will do what I can to help. I think there are some issues with this build.

2

When you say "hang" do you mean forever, or for a long time and then things start working again?

Unavailable network drives will often cause delays and there isn't always much that can be done about it. If we query one without knowing it's unreachable then it can take 30 seconds before Windows returns from the query and says it failed. And there's no way to know if something is unreachable without querying it.

Do you see anything similar in File Explorer, e.g. with the This PC folder there?

(Also check that showing the folder in one program doesn't then make it show faster for a while no matter which program you show it in next, which would make it hard to test if both are slow.)

12.13 had a change which made network drive querying slower in some situations, but that was fixed in 12.14.

A manually created dump during the hang/freeze may shed some light on things. ProcMon logs could also.

3

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

4

Just querying the icon, or label, or if the drive has a desktop.ini file on it, or if it exists, may cause a 30 second delay if Windows hasn't recently tried to access the drive and cached that it is not available. We try to keep calls that might trigger this off the UI thread, so they don't cause the UI to freeze for 30 seconds, but doing that 100% is much easier said than done.

It's best to completely avoid having mapped drive letters to things which are not always available. I use UNC paths instead of drive letters; haven't used mapped letters in many years.

If you can work out which version of Opus things got worse in, we might be able to work out what triggered that and change it back. But I'd also make sure it really doesn't happen in 12.11, and isn't the result of a change somewhere else.

1 Like
5

Damn skippy on that! I didn't have so much trouble in the c#/dotnet world, but I've spent the past year learning to hate Java and Swing and having to manage a pile of threads for a simple UI was one reason! (doesn't help that stringABC == "ABC" is false LOL couldn't teach myself that one)

You're absolutely right, and while I'd like to blame it on age and not wanting to change my old ways, it's actually just pure laziness on my part. Heck even if I wanted to keep my loverly-yet-stupid drive letters, thus continuing to offend my pure Unix upbringing, I could easily whip up a script to map/unmap those mounts when I needed them. It's embarrassing the stuff I do nowadays that I'd have fired an employee for in the wayback. So I'm going to dump them drive letters!
(Does DO have any issues with ext4 mounted filesystems using Ext2Fsd? Just curious, but considering an experiment of going to Kubuntu and using a VirtualBox VM for Win7 & DO, I can do c#/dotnet and everything else I do on this workstation with KU but they have nothing even CLOSE to DO in that world and I simply have too much data to handle to give it up)

Well I did some testing and have a couple more data points.... the hanging is > 90 seconds, but it's not FROZEN, meaning I can click a menu during this. But going into Windows Explorer and clicking on every drive I have (all drives were connected and operational during this test) - still nothing from DO. If I should click a button I have - which was kinda stupid really - it hangs DO for good. It's a script button I made in an attempt to force the tree to get itself accurate when it doesn't show folders that exist (from my post a while back). The command it runs is Go REBUILDTREE=BOTH so I can see why that would frustrate DO if it was trying to find all the drives! LOL
I didn't take any dump images yet - first, I ran outta time, but second I'm starting to think that this farking "SUBST" stuff may be at the least - exacerbating some other issues. I say that only because I had issues involving network drives long ago, if you recall my posts. The reason I decided to try the SUBST method is because most of my data is on locally connected drives, and Win7 is absolutely HORRENDOUS about blasting away your shares and/or permissions (granted I put this workstation thru a harsh pace, but still, c'mon this is ancient networking 101 here). So basically, I'm not quite so sure that 12.11 didn't have a problem as I haven't had the SUBST stuff going that long - mighty coincidental.

So here's what I'll do... by my last test, I conclude that the problem is NOT just a disconnected network drive, as they were ALL connected and reachable by Explorer. I will install 12.11 on a fresh VM and be sure NOT to load my settings or anything else I've customized - I'll go with stock install. And I'll have the SUBST drives set up. And see what happens! If it has a problem, next I will reboot and use Explorer to read into each of those SUBST'd drives FIRST before running DO. Also I will remove the step where I merge registry entries to set the labels on the drives. Somewhere along the line, I oughta figure something out! Honestly if it is this SUBST crap I don't even think it's worth fixing! Does anyone else still use it?

Ok enough for now.... as always kind Sir, thank you for your responses and for imparting your vast knowledge to we, your loyal-yet-sometimes-annoying users! :slight_smile: