对于开启了UAC保护的Windows系统，一种常见的绕过UAC保护的方法就是：
很多应用软件在安装结束前通常都会给出一个选项（默认选中），让你可以方便的在安装完成后直接启动应用。
安装程序作为一类特殊的程序，一般都会要求用户赋予其管理员权限以完成正常的安装动作。这样其启动的应用软件自身作为安装程序的一个子进程启动，便会继承其父进程的全部既得权限。
这样启动的应用程序可以利用管理员权限完成一些初始化工作。
这个方法适用于：比较方便的自注册，但外部完成注册则较麻烦或者冗余
- COM类插件：通过宿主应用注册比较简单，但通过写注册表，则相对麻烦。
这些内容源于一片文章——《当心应用软件借安装程序绕过UAC》，但换个角度思考问题也许会更好
Q:
Windows 7, C++, VS2008 I have a COM DLL that needs to be registered using "runas administrator" (it is a legacy app that writes to the registry) The DLL is used by a reports app which instantiates it using CoCreateInstance. This failed unless I also ran the reports app as administrator; until I changed the linker setting from /MANIFESTUAC to /MANIFESTUAC:NO
Can anyone tell me why this works? Does it mean that I can write apps that bypass the UAC using this setting?
A:
If your installer/registerer app has a manifest, and it says "don't run elevated", when you try to write to HKLM it fails. If you have a manifest and it says "run elevated", when you try to write to HKLM it succeeds. If you have no manifest (which you request with /MANIFESTUAC:NO), when you try to write to HKLM it writes to a virtualized location instead.
When you run the reports app, a similar triple applies although it it can read HKLM. Therefore if the reports app has a manifest, whether elevated or not, it reads HKLM. Without a manifest it reads the virtualized location. This is why you have success when both apps have a manifest or don't have a manifest.
It would probably be preferably to have your installer app with a manifest that requests elevation, and your reports app have a manifest that does not request elevation. That way all your apps are telling the truth and everything works. Plus you know why it's happening.