In the previous article, we created a test application to test our COM component. When we rant our test application, it was displaying a “Class not registered” error message.
Before re-looking into our component and test application code; let’s understand in what scenarios this “Class not registered” error message occurred.
One scenario is, unable to find the mapping DLL for the given CLSID which causes a “Class not registered” error message. We have discussed in our previous articles that, CLSID is used to locate the component through the Windows registry. It seems our test application is unable to locate the DLL through CLSID.
We need to re-check the registry entries for our COM component. Let’s open the “HelloComponent.reg” file that we have created in our previous articles. The content of the file looks like below:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{23893EE4-8514-4BD6-8830-A7EBDDF5C944}]
@="HelloComponent"
[HKEY_CLASSES_ROOT\CLSID\{23893EE4-8514-4BD6-8830-A7EBDDF5C944}\InprocServer32]
@="c:\\HelloComponent\\HelloComponent.dll"There is a problem here. If we run our application on 32-bit systems, it will work fine. But if we run it on 64-bit OS it will not work. Because on 64-bit systems, we need to place our CLSID into different locations. So, now create another .reg file and name it as “HelloComponent6432.reg”. Place the below registry entries into the file:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{23893EE4-8514-4BD6-8830-A7EBDDF5C944}]
@="HelloComponent"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{23893EE4-8514-4BD6-8830-A7EBDDF5C944}\InprocServer32]
@=c:\HelloComponent\HelloComponent.dllType HelloComponent6432.reg at the command prompt. So, these entries will be added to the registry. Before updating the registry; it is always a good idea to take a copy of your Windows registry. If anything went wrong, the backup will be useful to restore the Windows registry.
Now run our test application “TestApp.exe”. The test application is throwing an error “Error in the DLL”. It seems there is a problem with the DLL that we have created.
Let’s open our DLL file into Microsoft’s Dependency Walker Tool. This tool is useful to display all the dependent DLLs and the DLL details like exported functions etc., You can download this tool from Microsoft’s website. Once we open our “HelloComponent.dll” in the Dependency Walker tool, it will show the DLL entries like this:
Observe that none of the functions are exported from our “HelloComponent.dll”. All the functions defined in our DLL became private and these functions can be accessible within the DLL only. We should export some functions from our DLL. Otherwise, other modules can’t communicate with our DLL.
But here is the question; what functions do we need to export from our DLL? We need to export DllGetClassObject and DllCanUnloadNow functions. Because the COM library uses these functions to create an instance of the COM component and release the DLL from memory.
Now it’s time to export the functions from “HelloComponent.dll”. To export the functions, we do not need to modify our “HelloComponent.dll”. Instead of modifying our DLL code, we can put all our exported functions in a .def file and re-generate the “HelloComponent.dll” including the .def file.
Create the “HelloComponent.def” file and add the following lines to it.
; HelloComponent.def : Export module functions. LIBRARY "HelloComponent.dll" EXPORTS DllGetClassObject PRIVATE DllCanUnloadNow PRIVATE
Now re-generate our “HelloComponent.dll”. Make sure that you use the .def file while generating the DLL. Below is the command:
cl /LD /EHsc HelloComponent.cpp /link comsuppw.lib /def:HelloComponent.def
The above command generates “HelloComponent.dll” with exported functions information. Let’s open this new DLL in Microsoft’s Dependency Walker Tool. It looks like this:
Now our DLL is ready to call from other modules.
Let’s try running our test application. Our test application will pick the new DLL to test whether the COM component is working fine or not.
After running our test application, from the command prompt; this time it is showing “No such interface supported”. This time it is showing a different error, other than the “Error in the DLL” error. It seems the issue “Error in the DLL” was resolved; we need to look at this new error “No such interface supported”.
We will check this in our next article.
**