Self Registering DLL's

Jay Schwegler
Jay Schwegler used Ask the Experts™
I have an application, which upon startup, registers a required DLL for integration with another product.

The main problem is that a standard windows user does NOT have the correct permissions to self register a DLL, so obviously the operation is failing under restricted accounts.

Even if I pre-register the DLL as an administrator, the DLL does not seem to be registered anymore when logging back on as a user, it seems to un-register itself. Is this behavior expected for self registering DLLs?

How can I get around this problem?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2012

>>Even if I pre-register the DLL as an administrator, [...] it seems to un-register itself.

No, the problem is that when registering such a DLL as an admin, the registry entries get security settings that make them unaccessible for 'normal'´users.

BTW, check whith the dependency walker ( *why* these DLLs cannot be registered - if it is an issue about another DLL being unaccessible or something else.
Essentially the program is doing a "regsvr32 dllname"

Is it even possible for ANY regular user to even register ANY dll, since it would require write access to the registry which regular user don't have?
Top Expert 2012

That's why I asked why the registration is failing - if you're only writing to HKEY_CLASSES_ROOT, this should not happen. BTW, RegMon ( helps detecting access rights problems
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

A non-admin user cannot write directly to HKEY_CLASSES_ROOT.  Many self-registering DLLs try to do this, and they will fail for non-admin users.  MFC DLLs generated with MSVC 6 have this problem.  A non-admin user can only write to HKEY_CURRENT_USER\SOFTWARE\Classes, which is that user's own private HKEY_CLASSES_ROOT.

As jkr said, you should use RegMon to see where the DLL is trying to write to.  If it's HKEY_CLASSES_ROOT and it's failing with permissions errors, you need to get the author of the DLL to make it fall back to writing to HKEY_CURRENT_USER\SOFTWARE\Classes if HKET_CLASSES_ROOT fails.

(I went though all this just last week with one of our MFC DLLs. 8-)
Top Expert 2012

>> A non-admin user cannot write directly to HKEY_CLASSES_ROOT

Sorry to disagree, but HKEY_CLASSES_ROOT is just a link to HKEY_CURRENT_USER\SOFTWARE\Classes, as HKEY_CURRENT_USER is a link to HKEY_USERS\[some user SID]
jkr: Clearly HKEY_CLASSES_ROOT is *not* just a link to HKEY_CURRENT_USER\SOFTWARE\Classes, otherwise a user would only see the registry entries that he himself had created.  It is an combination of HKCU\SOFTWARE\Classes and HKLM\SOFTWARE\Classes.

It's not difficult to verify that a non-admin user cannot write directly to HKCR.  In Windows XP, go Start / Control Panel / User Accounts / Create a new account / call it "nonadmin" / Next / select Limited / Create Account.  Log in as "nonadmin" / Start / Run / "regedit".  Open HKCR and try to create a key.  You can't.  Now try again in HKCU\SOFTWARE\Classes - success.  Go back to HKCR and you'll see the new key there.
Top Expert 2012

From 'Inside Windows 2000"

Table 5-2 Registry Root Keys

Root Key Abbreviation Description Link
HKEY_CURRENT_USER HKCU Points to the user profile of the currently logged-on user  Subkey under HKEY_USERS corresponding to currently logged-on user
HKEY_USERS HKU  Contains subkeys for all loaded user profiles  Not a link
HKEY_CLASSES_ROOT HKCR  Contains file association and COM registration information HKLM\SOFTWARE\ Classes
HKEY_LOCAL_MACHINE HKLM Placeholder— contains other keys  Not a link
HKEY_CURRENT_CONFIG HKCC Current hardware profile HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current
HKEY_PERFORMANCE_DATA HKPD  Performance counters Not a link

HKCR consists of two types of information: file extension associations and COM class registrations. A key exists for every registered filename extension. Most keys contain a REG_SZ value that points to another key in HKCR containing the association information for the class of files that extension represents. For example, HKCR\.xls would point to information on Microsoft Excel files in a key such as HKCU\Excel.Sheet.8. Other keys contain configuration details for COM objects registered on the system.

The data under HKEY_CLASSES_ROOT comes from two sources:

The per-user class registration data in HKCU\SOFTWARE\Classes (mapped to the file on hard disk \Documents and Settings\<username> \Local Settings\Application Data\Microsoft\Windows\Usrclass.dat)

Systemwide class registration data in HKLM\SOFTWARE\Classes

The addition of per-user class registration data is new to Windows 2000. This change was made to separate per-user registration data from systemwide state so that roaming profiles can contain these customizations. It also closes a security hole: in Microsoft Windows NT 4, a nonprivileged user could change or delete keys in HKEY_CLASSES_ROOT, thus affecting the operation of applications on the system. In Windows 2000, nonprivileged users and applications can read systemwide data but can modify only their private data.

jkr: Thanks for the official confirmation of what I said.

jschweg: Any luck with RegMon?  Is the DLL trying and failing to write to HKCR?
Thanks for all the replies, I appreciate it.

RichieHindle: I know for an absolute fact that it is attempting to write to CLASSES_ROOT, because if I give the users group full access to CLASSES_ROOT, the DLL actually registers just fine. Regmon also reveals this as well.

So what you guys are saying is that I need to register the DLL to HKEY_CURRENT_USER\SOFTWARE\Classes? Cool.

I didn't think the creator of the DLL had any control over where and how it gets registered, I thought regsvr32 took care of all of that. So what you are saying is that the developers can change this behavior?

Sorry, bear with me, I'm not a developer.
Yes, it's up to the author of the DLL where it registers - all regsvr32 does is call a function in the DLL to tell it to register itself.  What we did when we had this problem was try writing the registry keys to HKCR, and if that fails, write them to HKCU\SOFTWARE\Classes instead.

(If it's an MFC DLL then the exported function is written for you, so the developer might not even be aware of it.  It's called DllRegisterServer, and by default an MFC DLL will simply call MFC to get it to register.  The problem is that with MFC 6, MFC will only try to write to HKCR.  If this is the case with your DLL, the author will have to duplucate the MFC functionality, adding the ability to write to HKCU\SOFTWARE\Classes if HKCR fails.  This may well be irrelevant in your case, but it could be worth passing on to the developer, just in case he's not familiar with the problem.)
> Yes, it's up to the author of the DLL where it registers
True. But there exists an API that allows re-pointing of the hive constants HKCR etc. to alternate values.

Furthermode a registration tool has been developed that incorporates this API for you.
_ys_: Fantastic!  I wish I'd known about that last week, when I had to rewrite our DLL registration code.  8-)
Top Expert 2012

So, I am glad that it was *not* a permission problem that could have been spotted with RegMon...
I already knew it was a permissions problem as I mentioned in my first comment, what I needed was a workaround to sucessfully register the DLL without having to modify permissions.
Additional note: RegOverridePredefKey (the API that _ys_ mentions above) is only available on Windows 2000 and later.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial