7

To register a DLL file on a windows server using regsvr32, do you first need to move the file to your system32 folder or is that actually done automatically once you call the regsvr32 command?

If I just drop a dll file on my desktop and register it there, can I just delete it after registration? What would happen after removing it?

In other words, how does the regsvr actually really work?

4
  • 1
    I am wondering what is actually provoking the question. Feb 28, 2017 at 18:31
  • @Bill_Stewart good question. My answer has been updated, and it's bordering on a StackOverflow caliber description, but I'm a developer in private cloud deployment, rather than an IT specialist. Feb 28, 2017 at 23:33
  • The question seems to reveal some misunderstandings. Hence my comment. Mar 1, 2017 at 4:09
  • @Bill_Stewart Last week I had a collegue on the phone who asked me about an error message. It was caused due to a missing dll file. So, I sent him the file and asked him to register it. So what did he do? - he just put it in c:\temp and registered it there. (He later explained to me that he didn't have the windows privileges to register it from his system32 folder). - It did solve his problem, but I had a bad feeling about this. Unfortunately, I didn't have sufficient technical knowledge to prove it. Thanks to the answers below, I finally understand it, now. Maybe even enough to correct it.
    – bvdb
    Mar 4, 2017 at 7:27

2 Answers 2

5

In addition to @Matthew Wetmore's correct answer, the usual thing that happens, is that it registers all COM components in that dll.

Specifically it creates two keys (+subkeys) in the Windows registry.

E.g. consider a dll: dao360.dll, which has multiple COM objects inside it. For each the first key is something like:

HKLM\SOFTWARE\Classes\DAO.TableDef.36

for the DAO Table Defintion object, the name of the Key is the ProgID of the COM object that programmers would refer to in their code.

Under the key is usually a single key with a default value:

HKLM\SOFTWARE\Classes\DAO.TableDef.36\CLSID

in this case:

{00000103-0000-0010-8000-00AA006D2EA4}

this is the Class ID or CLSID for the COM object, it tells us where the second key is located:

HKLM\SOFTWARE\Classes\CLSID{00000103-0000-0010-8000-00AA006D2EA4}

This key with its subkeys and values has additional information about the COM object.

One value to notice is the default value under:

HKLM\SOFTWARE\Classes\Wow6432Node\CLSID{00000103-0000-0010-8000-00AA006D2EA4}\InprocServer32

it has the file path of the exe/dll that hosts the COM object, in our example:

%CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll

This is the correct file path when regsvr32.exe was used to register this COM object. If you move the file manually, the COM object will no longer work because this registry value now references a missing file.

So before using regsvr32.exe on a DLL, move it to its final location and don't move the DLL after registering it.

1
  • 1
    You're right that it's usually the case (+1), though there's nothing requiring it to do that, or prevents it from doing something else entirely. You can create an appropriately named interface that does completely arbitrary things. I've seen so called "fixit" sites that encourage downloading a replacement DLL and registering it to solve a common error. There's very little difference here from downloading an .EXE and running it - it can do whatever it wants. Predictably this doesn't always end well... Mar 1, 2017 at 7:35
10

RegSvr32 calls an exported method DllRegisterServer in the DLL. What specifically happens next is up to the implementation. Often registry keys for COM are written based on the file location. The registration should not, generally, be considered an installer that does much beyond that.

Unless there is something specific to the app, it can be registered from anywhere, but you shouldn't move/remove it after that. SysInternal's SysMon can watch file and registry access when you call the registration if you really want to see the details - though nothing prevents the code from doing either nothing or really anything code can do like access the internet, write or remove other files, et cetera. Like any executable, only register code you trust.

There is also DllInstall that can be called with regsvr32 /i which is meant to be an installer according to the regsvr32 documentation:

Regsvr32
This command-line tool registers .dll files as command components in the registry.
Syntax
regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname
Parameters
/u : Unregisters server.
/s : Specifies regsvr32 to run silently and to not display any message boxes.
/n : Specifies not to call DllRegisterServer. You must use this option with /i.
/i :cmdline : Calls DllInstall passing it an optional [cmdline]. When used with /u, it calls dll uninstall.
dllname : Specifies the name of the dll file that will be registered.
/? : Displays help at the command prompt.

There is also DllUnregisterServer, but from practical experience implementations of this are usually of lower quality than the registration.

One of the goals of the Windows Installer (MSI) was to decouple installation from code like this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .