Regsvr32 (Microsoft Windows Register Server) is a system utility designed to register and unregister ActiveX controls, filter components (codecs), and DLL components on a Windows system by making changes to the registry.
DLL (Dynamic Link Library, Dynamic Link Library) is a dynamically linked set of subroutines (functions), logically combined into a single binary file, which can be dynamically loaded (used) repeatedly/simultaneously by various applications that require these functions for their functioning.
History of distributed code
Here, I think, it would be useful to get acquainted with the history of distributed code, which will give us an understanding of the reasons for the emergence and development of dynamic libraries. And this, in turn, will give an obvious idea of what functionality the regsvr32 tool has and what it is actually intended for.
Linear programming
At the dawn of the development of programming languages, when creating (developing) programs, the so-called linear approach was used, which consisted in the fact that the code was written/executed “top-down”, in a clear sequence from beginning to end. But as soon as a person learned to write code a little more complex than simply printing the phrase “Hello, World!”, he immediately faced several problems that showed that the approach has obvious disadvantages:
- the source code had to be copied from the old project to the new one;
- copying old code led to errors, confusion, inconsistencies, the need for correction and adjustment to the new project;
Procedures (functions)
There was an obvious problem of separation, as well as reuse of code. Therefore, as programming technologies developed, procedural (functional) programming appeared, which was based on the fact that areas of code were allocated into separate blocks called functions (procedures), which could be repeatedly accessed (called) from anywhere in the program. This significantly simplified the application architecture and solved the important problem of duplicate code, since now, instead of the program using repeated sections of code throughout the entire execution process, it is easier to place it in a separate procedure (function) and call it repeatedly [as needed]. However, this approach required improvement because:
- allowed the program code to be divided into logical parts only within one language development environment.
Overlays
Given the high cost of RAM and the absence of many operating systems of that time (MSDOS) of a mechanism for virtualizing the process address space (virtual memory), providing sufficient address space for applications, it became necessary to load code much larger in size into the limited space of [expensive] physical memory. application data. The consequence of all this was the division of the program code/data into separate modules, called overlays. This mechanism is not directly related to code sharing, however, we will mention it as a significant milestone in the development of code sharing mechanisms.
Interrupts
The first attempt to solve the problem of code distribution was the software interrupt mechanism, which made it possible to create (place in the BIOS microcode) and call services available to any operating systems and programs. The interrupt table included 255 vectors (addresses), each of which specified the procedure for servicing a specific interrupt. This service could be easily programmed by users, that is, any program could [re]assign one of the available software interrupts, thus providing a system-wide service. And despite all the positive aspects of this approach, it also had a number of serious disadvantages:
- Fixed number of services, limited by the size of the interrupt vector table (255);
- No exception handling.
- Lack of security system;
- Separate syntax, incompatibility with the syntax of high-level languages (the need to operate with low-level registers);
- Lack of control over data types and correctness;
Dynamic libraries
Further development of this concept (as well as the development of the OS) led to the emergence of dynamically loaded libraries (simply called dynamic libraries, DLLs). A distinctive feature was that the functionality of these libraries could be accessed from code in any languages and from any development tools [within the operating system]. The entire program interface (WinAPI) of the Mirosoft Windows operating systems is built on the mechanism of dynamic libraries, so any API, any service is one way or another based on DLL. A characteristic feature of a dynamic library is that it can be used by several applications at once, and the system ensures that only one instance of the dynamic library [code] is present in memory for all applications that contain references to the functions of this library. DLLs had a number of significant disadvantages:
- When loading a dynamic library [into the process address space], only its symbolic name was used, since there was no mechanism for stable identification of the necessary libraries, respectively:
- the loaded [third-party/wrong version] library could contain code that destroys the data structures and code of the calling application.
- a [third-party/wrong version] loaded library could use the host application's security context to gain access to resources that it would not normally have access to.
Component Object Model (COM)
The next stage in the development of the concept of shared code was the emergence of the component object model (COM, Component Object Model). COM provided the ability to separate code into separate, independent components. The mentioned components, unlike their previous counterparts, were no longer connected by file name, but using a special global identifier (GUID). GUID is nothing more than a 128-bit global identifier (GUID, Global Unique ID) that identifies a specific library class object. Each component was identified in the system by its own unique identifier, and the system stored a single database of information on components, which contained all the information: from the name of the file in which the component itself is located to network settings. The COM database is stored in the registry, in the HKEY_CLASSES_ROOT section:
- HKEY_CLASSES_ROOT\CLSID — GUID of component class identifiers;
- HKEY_CLASSES_ROOT\Interface — IID of interface identifiers (for components that implement them);
- HKEY_CLASSES_ROOT\TypeLib - Information about the files in which libraries are stored;
Moreover, HKEY_CLASSES_ROOT itself is a combination of the sections HKCU\Software\Classes (for the current user) and HKLM\Software\Classes (for the machine as a whole).
In order to somehow distinguish class identifiers from other [similar] system identifiers, in relation to COM these identifiers are called class identifiers, and the abbreviation CLSID is used for them.
An example of a CLSID value would be a string like {2DB47AE5-CF39-43C2-B4D6-0CD8D90946F4}. In a global sense, these unique numbers “do not repeat” and uniquely identify the components of the system, which tells us about the uniqueness of the library class object within the system. Subkeys in these registry branches can be:
1 2 3 4 | HKCR\CLSID\\LocalServer = <full path to 16-bit file> LocalServer32 = <full path to 32-bit file> InprocServer = <full path to 16-bit file> InprocServer32 = <full path to 32-bit file> |
That is, the (default) parameter of these keys contains the full path to the registered library. However, the component object model also had a number of problems:
- COM is based on dynamic libraries (the components are located in them). And as we remember, with DLL there was still a problem related to the coincidence of library file names;
- The COM database is located in the registry, and it was proposed to work with it directly, without any specialized API. Even though a database partition is publicly accessible, after prolonged use of the system it has traditionally become inconsistent (leading to many system errors).
Assembly
The next attempt to improve code distribution mechanisms was made during the development of the .NET Framework. During the development of the platform, a solution was proposed that is based on the so-called assemblies, which are the smallest building blocks of .NET, designed to provide secure code separation in .NET applications.
An assembly is a collection of types and resources grouped into one or more files to function together, forming a logical functional unit.
An assembly consists of: a manifest (describing the assembly), metadata (describing the types), compiled MSIL code of the assembly (.Net bytecode), resources (pictures, sounds, etc.). Because assemblies include content, version, and dependency information, the functionality of their associated applications is not dependent on external sources (such as the registry). Assemblies significantly reduce the risk of problems with DLLs and make applications more reliable and easier to deploy.
Step-by-Step Guide to Fix Regsvr32.exe Error on Windows
Photo Source Here are the solutions that you can implement to resolve the Regsvr32.exe error code on your system:
- If the error is caused by an invalid entry point, simply open an elevated Command Prompt. If the 32-bit DLL is in the %systemroot%System32 folder, move it to the %systemroot%SysWoW64 folder. After that, run the following command: %systemroot%SysWoW64regsvr32 <full path to DLL>. This will help resolve the Regsvr32.exe error.
- If the cause of the error is a virus infection, you need to run a powerful antivirus to detect and remove viruses from your system to resolve the Regsvr32.exe error on your system.
- However, if the causes for Regsvr32.exe are either active X controls or registry corruption, then you will need to scan your computer using various tools to resolve each issue individually.
This can take a long time, and too many software installations at once can also slow down your system's performance. This means that you will also have to compromise on the speed of your PC.
Repair Regsvr32.exe Error with full system care
To avoid all this hassle, fix the Regsvr32.exe error.
It is a feature-rich and innovative PC repair tool deployed with multiple utilities in one program including features like registry cleaner, antivirus and Active X controls error fixer. It also functions as a system optimizer.
This is a one stop solution for all errors related to your computer, including Regsvr32.dll error.
It is safe, effective and user-friendly. It is compatible with all versions of Windows including Vista, XP, Windows 7 and 8.
The built-in powerful antivirus scans the entire computer, detects and removes all malicious programs that could generate the Regsvr32.exe error message. This includes malware, adware, spyware and viruses.
When RAM becomes overloaded, it leads to corrupted libraries and corrupted registry. The registry cleaning utility repairs damaged DLL files and corrupted registry. It removes all unnecessary files cluttering up your RAM, including junk files, invalid registry entries, and temporary files.
Total System Care also has an Active X Control Scanning utility. This utility can be very useful if the Regsvr32.exe error is caused by problems related to Active X controls.
Click here to download Total System Care and solve Regsvr32.exe on your computer right now.
The meaning of registering libraries and controls
But let's return to our libraries.
For what reason, in order to use DLL functions in the system, they must be registered? Answer: so that the system can find them!!
It would seem, well, just place the DLL in the working directory of the application, and the problem of finding it is resolved. But libraries are not only local, some of them are used jointly by many applications, and this is precisely the situation for which everything was started!! I think it would be quite appropriate to make an analogy with the system path variable (%PATH%). As you remember, files that are located in the directories specified in the %PATH% variable can be launched from the command line without specifying the full path. If there are no directories in the %PATH% variable, the specified files will not be able to be launched from any location in the operating system; the command interpreter simply will not “find” them. By analogy, libraries that contain functions that are widely used by various programs must be “declared” in the system, otherwise programs will not be able to “find” them. It can be argued that when calling a function from an executable file image, the Windows loader (the manager responsible for allocating memory, connecting various functions from memory images, etc.) must know where the library containing the required function can be loaded from. If we rely on the history of the development of distributed code technology, we can conclude that regsvr32 provides registration of both classic DLLs and their advanced counterparts containing COM objects, since the utility no longer works with .NET assemblies. As for the issue of registration in the system in relation to a DLL library at a low level, it represents an algorithm of actions for modifying various registry sections and file system directories, the result of which is the “visibility” of the library by applications. If the library is “third-party” (not system), then registration of the library must be carried out at the installation stage of the application of which it is included and to serve the functions of which it is intended. In most cases, the library registration process itself is performed by calling external specialized system utilities, or a certain sequence of specialized Windows API functions.
Often there is no need to register DLLs yourself (manually); this is almost always done automatically when installing system/program components. The need for manual registration usually arises in the event of any errors in the system: problems installing/uninstalling programs, crashes, or in the case of independently developed DLLs that need to be tested.
We can consider a simple example where a program arbitrarily installed on the system uses a function from a library that is not “declared” in the system. In such a situation, the Windows loader, at the initial stage of initializing the process's virtual address space, imports all the libraries required by the program being loaded for execution. If one of the libraries listed in the import table of the executable image is missing, then the loader displays the following error message:
The error tells us that the cDSsvc.exe image loader could not find the MFC71.DLL library it needs to function. One of the ways to eliminate this class of errors is to reinstall the program, in a situation where the file of the required library is included in any distribution kit, since the library is installed automatically by the installation script. If the library is part of another package, for example Microsoft Visual C++ 2010 x64 Redistributable, then you need to reinstall it. If the described methods still fail to fix the error, then the Regsvr32 utility comes to our aid.
regsvr32.exe what is this process?
As mentioned above, this element is necessary to run the server, which registers dynamic libraries in DLL format that are copied to the system during the installation of various applications/games.
This is what it looks like in the Windows 10 task manager:
It is worth noting that the process is launched not always solely on the initiative of Windows (during the update), but also by third-party programs that need to copy the necessary DLL files to the System32 or SysWOW64 folders.
Immediately, there is no point in thinking about deleting regsvr32.exe to reduce resource consumption. Otherwise, the integrity of the OS will be compromised, which will entail critical changes, and may even require reinstallation.
[simplified] description of the library registration process
The regsvr32 utility, using the LoadLibrary system function, loads the library and, depending on the input parameters [command line], executes:
- looks for an entry point in the library and calls the DllRegisterServer or DllUnRegisterServer function of this library and looks at the returned result.
- looks for an entry point in the library and calls the DllInstall / DllUnInstall functions.
All this suggests that there are certain requirements for the structure of the DLL that you want to register with regsvr32. In order for a control element to be registered using regsvr32, the DLL must implement the DllRegisterServer, DllUnregisterServer functions, and, if it is necessary to perform specific actions, also the DllInstall, DllUnInstall functions. The DllRegisterServer / DllUnregisterServer functions contain the logic that actually registers the library with the system, adding the registry entries required for the control element. The DllInstall / DllUnInstall functions are used to perform additional actions that the DLL author plans to perform. So remember that:
Not all DLLs can be registered using regsvr32!
Let's see what happens when, for example, the DllRegisterServer function is not defined:
In this case, we see an error on the screen: “Module ????????.??? loaded but DllRegisterServer entry point not found." But let’s move on directly to the registration process itself.
New method
As we have already said, the DllRegisterServer() function is used to register a library. The function checks the 128-bit global identifier (GUID, Global Unique ID) of all COM/ActiveX objects found in the library and sequentially writes information about them to the registry. Here we see what is happening is not the registration of a library, but the registration of objects in libraries. As we said above, registering objects is necessary because programs do not work with the DLL/OCX/ACX files themselves, but with objects that represent a specific set of interfaces. As we already mentioned, for DLL registration purposes, the registry key HKEY_CLASSES_ROOT is used, which is a combination of keys:
- branch HKLM\SOFTWARE\Classes\CLSID when registering COM library objects for all system users;
- branch HKCU\SOFTWARE\Classes\CLSID when registering COM library objects only for the current user;
- branch HKLM\SOFTWARE\Wow6432Node\Classes\CLSID for registering 32-bit DLLs on 64-bit Windows operating systems;
Thus, we can conclude that the process of registering a library consists of informing the operating system that the implementation of the interfaces provided by an object with a certain identifier is located in the corresponding file.
If you need to change the location of the DLL on the system (for example, change the placement directory), you will need to re-register it.
Old method
In addition to the modern method of working with COM objects, the registry also contains the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs branch. I can assume that it refers to the outdated method of registering shared DLLs, based on counting the number of links to the library. It is probably left in place for compatibility purposes and is intended to register libraries that are an outdated kind of library consisting of a set of functions. This branch contains parameters of the REG_DWORD type, the names of which contain the full path to the shared libraries registered in the system (for example: C:\Windows\system32\VBAME.DLL). The value of the parameter can vary from 1 to 65535. The fact is that the value is the usage counter or, as it is also called, the number of links. This registration method was often used by non-MSI installers. Every time any such installer independently registers a library on the system that has already been registered by someone else (that is, is present in SharedDLLs), it increases the usage counter by 1, and when (for example, when deleting) the library is unregistered , then the counter is decreased by 1. Similar logic was implemented in the first versions of Windows to combat such a phenomenon as “DLL Hell”. The parameters of some libraries can be observed to have quite large values (4096), I believe that this is how system-critical libraries are marked, and the counter is artificially increased so that various user packages, when uninstalled, do not accidentally reduce the usage counter to 0 and turn off the DLL .
Fixing the problem
Try restarting your computer - this may be a one-time problem. Otherwise, follow the instructions below.
- Download and run the Process Explorer utility from the official website.
- In the list of active processes, find the one that is overloading the CPU (in the “CPU” column) and expand it. The process called by regsvr32.exe will be displayed. This will give you information about what started the registration server.
Next, correct the high load using one of the following methods:
- If you determine the program that caused regsvr32, restart or, as a last resort, reinstall it.
Advice! If you cannot identify the program, search the Internet for the name of the library on which the actions are performed and find out what it belongs to. - Sometimes the problem is installing pirated software. In this case, you need to use its licensed version, and also disable the antivirus, which may mistakenly consider the program to be malicious and block access to system libraries.
- It happens that the problem appears after updating Windows 10 and is caused by security software such as an antivirus or firewall. Uninstall it, restart your PC and install again.
- If the problem is with the device driver, try reinstalling it, ending the regsvr32.exe process first.
32-bit and 64-bit versions of regsvr32
Starting from Windows XP, depending on the bitness of the OS, the regsvr32.exe utility is located either only in the %SystemRoot%\System32 directory for 32-bit systems, or in the %SystemRoot%\System32 and %SystemRoot%\SysWOW64 folders for 64-bit systems ( there are two different versions of the program). It is a command line utility, that is, in other words, it works with the console and can be used in scripts.
At the moment, 64-bit versions of Windows have begun to be used more actively. If in 32-bit versions of Windows everything was quite transparent and there was only one version of the program, then in 64-bit versions of the OS there are two versions of the regsvr32 utility:
It turns out that in a 64-bit system, the developers retained the previous directory naming system, but placed “native” 64-bit applications there. This is explained by ensuring application compatibility and reducing the time spent translating code from the 32- to 64-bit version of Windows. Thus, in a 64-bit version of Windows, both 32-bit and 64-bit versions of programs can run, respectively, and both 32- and 64-bit DLLs can be used. When you run regsvr32 on a 64-bit OS to register a DLL, you are using the 64-bit version of the utility by default.
For 64-bit Windows operating systems, there is a golden rule: the System32 directory of the system is intended for native 64-bit applications, the SysWOW64 directory for 32-bit ones. A little unintuitive, but this is an established fact!! WOW64 (Windows on Windows64) is a 32-bit subsystem that runs in a 64-bit environment.
So if you need to register a 32-bit version of a DLL on a 64-bit OS and you get an error, you can do the following:
- Open a command prompt with administrator rights;
- If the 32-bit DLL required for registration is located in the %SystemRoot%\System32 directory, move it to the %SystemRoot%\SysWoW64 folder;
- Run the command: %SystemRoot%\SysWoW64\regsvr32 <full path to the DLL>
that is, for example: %SystemRoot%\SysWoW64\regsvr32 %SystemRoot%\SysWOW64\test.dll
If you are faced with the task of registering a 64-bit DLL in a 64-bit OS:
- Open a command prompt with administrator rights;
- If the 64-bit DLL required for registration is located in the %SystemRoot%\SysWOW64 directory, move it to the %SystemRoot%\System32 folder
- Run the command: %SystemRoot%\System32\regsvr32 <full path to the DLL>
that is, for example: %SystemRoot%\System32\regsvr32 %SystemRoot%\System32\test.dll
What is Microsoft Enrollment Server used for?
The registration server itself, regsvr32.exe, is a Windows system program that is used to register some DLL libraries (program components) in the system and remove them.
This system process can be launched not only by the operating system itself (for example, during updates), but also by third-party programs and their installers that need to install their own libraries to work.
You cannot remove regsvr32.exe (since it is a necessary Windows component), but you can figure out what caused the problem with the process and fix it.
Syntax regsvr32
As mentioned above, regsvr32 is a command line utility, so for practical use it can be launched from under the already familiar cmd, or used in scripts.
In most cases, registering a DLL requires elevated privileges, that is, local administrator rights.
The regsvr32.exe utility has the following command line parameters:
Regsvr32 [/u] [/s] [/n] [/i[:cmdline]]
A list of utility keys and a description of their actions are given in the following table:
Parameter | Description |
/u | Unregisters a DLL. You can only unregister DLLs; the command does not apply to controls or filters. |
/i | calls the DllInstall function, passing it an optional cmdline command line as a parameter; Calling DllInstall calls the standard registration functions DllRegisterServer/DllUnRegisterServer, but allows you to pass a string of parameters that can change the registration behavior, such as registering a DLL more than once. The /i switch, when used with the /u switch, causes DllUnInstall. |
/n | does not call DllRegisterServer, that is, only DllInstall is called; this can be used with the /i switch to pass additional parameters for registration. |
/s | "quiet" mode; messages are not displayed. |
In general, registering a DLL using regsvr32 can be done with the following command:
regsvr32.dll
For example:
regsvr32 "C:\Windows\System32\schmmgmt.dll"
I remind you, be careful with versions of the regsvr32 utility for Windows of different bit depth. In some cases, you have to specify the path to the utility when starting. Moreover, almost always, when the registered component lies outside the paths included in the %PATH% variable (for example, if it is not located in %SystemRoot%\System32), the path to the component must be specified! Example:
%SystemRoot%\System32\Regsvr32 %SystemRoot%\System32\macromed\Flash\Flash10a.ocx
*Compound file paths must be enclosed in quotes according to Windows command line syntax.
Checking library files
If the problem occurs after installing new programs, try uninstalling them, clearing the registry and checking the system component storage. Let's go in order and start with the correct removal of the program.
- Open Control Panel .
- Go to Programs and Features .
- Select the application that you suspect of causing harm (uTorrent is highlighted as an example only).
- Click " Delete ".
- Wait for the uninstallation to complete and close the Uninstall or Change Programs window.
On Windows 10, the same thing can be done through the “ Applications ” section in Settings . It will turn out even faster and more convenient.
The next step will be to clean the registry of traces left by the uninstalled program. I recommend doing this using the free CCleaner utility:
- Launch CCleaner.
- Open the Registry .
- Run a problem search.
- Correct all errors.
The list of errors will definitely contain a line with the library file. There is a possibility that after removing it, the problem with the broken DLL will be eliminated, and Regsvr32.exe will stop loading the processor due to the inability to complete its work.
We will not stop at clearing the registry of erroneous entries and will restore the system component store using the DISM utility. We won’t go into details, the main thing you need to know is that nothing bad will happen to the computer, and no files will be deleted.
- Launch Command Prompt with administrator rights.
- Run the command “ Dism.exe /online /cleanup-image /scanhealth ”.
This is interesting: How to enable ClearType fonts in Windows 10
If no errors are found, try another command - “ sfc /scannow ”. With its help you will check the integrity of Windows system files. If failures are detected, the utility will try to make corrections.