A single folder always the same makes Directory Opus crash.
What happened, when I click on that folder always the same one the program crash, the Windows 10 error window briefly appears that the program has stopped working. No Directory Opus error window is appearing in between to let me know what it is going on.
Without any problem the folder is accessible from Window Explorer. Why a folder makes Directory Opus crash, what would cause this to happen. What would be the thing to do to access that folder from Directory Opus?
To let you know I have uninstall and install the program several times thinking the program was corrupted. I found out some settings like the group tab folders were corrupted, I had to delete them and rebuild each one of them. Another thing that might help, I have changed the computer I was able to use the same disk without reinstalling Windows 10. On startup, it has discovered the changes that were made. The defective laptop was an HP zBook G3 and the new one is a G4 with the same type of monitor, processor, video and memory. Sometimes the program takes a long time to load I've just tried it, it took 4 seconds. I remember I had some problem with the shell, I know this directory has the Tortoise version control, I also have another folder which has also Tortoise set, I do not have any problem accessing it. Another thing that I've done is disabling the antivirus and VPN. Even with all these things that I've done Directory Opus crash on that folder.
It is on a local drive use for projects only, it is on D: drive Windows starts on the C: drive.
The folder is for 4 GL language development software, it contains mostly text files of object classes, setup and others needed for the development environment and some binary files use by the language application software. Many folders are in Tortoise SVN control version, there's some zip file for backup.
Try copying the files to another folder (maybe in a few groups/batches to work out if it’s a particular file/type) to see if the problem also happens there, and if so which files cause it.
I would also try disabling or temporarily uninstalling the SVN shell extension to see if it is involved, since it’s going to be fetching overlay icons for the files at least.
I have copied the entire folder Project on the same drive to another one with the folder name ProjectCopy; click on it, no problem occurred while accessing the folder, this without uninstalling the SVN, I was able to move around the subfolders.
After that I have renamed the old folder to a temporary name from Project to ProjectOld and rename the ProjectCopy to Project, when I click on that folder knowing it is the copied one, Directory Opus crash, strange. Another thing when I click on the ProjectOld folder, knowing it is the guilty folder, there is no problem to move around within the folder and subfolders, this with the name folder ProjectOld, but if I put it back to Project, Directory Opus crash.
However, if I understand what it is going to the cause, it is the name of the folder that creates Directory Opus to crash.
As you ask to uninstall the SVN for which I did, even with the SVN uninstall Directory Opus still crash when accessing the same folder name, and I was able to move around within the rename ProjectCopy or ProjectOld.
I believe it does not have anything to do with the new or old content but with the name of the folder. The folder name "Project" cause Directory Opus to crash, but from Window Explorer I can move within the Project folder without any problem.
If it stops crashing when the folder is renamed, my guess is there's something configured to treat that folder specially. Maybe a cloud storage tool, or something else related to SVN.
If there are still no DMP files created, the easiest way to track it down might be to create a Process Monitor log of what happens when you go into the folder and trigger the problem.
Please include both file and registry details when making the log, and let us know which folder it is that triggers it.
It looks likely to be a shell extension issue. The last thing Opus does before the process crashes involves loading two shell extensions:
ti_managers_proxy.dll (C:\Program Files (x86)\Acronis\CyberProtectHomeOffice)
(Checking to see if it wants to add overlays in the corner of file/folder icons.)
AcShellExtension.dll (C:\Program Files\Common Files\Autodesk Shared\AcShellEx)
(Checking to see if it want to add any custom columns to the file display.)
AcShellExtension.dll is the last one that is loaded, so I would suspect that one more, but sometimes the issue is in an earlier operation that leaves the process in a state where the next thing fails, so it could be either of them. (Of course, it could also be something else entirely, but these look most likely right now.)
Would it be possible to try using ShellExView to disable any shell extension related to those DLLs, then reboot and see if the problem remains? That will tell us if we're on the right track.
DLLs may include multiple shell extensions, but you can sort the ShellExView list by DLL path to find them all at once. Click the DLL's first extension, then shift-click its last one to select them all; right-click, and disable them via the menu. After testing, they can be re-enabled again in the same way.
Checking for updates to either related program may also be worth doing first, in case it's a bug that has been fixed.
First I have updated Acronis and AutoCAD, even with the update Directory Opus still crash on the folder in question.
I have used ShellExView, I have disabled the associated DLL you are talking about above. Consequently, the Directory Opus was getting within the folder without crashing, meaning you have narrowed the cause of the problem when you have read the Process Monitor Log. One thing that I’ve done further is disabling either one of them. I found out by disabling only AcShellExtension.dll overlay in ShellExView from AutoCAD Directory Opus was getting in the folder meaning the real cause of the issue is AcShellExtension.dll. For the moment I’m making notes, the only overlay shell that is disabled are related to this DLL.