Is this with an unusual setup of UNC paths pointing to junctions pointing to mount points pointing to junctions pointing to... etc.? I seem to remember someone here had something like that but not the exact details. That kind of thing will definitely confuse change notification at some point, as the redirects may not be followed to an infinite depth, and may slow things down as well.
(Basic junctions and mount points should work, of course.)
Should I still be anticipating a custom debug build for this issue? I haven't yet heard anything that explains the reason this is happening for me with Opus 12.
The plan is to make one, yes. It will take a little while.
ok, great. thanks. I'll do my best to hang on with Opus 12 until then.
In the event I end up needing to revert back to Opus 11 (due to a user revolt, basically) is there anything special that needs to be done or do I simply uninstall Opus 12 and reinstall Opus 11.
Please understand I have 30+ people using this particular installation of Opus and they are NOT Opus experts. If their Opus profiles will be damaged by a downgrade I need to know that and what I can do to mitigate the problem. I can't find out after the downgrade that I have 30 people who now have the default Opus configuration rather than their normal carefully constructed one.
I do have Zips of their Opus 11 ...\Roaming\GPSoftware\Directory Opus and ...\Local\GPSoftware\Directory Opus folders. I can also have them create a native Opus backup before the downgrade to Opus 11.
Thanks,
Jason
I just observed this error for the second time since Opus 12 was installed. Perhaps it's related to our problem?
Ya, sorry...That would have been a good idea but I was in a rush at the time and didn't think to create one. I'll do that if it happens again. Sorry.
Did you read that in a rush too? Your answer does not fit the question. He asked if a dump was created automatically (you have to check the dump folder), not if you manually created one (which you say you did not).
If yes, don't worry, happens, but go find that dump.
Thanks for the pointer
I don't see that it's obvious from his actual text that he was asking about an automated dump having been made. However, I do see that the page he linked to mentions an automated dump being made and one was in fact made. I've emailed it to crashdumps@gpsoft.com.au
Thanks, again
I think I have some more information about this problem, in case it helps.
We have a programming environment that uses DDE to talk to MS Excel (it reads/writes data to/from Excel files). We're also having a problem with that which started the same day I upgraded to Opus 12.
It appears that whenever Opus is running AND is currently exhibiting the intermittent File List update issue the DDE communication between our programming environment and Excel is VERY slow (minutes compared to the usual seconds). During this period of delay, if Opus 12 is closed then the DDE communication seems to recover. Conversely, when Opus 12 is running and isn't currently experiencing the File List update problem the DDE communication seems to be normal.
I don't know what's really involved behind the scenes when using DDE to talk to Excel but I've seen indications that COM objects are part of it.
I don't know if that helps point to a particular direction but I thought I should mention it, just in case it's helpful.
Jason
Hmm, interesting. If you're able to spend some time testing it, one thing you could try is to run Opus elevated (shut it down completely, then start it using Run As Administrator - it should show ADMINISTRATOR in the title bar to confirm).
(If Excel or something else is broadcasting random messages around maybe Opus is misinterpreting them - running it elevated will stop non-elevated processes from sending messages to it).
I'll give it a try tonight. If DDE is somehow related to this then it would be consistent with the intermittent nature of the Opus problem; we periodically use DDE (quite often but not continuously).
That crash looks like a known bug in Windows 7, which also affects Explorer:
Microsoft have a hotfix here:
I posted this as a reply to the wrong message, sorry. Re-posting it now
Thanks, so I take it that crash doesn’t seem to be related to our auto update issue.
Regarding the request to see if running Opus as an admin seems to help. Recall that this is a Windows Server 2008 R2 application server on which many other people are also running Opus. Everything I’ve described so far happened to me when I’m logged on to the server with admin credentials already. When I select to run Opus ‘as an administrator’ it looks exactly the same as when I run it normally (there’s no ‘ADMINISTRATOR’ in the title bar). Opus.exe is nearly always running under some other user’s credentials at the same time. Is that a problem for what you were asking me to check?
It's possible the crash is tied in to the other problem, but also possible it's unrelated. Installing the Windows hotfix for it makes sense either way, but I wouldn't bet on it solving both problems, unless we're really lucky.
It sounds like UAC is not enabled on the server, which means we can't use it to test the theory that something is confusing Opus by sending rogue window messages to it.
I will see if I can get the version with extra debugging made today, as that seems the best bet for working out what is happening at the moment.
Yes, UAC is disabled on the server. I disabled it because was interfering with map 'app' in Outlook 2013, as I recall. In any case, it is off intentionally.
Thanks for working on a debug version of Opus to try to find the source of this issue.
Jason
The special debug version is now ready. I've sent a private message with the details to jproos (and will forward to tbone as well, in case it helps with his similar issue).
Many thanks for your time and help diagnosing this problem!
I expect to be deploying the custom debug build tonight and hopefully generating useful debug information so I can reinstall the official 12.6 build.
With my luck, this version will not exhibit the problem but will be annoyingly slow due to all the debug activity.
I think yes, folder updates for me do not work whenever the %G placeholder in the titlebar resolves to {xxxxx-…-yyyy} volume ids instead of the actual UNC path the folder is on
This doesn't seem to be happening for me.
My users didn't all cooperate last night so I had to reschedule the install of the custom build for tonight. I've installed it and generated a debug log showing some activity that didn't appear in the Opus file list.
I emailed the log to the crashdumps email address.
Hopefully the log file sheds some light on the situation.
Jason
