I have been using Tab Groups for years without any issues but since upgrading to v12, Opus will occasionally lock up.
This is been happening since day one of using v12 but I have held back until now to see if there is a pattern but there doesn't seen to be one.
I have a pull-down menu with the command:
Go TABGROUPLIST=icons
...which lists all my Tab Groups (24 of them).
The lock-ups are quite random. I have been working on the same project for a month and every day I select that particular Tab Group. Maybe once every couple of days, I will get a lock-up. I have tried waiting for Opus to come back to life but it seems pointless after waiting a few minutes for something which usually happens instantly. I once left it for over 10 minutes but it still never came back to life.
The only way I can get it back to life is by exiting via the Opus notification icon area and running DOPUS.EXE again.
Further information:
I am using a USB version.
The tabs are either all local or a mixture of both local and network drives.
The lock-up happens with either variation.
All tab locations exist.
After a lock-up/restart the Tab Group opens with no issues.
How do I create the Tab Groups?
I open all the required tabs (on both sides of a dual display) then right click on the "tab bar" and select "Groups/Save Both Sides..."
I appreciate there have been no reports on this and there's not a lot to go by but any pointers would be much appreciated.
Do any of the tabs point to unavailable network drives?
Next time this happens (and Opus is locked), please use Task Manager to make a dump file of the program (from the Details tab, locate dopus.exe and right-click). Then zip the dump file and send it to us (depending on how big it is, either email to crashdumps@gpsoft.com.au or via Dropbox or similar).
I've emailed a link to the crash dump. On this occasion Opus locked up for over 10 minutes but came back to life after AutoCAD crashed. Maybe this has something to do with it? I will report back if I discover anything else.
The dump shows several AutoCAD DLLs are loaded into the process, so they could be involved. That said, I did not see any of them executing code when the dump was created, so they may just be a bystander.
The Dropbox shell extension looks like it has a thread running which may be blocking other threads, while it waits for some kind of connection. I would try disabling that shell extension using ShellExView first, in case it is involved. But if it isn't, try doing the same with the AutoCAD extension(s) as well.
A Websense DLL, QIPCAP64.DLL, was also in the stack trace of one of the hung threads. It doesn't look likely to be involved, but could still potentially be, if the other leads don't go anywhere.
The Dropbox DLL looks like the most likely cause, in my opinion, since it is waiting on something particular (a connection to a named pipe), while the other hung threads look like they are waiting on a low-level OS lock, which is possibly being held by the Dropbox DLL and won't be released until the pipe connects. That is a lot of guesswork, though, and may turn out to be incorrect.
(Might be worth checking that Opus hasn't been run elevated, or that something else hasn't caused any of the Dropbox processes to be launched elevated, as that could stop the Dropbox shell extension inside of Opus from being able to talk to the Dropbox process, assuming the named pipe it is trying to connect to belongs to another process on the same machine.)