Slowness / Non responsive in window showing Drive List

Returning to the question:

I don't, yet, perceive any kind of logical pattern as to when & why this happens.
It just periodically does

That's not to say 100% a pattern isnt there!
Just if it is, then it hasn't become obvious to me.

If I have DirOpus running over then next couple of days then I'll throw all the move, rename, delete jobs at it I can think of.

I'l also try with lots of different combinations of external drives connected.

Hope that will provoke problems &, hence, illuminate the issue somewhat more :crossed_fingers:t2:


I do have a drop down arrow in the Lister address bar that shows me all my drives.

image

Do you think that seriously could be the cause of all the slowdowns?

I REALLY hope its that easy. Would be great.

To be clear, the crashes/freezes do NOT happen when I use that drop down.

Just that Leo asked me about buttons etc of that nature so I thought I'd best 'admit' that I do have it.

It doesn't act as a trigger, when used, though.


The freezes sometimes happen just when I'm switching Lister or trying to 'drag & drop' or, to be honest, any number of fairly common file operations. :thinking:

Nothing exotic going on when it happens, as far I can see.

Thanks,
S

I can see that. I was just asking that we leave that off-topic subject there rather than create more noise in our forum, which you've gone and done anyway, again.

Yes, or I would not have said what I said.

The logs we have seen so far show that the freeze was happening when that list of drives was being updated. (Or, at least, that list or another list of drives somewhere else on the toolbars or in a menu.)

It's not about using the dropdown. It happens when the toolbar is updated, which is triggered by a lot of different things.

I've got an internal HDD drive that died in a very similar way. Windows still did not report failing disk, as thresholds were not exceeded, but SMART values were showing something's going on. Explorer also had issues but to a much less degree.

Right,
Here we go

I'm back to getting the slow-down grinds, freezes and, just now, an actual crash. Thus, I can provide more useful crash logs (.dmp files) to Jon & Leo now.

I didn't have so many recently. That's because I was mainly just noodling with DirOpus, experimenting & ploughing through hundreds of forum threads! :sweat_smile:

Now, I've gone back to more normal working patterns (not all DOpus learning & tweaking all the time :wink:)

Let's see what we can see

Sending via WeTransfer now

image

Many thanks for the new snapshots!

Possible fixes coming in 12.21.4 beta:

I've spent most of today looking at those and for possible fixes/mitigations. I've made some changes which will be in the next beta version, 12.21.4, which we're aiming to release in the next day or so.

I can't be certain these changes will fix things but, once the beta is released, please give it a try.

If the fixes don't help:

If you still get any freeze or crash after 12.21.4 beta is installed, please make a couple of new snapshots and send them to us in case they reveal something new.

Any detail of what was happening leading up to the freeze/crash in the snapshots that could also help work out what's going on.

For example, based on what I can see in the new snapshots, it looked like:

  • A double-click on a folder below your S:\ drive started reading the folder but never completed.
  • Some files were being copied in the background in most cases (I don't think they're involved).
  • Folder sizes were being auto-calculated in most cases (probably not involved, but unusual, so could be a factor).
  • The actual crash/freeze happened while doing a drag & drop of some archive files on your K:\ drive.
    (although I can't tell what they were being dragged over, which could be an important piece of information, especially if the drag & drop crossed over any other programs/windows)

Does that make sense and fit with what you were doing?

Observations in more detail:

The K:\ drive drag & drop side of that is strange, since everything looks fine within all the Opus code, but the OS seems to be taking a very long time, or even crashing, when it is parsing the file/folder paths. (That is at least somewhat similar to the original issue/snapshot with the G:\ drive icons/labels taking a long time. I'm not sure what would affect both those operations, though, and it may be a coincidence.)

With the S:\ drive double-click, the changes in the next beta aim to address that. We found some places where it might happen, at least in theory. (It should be impossible normally, but maybe a specific configuration and sequence of events/commands can trigger it. We've added some additional checks for those situations.)

We also found an issue with the Go DUALPATH command. I don't think any part of the default config uses that, but if you are using it it might be worth knowing as it could have been involved. Those issues are fixed in the coming 12.21.4 beta.

Automatic crash dumps:

If Opus is crashing (not just freezing) and showing the Thread successfully terminated message in your screenshot, there should also be some Automatic crash logs (for bug reports) of the exact moment of the crash. Those are usually much smaller than full process snapshots, but can be very useful. If you have any of those, please send them to us.

Many thanks!

1 Like

Great, Leo

That was a very in-depth response. :+1:t2:

"sub-folder called DOpus.Minidumps" : In
C:\Users<USERNAME>\AppData\Local\Temp\DOpus.Minidumps

  • that's where the auto saved files go, yes? -
    I'll check that momentarily & send them to crashdumps@gpsoft.com.au
    --

I included that re-cap because I'm spending a long time searching for other answers in forum. So, I thought other customers/users might appreciate useful bits of info dropped into recent 2020 posts. Especially those with less skill or, to be frank, time to spend an hour+ searching & reading

Can't do any help & might do some good, no?

I know it would help me on other issues I have so I assume others might be in similar need. -> I'm paying it forward :wink:

Thanks for all the work, truly

1 Like

The automatic crash dump confirms that the crash seems to be happening during a drag & drop.

The crash itself inside part of Windows (the DragDropHelper object inside of shell32.dll), so we can't tell what's going wrong there really, at least without a way to reproduce it.

If you can tell us more about what you're doing when those crashes occur, it might lead to a way to reproduce the problem (assuming it's still happening in the new beta out today).

For example: What is being dragged from where, to where, and over what along the way.

I dont remember a drag-drop Triggering it. Certainly, I've had crashes, freezes in even tof just opening a new lister

However, in this case maybe it looks like a drag drop but isnt? If I remeber correctly I was, on one at least, calling the context menu on a bunch of files

Could that look like a drag & drop in the crash report?

S

It's definitely a drag & drop happening. Further up the stack it's responding to the mouse button going down over a file.

Drag & drop can be triggered accidentally if you move the mouse a little while clicking files. Something like that might be what's happening.

That or something is simulating mouse input over the lister, perhaps.

Elucidate that a bit, please
What kind of something am I looking for?

Some kind of automation tool could be doing it. It's not that likely, though, unless you're using something that would do that kind of thing around the time the problem happens. If nothing comes to mind, I would not worry about that.

Thanks, Leo

I don't believe I have any automation tools - not even scheduled backups (windows built in try to run & fails occasionally)

S

Can I send your any more logs or anything that might help?

Or do we just await the next crash & keep fingers crossed for more info?

Please grab the new beta (12.21.4) and see if the problem still happens with that.

If it does still happen, please send us any logs and we'll investigate them to see if the beta changes made a difference.

Many thanks!

Done already - Beta 12.21.4

It was the most recent available yesterday, yes?

Thanks
S

I need to be able to edit my post above :arrow_up:

To fix / add information without creating a new post

Have I misplaced it?
or
Has that function disappeared?

Can it come back, please?


This was meant to go in quietly without a new post:
image

If you add information via edits almost a day later, people may not notice them. The information is already in the thread now, so no need to edit anything.

You should be able to edit posts within a few minutes of them being made. After that, it's best to add new info in a new post if it looks useful.

(n.b. The build number is usually not important, but you can use the Copy button at the bottom of the About dialog if you want the full set of details in text form. The version number is usually enough on its own, though. No need to worry too much about the rest.)

Ok, Thanks

Is it right that I cannot edit the one i just posted less than 10 minutes ago? - the one with screenshot

What's the time limit from posted to no longer editable?

PS. You want this minor follow-on query moved to new thread?
Is it that strict?
I'll do it
Just clarifying what I you want me to do with diff questions

Ta,
S

BTW

What with our original confusion, weeks back, the thread ended up not exactly labelled correctly to the issue we are now discussing.

Should really now just be something like
"Slowness / Non-responsiveness / Crashes = unpredictable to user. Solution?"

It's NOT "Drive List opening" specific.

Worth changing?
Can you?

S

I've looked at the snapshots you sent on Saturday and Sunday and they show that the process is freezing inside of Windows when querying your Q:\ drive this time.

The drive letter seems to change, but the general problem stays the same: Something about your drives or your system or your antivirus is causing freezes when drives are accessed for basic queries such as icons, labels, file/folder attributes, and so on.

That's the last of the help you'll get from us on this issue, after your behavior* over the last few weeks, and given this issue has not being reported by anyone else.

(*Including creating multiple sockpuppet accounts to bypass a temporary forum ban, and then filling the forum with foreign language posts, many of which served no actual purpose or were asking questions that you already had answers to, which was part of the original complaint, and then sending multiple lengthy complaints via email after we had asked you to stop contacting us. The ban is now permanent and will not be lifted.)