I wanted to elevate a response to one of the comments on an earlier post to the status of a full post, so it’s hopefully a bit more discoverable.
The author writes:
“I would’t mind dismissing Yet Another Popup, if it would have the decency to pop up already. UAC takes for-freaking-ever to ask my permission to do something I just told the computer to do. If it happened right away, it would be no biggie, but I frequently have to wait 20, 30, 40 seconds (sometimes way, way longer–about 30 minutes for a game download and install once) before the UAC prompt on the secure desktop. This is why I want to turn the damn thing off–because of its horrible performance! And it’s all well and good to blame this on ill-behaved apps, but who owns UAC? That’s right, Windows. I suspect for most users UAC is just another reason why Vista comes across as one of the clunkiest Windows releases ever.”
And yes, Jason, you have a very fair point – that user experience sucks, and I hate user experiences that suck! Let’s discuss.
First, we need to determine where exactly the problem occurs, because there are two possibilities. The first is that we’re having trouble transitioning to the secure desktop. Given the current implementation, this is generally caused by limitations in the graphics card drivers to support this transition. If you end up staring at a black screen for a while, then this is likely the culprit. Unfortunately, there isn’t much to do about this. One option is to get a new graphics card. (Easier said than done, right?) The other is to turn off switching to the secure desktop for elevation prompts, which has a couple of issues. First, it’s somewhat less secure (a malicious application could disguise the dialog by painting something in front of it, and since the boundary of a window message is the desktop any potential loopholes could be exploited to auto-elevate – let’s just say we did the secure desktop thing on purpose). Second, we disable this via group policy, but home SKUs don’t have group policy editing included, which means you end up resorting to an obscure registry hack (also easier said than done, right?). So, I’m really kind of hoping you don’t fall into this bucket.
The far more common bucket would be the case where everyone would be impacted with a given exe – and there is something the developers could do about this (and you can too, if you throw a shim at it). So let’s discuss this one, and we will continue to try to push the software ecosystem in this direction to resolve it through policy rather than technology.
When we need to authorize a request for elevation, we look at the binary to see if it is signed. There is a difference in the UAC prompt if the application is signed – instead of being kind of orange and scary, it’s greyish and more neutral. But the fact that it’s signed means we have to verify the signature. And herein lies the problem.
Clearly signatures are a good thing, particularly for huge downloads from arbitrary sites. So we don’t discourage signing – quite the opposite! But say you have a 10GB setup.exe that gets prompted for elevation due to GenericInstaller (which tries to ferret out setups by looking for heuristic evidence). That means we have to touch the entire 10GB file to verify that the binary has not been modified since it was signed – and that’s a lot of disk I/O (and the reason you wait for the elevation prompt). If you are running such a huge file repeatedly, you can skip over the signature check by applying the NoSignatureCheck shim using Compatibility Administrator – this will eliminate your wait. But, if you’re only running it once, it may be worth it to you to actually perform the check.
What could the developer do? They could manifest the self-extracting setup.exe to request asInvoker. The unpacker could then launch a small application that does the setup, which is signed but small enough that the validation doesn’t take long. So, instead of waiting to validate the entire self-extracting package (when you may not even need all of it) you only wait to validate the actual setup, which clearly you’d want to manifest as requireAdministrator if you are doing a per-machine installation.
If you are noticing one particular source of exes that take a long time to pop up, my guess is they are elevating the outside package and doing a complete signature check over the entire setup package. Let us know if we need to evangelize to one particular group of folks. Is there any one source where you see this happening more frequently than other times? For this is an instance where we, as a platform, have made it possible to be either high performance or low performance. We rely on third party developers to take the high-performance path, but we don’t always reach everyone to tell them how. However, we can’t remove the low-performance path, so we have to continue to extend our outreach. Clearly, we still have work to do.
As for your 30-minute experience – we have no clue. We’d have to debug that one.