Windows User Account Control Killing Dll's

[John Stephen]

Here is a rhetorical question, mostly to invoke discussion.
I have a customer who has recently upgraded from Windows Server 2003 to Server 2012 R2. They have two servers, one the data server which holds our VFP app and a Terminal Server which acts as the host for thin clients. Users login through an RDP from their personal desktop, each user has a personal folder under Windows on the TS. Access to the data server is done through a mapped drive using some sort of IP address. The previous system was the same and worked perfectly for years.
As the new system came on stream users couldn't access the dll's which had been properly registered. Just to be sure we installed the dll's on both servers. The problem was intermittent, install and register the dll's and they would be accessible for half an hour or so, then the users would get 'Ole error code - access is denied' error. The dll files were still there, run the registration process again and it would be Ok for a bit longer. When I logged in as administrator everything was always fine. The owners of course were not prepared to give everyone administrator rights
At first we looked at the Anti Virus system but turning it off made no difference.
Finally the technician disabled the User Account Control and everything is fine now.

So was UAC un-registering the dll's ? Or changing their attributes ? It certainly looks like it

Is this another undocumented feature of Windows ? Like the one that disconnects mapped drives intermittantly that are idle for a while (Server 2016 with Windows 10 on a LAN)
Whatever it was created a world of pain with the technician blaming our app for the problem until the customer got mad with him.

 

[Olaf Doschke]

Where you find your answer depends on what you do.

On top of UAC there is
-file redirection aka VirtualStore (UAC related redirection)
-registry redirection aka Registry Virtualization (both UAC and 32bit/64bit related redirection)
-The 32bit subsystem SysWOW64.
-the need for manifests requiring elevation, when your EXE/DLLs should do something requiring administrator privileges.
-the newer Server OS you have the opportunistic locking (oplocks) problem of newer versions of SMB protocols.

For the reason that your users shouldn't need to be Admins and shouldn't need an elevated process, you should do all registering of COM Servers at a setup once for all. Forget self-registering via DLLRegisterServer, for example, or cmd batchfiles executing regsvr32, which are anther spawned process that's still not elevated, even if your EXE requires and gets elevation. That's another security mechanism since the introduction of UAC is admin account sessions don't cause elevated processes and even elevated processes don't spawn elevated child processes.

Instead of needing to write a setup for the registering, you can start the Command Prompt (cmd.exe) as Administrator and do your regsvr32 registrations from there. Just make sure the title bar tells you are running as Administrator and make sure you start the cmd.exe from SysWOW64 and not the 64bit cmd.exe, because your EXE needs 32bit DLLs, including your own 32bit COMServer DLLs to be registered in the 32bit registry and not in the virtualized regsitry.

Any manual regsvr32.dll use, even unelvated, will give you feedback of being successful. That's because of the redirection/virtualisation. Instead of being rejected from the protected registry you get keys in the virtual part, where they are not effective.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

By the way there also are advanced possibilities by the manifests, ie regfree COM usage.

Just not with DLLs, only with EXE, and I have no experience with remote COM Server, so if your major app.exe is using a COM Server made by you running remote from it on the server also providing the file share, then I don't see how regfree COM by manifests should work. In a manifest you can only tell Windows (Vista and higher clients) which OCX/COMServer your process uses and AFAIK you specify local files.

The manifest automatically embedded in VFP mentions the MS Common Controls you are getting with VFP and are allowed to redistribute, but really registering something still works and works under any other circumstances, too, ie woth older client OSes.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Gerrit Broekhuis]

Hi John,

So far I’ve mostly used a setup builder like InnoSetup to avoid these problems. So far I have not experienced any, and the installer takes care of the proper / elevated dll and ocx registring when required.

If you setup manually I suggest you follow Olaf’s suggestions.

Regards, Gerrit

 

[John Stephen]

There is no problem with the registering, nor have I had any problem with installations and self registering over 20 years and over 7000 distributed applications.
The whole point is that something is de-registering the dll's well after successful registration. In this case that process points to the UAC
Thank you for participating anyway.
Cheers
John

 

[Olaf Doschke]

ASI said, you THINK you have registered the DLLs. And you may be able to use COM servers for the session.

But to really register in the right registry branch (32bit nonvirtualized), you need to do the registering elevated. And your process isn't as long as you don't change your applications manifest to requitre elevated permissions. Even if you setup user accounts being administrators.

