Rubberduck doesn't load v2.2.0.3086

[A9G-Data-Droid]

After updating to the V2.2.0 release Rubberduck no longer loads at all.

I can see that the new version is installed in Add\Remove programs.

No Add-Ins appear in my VBE Add-In Manager.

There is no log because it never gets that far. The installer appears to be silently failing to do something.
(Where would I find the installer log?)

[bclothier]

IIRC, look in the %temp% there'll be a installer log there.

[bclothier]

BTW - which did you use, per-user or per-machine?

[A9G-Data-Droid]

The only option I have is "Anyone who uses this computer"

[A9G-Data-Droid]

There is nothing of value in the installer log.

[bclothier]

Ah then you installed per-machine. Therefore VBE registration cannot be done automatically in this case.

Can you see if you can locate Rubberduck in the start menu, and choose Register VBE Registration from there? That might get you going.

[A9G-Data-Droid]

That works, Rubberduck is loading now. That seemed automatic to me... Why wouldn't the installer call that script at the end?

[Vogel612]

because the installer runs as admin, which means the script is spawned as admin, which results in the same problem as before. At least that'd make sense, I don't know if we tried that.

[bclothier]

Yes we did - there is a bug where when we write to HKCU as an admin, it causes an error. The registration has to be done without the admin elevation to work correctly. As @Vogel612 notes, once we are elevated, we can't de-elevate to write to the HKCU without incurring the bug.

[A9G-Data-Droid]

Ok, I would recommend running the installer as a normal process, which spawns an elevated process for the parts that need elevation. Then when those parts are done and execution gets back to the normal process it can fire off the script in the de-elevated context.

[bclothier]

It does that exactly already.

The process you went through is because the installer was already launched as an admin, and as noted, cannot be "de-elevated". If it's ran without the "Run As Administrator", it will do exactly what you just described.

[A9G-Data-Droid]

Interesting. Can you spawn a new shell process that is forced to run in the "de-elevated" context like this:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" Rubberduck.RegisterAddIn.bat"

[bclothier]

TIL I didn't know about that. Thank you for sharing.

I might be able to use that from the installer. I will test and see what I can do about that.

[A9G-Data-Droid]

I may have led you astray. If that doesn't work it's because the invoker still has a high integrity level. The solution might be more complex than I was hoping.

Take a look at this:
https://www.codeproject.com/Articles/18946/High-elevation-can-be-bad-for-your-application-How

And this:
https://archive.codeplex.com/?p=uachelpers

[bclothier]

By default, the installer requires the lowest privilege level. Reference

However, what this means is that it depends on the user who invokes the installer. Assuming they simply open the installer without choosing the Run As Administrator, it should not run elevated and that is the typical in most cases, even if the user is the administrator.

But, on systems where UAC is disabled or the user is permanently elevated or something similar, then the installer will run elevated even without having chosen the Run As Adminstrator. In this case the installer will offer the per-machine as only option.

I will review the articles.