Occasionally Opus seems not to recognize admin mode. My button for "set admin=toggle" will be grayed-out, and any button or context menu item with the @admin command will not function. Completely closing Opus will not clear the problem, but a reboot or logout usually will. I running Windows 7 x64 and Opus 9.53. UAC is turned on (set to do not dim desktop), and my user account is an administrator level account. I can't trace it to either a 3rd-party app or to running a particular Opus command.
That happens if Opus is running as administrator (i.e. dopus.exe itself was launched elevated, so it's already elevated and cannot switch to admin mode) or if UAC is off.
See this FAQ for things to check to ensure Opus is run normally, and also make sure you do not launch Opus from something else which is elevated (since apps you launch inherit the context of what you launch them from, in general):
Neither dopus or dopusrt are set to run as administrator. Opus is set to run at startup and I've haven't changed any settings. I used autoruns to insure that the startup items are in their normal places and that the shortcuts were not set to run as administrator. I also checked dopusx64. The only possibly different item I have in startup is a scheduled task for Search Everything to circumvent the admin prompt.
Could that admin Everything task be launching Opus at times?
Next time it happens, run Process Explorer as administrator and add the Integrity column. Both dopus.exe and dopusrt.exe should have Medium integrity, not High or System.
I thought you had found the issue with Search Everything, but it uses explorer for open in folder by default. I'll check process monitor next time it happens. Thanks for the help!
This is still happening to me. Process monitor shows dopus, dopusrt and dopusx64 all running a medium integrity.
Process Explorer displays processes in a tree that indicates the 'launching heirarchy' (for want of a better term) - so does this indicate which process was responsible for launching Opus?
Dopusx64.exe is under svchost. Dopus and dopusrt are under explorer.exe. The svchost process is C:\Windows\system32\svchost.exe -k DcomLaunch and has system level integrity--is this normal?
It's normal for svchost.exe -k DcomLaunch to be at the system integrity level. (Dopusx64.exe should still be at medium level, though.)
Another thing which might cause Opus's Admin buttons to be disabled is if Opus is being run in XP (or earlier) compatibility mode, so it looks to Opus like it is running on XP (or earlier) and not Vista or Win7. (To check that, go to the Compatibility tab shown at the bottom of the FAQ and make sure all the other checkboxes are also off.)
If you go to C:\Program Files and create a new folder, does Opus successfully trigger a UAC prompt? Or does it succeed without prompt, or simply fail?
Have you tried reinstalling Opus? Just install it over the top of itself in case re-registering its components helps. (Don't uninstall first as it will erase your config; or if you do want to uninstall, do a config backup first.)
Solved thanks to Leo.
Process Monitor shows Opus looking for C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Hagel Technologies\DU Meter\DUMeter.sqb-journal. The local profile normally shows access denied.
Dumeter is a fairly common bandwidth metering program developed by Hagel technologies. It runs a service. When I stopped the service and reopened Opus my set admin=toogle,3 button was again functional.
Leo pointed me in the right direction when he asked me to try creating a folder under c:\program files. In Opus I got an "access is denied (5). Explorer would give the UAC prompt instead. I could delete the directory in both Opus and Explorer--both gave the UAC prompt. Then I traced the activity when trying to create a folder in Opus. I received an "invalid device request" (fsctl_lmr_query_debug_info) from the root of C down to the path of Dumeter.sqb-journal. That's when I stopped the dumeter service and discovered that was the issue. The weird thing is i restarted my PC with the service re-enabled and Opus functioned normally--but the problem has always been intermittent. But stopping the dumeter service is the only time it has ever been "fixed" without several logouts or restarts. The question is why Opus is trying to write to this file when UAC should be launched or why Opus usually went into "admin" mode. I'm also sending this to Hagels tech support. This fix "so far" has been to grant the admin group rights to the local profile folder.
Thanks to you both for pointing me in the right direction.