It's not the solution, because you don't want your application users to always need to be admins to be able to use an EXE requiring elevation, just because you need to use Selfregistering at the first start.

So forget doing it that way, it's game over, you have to do a setup or manually register elevated, and THEN normal users can use a normal application running at normal permissions and are capable to instanciate the COM Servers.

Yews, you did something for 20 years. But that doesn't work that way anymore.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

So why do they work when first registered and then change ?
Cheers
John

 

[Olaf Doschke]

I actually don't care. Inspect the registry yourself. Do so starting regedit as admin, as normal user, regedit from system32 and regedit from syswow64.

Look up the mechanisms I described. They are real, I'm not inventing them. And simply convince yourself when you once register the COMServers the right way they work.

This is the way since Visa, that was 2007. I don't know why it took you over 10 years to get to this point, but the solution I recommend will work if you simply stop refusing it.

You see it for yourself, they self-registering only works temporally.

Redirection works this way: You write to another branch than you think. If you request the key where you think they are, you also get back the values you stored. That's fine for any normal keys your app sets and wants to read back. But not for keys the system needs to know and use when you donÄt request the keys, but request the instantiation of a COM Server.

I don't really care what how exactly the Windows OLE subsystem finds the OLE Class registration in the redirected portion of the registry, but the reg keys never arrive in the place they should be.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

I am not refusing anything, just trying to understand it. I am trying to get my head around it but not very successfully at this point. As I see it you are saying that I must manually register all my dll's on every installation. But thanks for trying anyway, meantime the technician has disabled UAC.
Cheers, John

 

[Olaf Doschke]

No, I'm not saying you must register them manually, I said you can also create a setup, that's the usual way to automate this, isn't it?

Solving this by disabling UAC is the worst solution. Giving up security.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

Thanks but I would have no idea how to create a setup, I am only a lowly 4gl programmer

 

[Olaf Doschke]

Look, you don't need to in this case, you said "the echnician" (singular) disabled UAC. So this is a singel terminal server running for many users, isn't it? Then you can also do that step manually.

The bigger companies I work for have their own devops that are capable to assign software packages ti workstations via SCCM, all they need from a developer is a setup.exe, ideally an MSI package. VFP comes with Installshiled Express, there's a walkthrough and you can specify for a DLL you add to the setup files via a context menu, that the setup registers it. VFP also comes with the merge modules for VFP runtimes, C++runtime.

But for a single case you can still do the one regsvr32 call you need. The thing is if you write a cmd file you still also need to elevate its execution. running a cmd from the Administration command prompt works, but it's also a manual step to get there, you can specify a cmd to need admin elevation, but that's not something you can set to the cmd file once on your own development system and distribute as "file attribute", so the simplest solution for a single case to see it work is the manual registration and to solve that for all future installations the best way is to provide an MSI setup package.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[John Stephen]

In this case one server, but in others which are LANS I can have many workstations which require dll registeration. I use the installer pictured, perhaps you could comment on the setup and how I could use it. I don't have the full VFP package anymore, the original CD is stuffed and moving computers over the years has depleted the resources somewhat. TIA, John

 

[Olaf Doschke]

From your screenshot, I can only deduct you use "Clickteam Install Creator".

I am not eager to dig into that, but as registering is something you do per file, you'd rather find this as context menu option of a file within the files tab. I don't know, look into the manuals, ask in a Clickteam Install Creator forum.

Installshield also offers the option to autodetect whether files you add to the project have registerable COM servers. The main point is that a setup runs elevated and thus can do the correct registering, even using regsvr32. It seems if you want to run elevated you have to specify this here. That alone looks like this is rather a packager, something doing a selfextracting archive with additional capabilities.

Use Inno Setup instead, perhaps. See

http://doughennig.com/papers/Pub/Deploying.pdf

HEre page 15 has an example for how you specify a DLL to be registered:

Source: "{#AppFiles}COMServer.dll"; DestDir: "{pf}\My Application"; Flags: ignoreversion regserver

Inno just doesn't generate MSI, the preferred format, as I said, in software management via SCCM. Anyway, there are many tools.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[gjbbroekhuis]

Hi John

I already mentioned InnoSetup (it’s free...) for creating a true setup executable for either the first installation or an update.

Regards, Gerrit

 

[John Stephen]

Yeah thanks Gerrit, I took that on board

Cheers
John