I don't know what's going on with DOF + Admin mode, but of course my baseline advice is always the same regarding Admin mode: Just Don't Do It. If you can focus first on getting rid of all of those Admin mode processes, things will work much better across the board.
> padder must be run as admin, else no keypresses in PinUpMenu (strange?!)
It's actually not strange. It's an intentional security feature in Windows, and it's just the sort of reason you should stop running everything in Admin mode. You don't get key presses because Windows by design sets up firewalls between Admin mode processes and everything else. One of those firewalls is that non-elevated processes can't intercept the keyboard when an elevated process has focus, because Windows doesn't want key loggers to be able to grab system passwords and other potentially sensitive keyboard input.
Actually, you *always* have to run RegisterComObject in Admin mode, because it updates protected system keys.
I think whoever came up with this advice must be imagining that running RegisterComObject in Admin mode somehow sprinkles magic Admin Mode Dust over the keys it updates. It doesn't. Running the registration in Admin mode simply allows the registration to happen at all.
Here's a wild guess:
Are the people who are having the DOF + Admin mode problem running with UAC turned off?
If so, that might be the whole issue. Turning off UAC prevents Windows from being able to elevate processes in certain cases. You might be *thinking* that you're running RegisterComObject in Admin mode, but not *actually* running in Admin mode, because of the absence of UAC. Everyone thinks that turning off UAC just shuts off some prompts, but it actually shuts down the whole system service that allows the desktop shell to elevate selected processes.