The first log looks like it might be related to building a list of special shell folders. We had a bug in the very first release version when a certain shell folder was present which caused a stack overflow, which can often look like a clean exit (i.e. no crash dialog). Luckily that time there was a crash dump saved and the customer was able to send it to us.
Are you sure there are no dumps in %TEMP%\DOpus.Minidumps ?
It may also be worth seeing whether any new software was installed that coincided with this problem starting - anything that adds a folder to the Explorer folder tree would be suspect.
We'll also add a bit more granular logging when initialising the shell folder list which hopefully will help.
There are minidumps, but they’re from last November and September-- long before any of these issues (and probably with DOpus 12?). Nothing being produced now, or even this year.
No software updates since DOpus 13 was working, but I am running Megasync.
Might be worth noting that I’m also running the DisplayFusion 11 beta, which was updated about a week before DOpus stopped working. To be safe, I booted with it disabled-- with no effect on DOpus hanging.
DOpus 13.3.4 exclusively hangs, does not crash. Appears to be a single-thread busyloop? No matter how many windows I try to open, the "extra” DOpus processes appear to time out and die (within 5-10s), leaving only the original thread running at 100% on one core/thread.
Looks like a smoking gun, one of the “Discover {UUIDs…}” is looping until the process is killed (this is prior to anything showing up in Task Manager, has to be killed from Resource Manager)
(also, all the Discover {} prior to BAD-UUID only appeared once, so the busyloop only occurs for the very last one listed)
Thanks, received it. Unfortunately the GUID in question doesn't appear in Google, so we have no way to know what it is.
Are you able to run regedit.exe? It should appear under HKEY_CLASSES_ROOT\CLSID\{....GUID....}. Usually nested underneath that key there'll be another one called LocalServer32 or InprocServer32 or similar, and the default value of that key should contain the DLL pathname.
In terms of getting you back up and running, you can try adding the GUID to Opus's block list:
Locate %ProgramData%\GPSoftware\Directory Opus\Global Data
Edit or create the file globalprefs.oxc
If file did not exist, create with this structure:
It’s a sync folder from Megasync (that particular one hasn’t been touched in years, either). I’ll try blacklisting it tomorrow and get back to you. In the meantime, here’s a reg export of the looping entry (partly redacted), hopefully this can help on your end.
Curiously, some of the other GUIDs are also Megasync targets, and none of them caused the looping issue for some reason.
“…” denotes a removed hex string (the decoded text string is pasted below)
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}]
@="SYNC NAME WAS HERE"
"System.IsPinnedToNameSpaceTree"=dword:00000001
"SortOrderIndex"=dword:00000042
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}\DefaultIcon]
@=hex(2):...,00
# "C:\ProgramData\MEGAsync\MEGAsync.exe"
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}\InProcServer32]
@=hex(2):...,00
# "%systemroot%\system32\shell32.dll"
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}\Instance]
"CLSID"="{OTHER GUID REDACTED (different from main GUID)}"
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}\Instance\InitPropertyBag]
"Attributes"=dword:00000010
"TargetFolderPath"=hex(2):...,00
# "D:\path\to\megasync\folder"
[HKEY_CLASSES_ROOT\CLSID\{MAIN_GUID_REDACTED}\ShellFolder]
"FolderValueFlags"=dword:00000028
"Attributes"=dword:f080004d
Just two ideas run a system check and check disk to see if nothing on your system is corrupt.
Secondly unplug any external hard drives or usb devices except mouse or keyboard. Then if that does not work unplug keyboard use mouse then if that does not work unplug mouse and just use keyboard to rule out a defective usb.
I would aslo if that fails use revo unistaller to uninstall directory opus 12 and 13 in case that is the problem.
Please don’t. It’s more likely to cause problems than solve them.
The issue is with a particular cloud storage software, and the changes in the new beta will hopefully fix it, or provide more diagnostics about where the problem is to make further changes.
Dism and sfc commands can work to fix a corrupt component store. The combase.dll mentioned previously in one of the logs is part of the component store. Usually, problems with Apps not starting are not fixed that simply. It’s always worth trying though.
I’ve used Megasync with Opus and never had a problem. Which version of Megasync are you using?
I tried out 13.3.5, but I’m afraid that didn’t fix it-- while it looks like some of the early startup stage messages were removed, DOpus still loops+hangs on the bad GUID (same one as yesterday), see below:
I’ve kept the bad (corrupted? It still functions as a sync, though, and there are no FS/disc errors…) Sync Folder, so I can give it another test or two if you guys need.
We've got one more version for you to try before I think we're out of ideas. Would you mind giving this version a try and see if there's any difference?
If its running on other peoples PC's then could it be as simple as a microsoft visual c++ corruption or something like that. As I don't know exactly what windows dll directory opus use.
It looks like you have a corruption in one of your system files that Opus uses. I would suggest running a system scan and check disk to rule theses out. As it is strange your getting this problem and others aren't.
May I ask what the underlying cause was? That is, if it’s an underlying issue with Megasync, should I report it to them?
Anyway, I really appreciate how much you guys worked with me on this. I’d been recommending Directory Opus to my coworkers, but after a few days fumbling around without tabs/filters/scripting, I realized just how much time is getting wasted in my department as a whole-- can’t promise anything, but I’ll let management know how much time we could be saving if my coworkers had your software, too.
We're glad it's fixed! Thank you for your help and patience tracking it down.
No need to report the issue to Megasync; it was entirely on our side. There was a bug in some code involved in enumerating cloud sync tools/folders, but it was only triggered in a rare situation that wouldn't apply on most machines. Once it was narrowed down with your help, the bug was obvious and easy to fix.