Self Registering DLL's
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?
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?
ASKER
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?
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?
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 (http://www.sysinternals.com/ntw2k/source/regmon.shtml) helps detecting access rights problems
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
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
(I went though all this just last week with one of our MFC DLLs. 8-)
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
(I went though all this just last week with one of our MFC DLLs. 8-)
>> A non-admin user cannot write directly to HKEY_CLASSES_ROOT
>> HKEY_CURRENT_USER\SOFTWARE
Sorry to disagree, but HKEY_CLASSES_ROOT is just a link to HKEY_CURRENT_USER\SOFTWARE
>> HKEY_CURRENT_USER\SOFTWARE
Sorry to disagree, but HKEY_CLASSES_ROOT is just a link to HKEY_CURRENT_USER\SOFTWARE
jkr: Clearly HKEY_CLASSES_ROOT is *not* just a link to HKEY_CURRENT_USER\SOFTWARE
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.
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.
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\CurrentControl
HKEY_PERFORMANCE_DATA HKPD Performance counters Not a link
HKEY_CLASSES_ROOT
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\Usr
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.
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\CurrentControl
HKEY_PERFORMANCE_DATA HKPD Performance counters Not a link
HKEY_CLASSES_ROOT
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\Usr
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?
jschweg: Any luck with RegMon? Is the DLL trying and failing to write to HKCR?
ASKER
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
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.
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
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
_ys_: Fantastic! I wish I'd known about that last week, when I had to rewrite our DLL registration code. 8-)
So, I am glad that it was *not* a permission problem that could have been spotted with RegMon...
ASKER
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.
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 (www.dependencywalker.com) *why* these DLLs cannot be registered - if it is an issue about another DLL being unaccessible or something else.