Opus is not responding on one of our systems when shift-deleting or deleting to recycle a set of files from a junction point dir. The files get deleted but dopus is then hung.
Hang happens whether deleting from the source or target of the link.
I have emailed a .dmp from to crashdumps@gpsoft.com.au along with our reg. code.
Build 7076 (12.14 x64) Pro edition.
Thanks for any advice.
-Paul
Is LinkShellExtension installed? If so it may be related to this and need updating:
I don't think it's installed. I looked in autoruns and didnt see it under the explorer tab.
There an nvidia shell extension and a bunch from dopus..
Could you tell us more about the junction's source and target? Is a network drive involved or any other info that might help us re-create what you're seeing? (If a network drive, is it Windows, or something else?)
Is this only happening on one particular machine, even when the same thing is done on others, with the same location/junction? Is the type of drive/folder/junction involved the same on both machines? (e.g. It's not a network drive on one and a local drive on the other, or anything like that.)
Does turning on Preferences / Miscellaneous / Advanced [Troubleshooting]: no_external_change_notify make any difference?
If that does make a difference, please try resetting it back to False, then turn on Preferences / Miscellaneous / Advanced [Troubleshooting]: notify_debug instead and see what is output to DebugView.
Additional crash dumps may also be useful, in case the one sent just polled the process at a bad time. The code the dump shows was executing would not usually run for more than 1 second, unless there is a change-event loop somewhere. I've been looking for a loop but haven't been able to find one so far, but additional dumps may show I'm looking for the wrong thing.
Hi Leo,
We will try the notify settings and get some more minidumps when in the office tomorrow.
The machine in question is a 64 hw thread threadripper. The drive is an Intel optane ssd with a link to a folder on a bigger drive of various graphics assets ( custom binary format is what we are deleting ). The other drive is also ssd probably nvme. Will confirm.
My work machine has pretty much the same setup but with a nvme ssd linked to a sata ssd. On an Intel 16 hw thread 8 core i7 x299 mobo. It has no issues. Both machines have windows defender exclusions for the root folders of source and target. We both use search everything ( voidtools)
Thanks for getting back so quickly. Will send more minidumps tomorrow and turn off some more.shell extensions that the nirsoft tool showed up ( eg sketch-up ).
Paul
More dumps would be great if you can. Many thanks, and for the extra info.
Don't worry about the exact drive types; if they're local drives that rules out a category of network drive issues. (The only thing that might be relevant is if the target is a non-NTFS drive, possibly, but that's unlikely unless it's removable, which it doesn't sound like it is.)
From the first dump, it probably isn't a shell extension issue, so don't worry about those either, at least for now. (Of course, if the new dumps indicate something different then it might make sense to look in that direction again, but don't worry about it for now.)
The two Prefs/Misc/Advanced/Troubleshooting options may still reveal something and are definitely worth a try though.
Hi Leo
Turning on no_external_change_notify does stop the hang.
I have emailed the debugview log to your carshdumps email address.
As you will see in the log, this hang was deleting two fsubolders and 10 or so files from a folder on the junction point.
Based on this we didn't grab more dumps, but can do so if you would still like us to / would be useful.
Thanks!
-Paul
We spoke to soon. Initial tests with no_external_change_notify did not hang, but the developer is still getting the hang on delete depending on which/how many files he deletes.
We'll send on some more minidumps when he gets chance to grab some.
Sorry for the confusion.
Hi Leo, I work with Paul. I can also repro the hang another way - if I just select 8+ files in that particular folder, and then click on another app/window and then click back on dopus - dopus is no longer responding, i.e. I didn't even need to try and delete the files. Paul can send you a log/dmp of that situation. Like I mention, doesn't happen in all folders (on the mapped drive), in others I can select, delete any number of files/folders without trouble.
Thanks for the extra info.
Is there anything different about the files and folders where it does and doesn't happen? Maybe the types of files?
Is the viewer pane open when you select things? Or are you potentially hovering over the files long enough to trigger the tooltip to appear? Those could trigger code/components to be run which are specific to certain file types and might be why it happens in some folders and not others.
It might also be worth trying Directory Opus 12.14.1 (Beta) to see if that makes a difference, since there is a fix in there for an issue which is hard to trigger (unless using French Windows, where it's fairly easy, for fairly random reasons) but can cause hard to diagnose problems if it is triggered. Ruling that out would be worthwhile (and if it is that issue then the beta will fix it).
I had a look at the second dump but everything looks normal in that one. None of the threads appear to be hung, and the program looks like it is waiting for user input. (Which is how dumps can look with the bug that 12.14.1-beta fixes, so it could well be that.)
Hi Leo, I tried the beta, but was still getting the hang.
I did manage to narrow down the problem somewhat:
Firstly, I have the viewer pane open, and yes, this seems to be the root of the issue.
Secondly, I narrowed the hang down to files of ours that had a .vtx extension. These files are a custom format of ours, but dopus thinks it's a visio document, so looks like it hangs trying to preview or parse those files. It hangs if I just select the file.
If I shut the viewer pane down, it no longer hangs.
If I rename the file(s) with .vtx extension (and restart dopus), it doesn't hang (with the viewer pane open).
We'll ping you those files that are problematic, it might be anything that the viewer pane struggles to parse, not just .vtx?
Mario
It'll be the Visio preview handler locking up.
If you go to Preferences / Viewer / Plugins, select the entry for ActiveX + Preview + Office + Web and click Configure, you'll see a list of file types. Locate the one for Microsoft Visio, click it and then use the list on the right to delete the .vtx file extension from its list.
Or, if you never view Visio documents anyway, you could turn off the preview handler for Visio altogether.
Thanks Leo and Jon, for the support, looking at the minidumps/logs and all the suggestions. Much appreciated.
-Paul
That does the trick, many thanks!
Likely simple reason the hang wasn't reproducible across machines was due to file ordering - on the pc where it was hanging, the .vtx file always appeared to be last in the list of selected files, hence the one that ended up in the viewer pane.