When I try to register a Visual FoxPro DLL via an administrator command prompt:
C:\Windows\SysWOW64>regsvr32 C:\_temp\my.dll
on machines that are not mine I get the following error:
The module "c:\_temp\my.DLL" was loaded but the call to
DllRegisterServer failed with error code 0x80004005.
For more information about this problem, search online using the error
code as a search term.
I am able to register it on mine. How do I get more info as to why it is failing?
Can I use my machine where it does register to back into why it doesn't register on other machines?
I've manually copied MSVCR70.dll into the %systemroot%\SysWOW64 directory on the machine that it won't register on.
I've reviewed the dependencies with https://github.com/lucasg/Dependencies and everything looks good.
I have typically found and associated 0x80004005 with permissions. Did you try to run the DOS prompt AS ADMINISTRATOR?
Also, VFP is ONLY a 32-bit application/dll, it was never 64-bit support, so you probably need the files in System32, not SysWow64.
Permissions might also need to be confirmed for those USING the dll. Ex: you install with admin permissions to drive
C:\SomePath\YourVFP.dll
Make sure the end-user has permissions to this path/file as well.
Aside from the above points... Do you have the VFP SOURCE code / project to build the DLL?
Based upon the comment from Tamar, I searched the registry for this DLL on a machine where I could register it and I found {CLSID}\Foxruntime\VFP7R.DLL.
I installed the VFP 7 Runtime from here (github.com/VFPX/VFPRuntimeInstallers) and I was able to register the DLL 😊
Related
I got the following error while running the vb6 project in windows 7. I was search in google. I can't find the exact solution. Please help me to fix this issues.
The component CCrpDtp.ocx or one of its dependencies not correctly registered.a file is missing or invalid
The most obvious thing is to check to see if you have the ccrpdtp.ocx file installed and registered on your machine.
If you do not, go to the Common Controls Replacement Project site and download ccrpdtp6.zip.
The file contains the control and a dll dependency, both of which need to be installed somewhere on your machine. There's also a readme file which explains that you have to use regsvr32 to register the ocx.
I'm trying to register a .dll file(msvcr110.dll) using regsvr32.
But I get an error that says:
the module msvcr110.dll was loaded but the
DLLRegistryServer entry point is not found
I have run the command under both System32 and SysWOW64 and I have run my commands with Run As Administrator. Could anyone please help?
Thanks in advance.
msvcr110.dll does not need to be registered. regsvr32 registration is applicable to DLLs that host COM servers only. Such DLLs export DLLRegisterServer entry so that it is given a chance to update registry and add registration-specific entries and hence enble discovery of the hosted COM classes. msvcr110.dll is used as a dependency DLL directly, not via COM.
Running an application from Visual Studio 2012 on 64-bit computers, displays the following error message:
Retrieving the COM class factory for component with CLSID {F2D4F4E5-EEA1-46FF-A83B-A270C92DAE4B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
I am using Inventor packandgo dll library in visualstudio.
Anyone know what is the error?
My problem and the solution
I have a 32 bit third party dll which I have installed in 2008 R2 machine which is 64 bit.
I have a wcf service created in .net 4.5 framework which calls the 32 bit third party dll for process. Now I have build property set to target 'any' cpu and deployed it to the 64 bit machine.
When Ii tried to invoke the wcf service got error "80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Now Ii used ProcMon.exe to trace the com registry issue and identified that the process is looking for the registry entry at HKLM\CLSID and HKCR\CLSID where there is no entry.
Came to know that Microsoft will not register the 32 bit com components to the paths HKLM\CLSID, HKCR\CLSID in 64 bit machine rather it places the entry in HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID paths.
Now the conflict is 64 bit process trying to invoke 32 bit process in 64 bit machine which will look for the registry entry in HKLM\CLSID, HKCR\CLSID. The solution is we have to force the 64 bit process to look at the registry entry at HKLM\Wow6432Node\CLSID and HKCR\Wow6432Node\CLSID.
This can be achieved by configuring the wcf service project properties to target to 'X86' machine instead of 'Any'.
After deploying the 'X86' version to the 2008 R2 server got the issue "System.BadImageFormatException: Could not load file or assembly"
Solution to this badimageformatexception is setting the 'Enable32bitApplications' to 'True' in IIS Apppool properties for the right apppool.
The problem is that the DLL is registered on the 32 bit version of the windows registry, and the application is using the 64 bit version.
Solution: Go into the Project Properties, Compile tab and click "Advanced Compile Options...". Change "Target CPU" to x86, click OK, save and try again.
Source:
http://www.theogray.com/blog/2009/10/comexception-regdbeclassnotreg-on-64-bit-windows
Has worked for me with an VB 6 COM DLL invoked from a .Net 4 Winforms application
Somewhere in the code you are using, there is a call to the Win32 API, CoCreateInstance, to dynamically load a DLL and instantiate an object from it.
The mapping between the component ID and the DLL that is capable of instantiating that object is usually found in HEKY_CLASSES_ROOT\CLSID in the registry. To discuss this further would be to explain a lot about COM in Windows. But the error indicates that the COM guid is not present in the registry.
I don't much about what the PackAndGo DLL is (an Autodesk component), but I suspect you simply need to "install" that component or the software package it came with through the designated installer to have that DLL and appropriate COM registry keys on your computer you are trying to run your code on. (i.e. go run setup.exe for this product).
In other words, I think you need to install "Pack and Go" on this computer instead of just copying the DLL to the target machine.
Also, make sure you decide to build your code appropriate as 32-bit vs. 64-bit depending on the which build flavor (32 or 64 bit) of Pack And Go you install.
I had the same problem. I tried lot of ways but at last solution was simple.
Solution:
Open IIS, In Application Pools, right click on the .net framework that is being used.
Go to settings and change 'Enable 32-Bit Applications' to 'True'.
In 64 bit windows machines the COM components need to register itself in HKEY_CLASSES_ROOT\CLSID (64 bit component) OR HKEY_CLASSES_ROOT\Wow6432Node\CLSID (32 bit component) . If your application is a 32 bit application running on 64-bit machine the COM library would typically look for the GUID under Wow64 node and if your application is a 64 bit application, the COM library would try to load from HKEY_CLASSES_ROOT\CLSID. Make sure you are targeting the correct platform and ensure you have installed the correct version of library(32/64 bit).
Long solved I'm sure but this might help some other poor soul.
This error can ocurre if the DLL you are deploying in the install package is not the same as the DLL you are referencing (these will have different IDs)
Sounds obvious but can easily happen if you make a small change to the dll and have previously installed the app on your own machine which reregisters the dll.
I had run into the same problem. I added reference of Microsoft.Office.Interop.Excel COM component's dll but Office was not installed on my system it wont give compile time error. I moved my application to another system and ran it..it worked successfully.
So, I can say in my case it was the system environment which was causing this issue.
I had this problem and I solved it when I understood that it was looking for the Windows Registry specified in the brackets.
Since the error was happening only in one computer, what I had to do was export the registry from the computer that it was working and install it on the computer that was missing it.
I was getting the below error in my 32 bit application.
Error: Retrieving the COM class factory for component with CLSID
{4911BB26-11EE-4182-B66C-64DF2FA6502D} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
And on setting the "Enable32bitApplications" to true in defaultapplicationpool in IIS worked for me.
For me, I had to install Microsoft Access Database Engine 2010 Redistributable and restart my computer.
This happened to me when I startup eclipse for a workspace and not other workspaces. In that workspace I had a *.ts file opened with "JS editor". Error occurred in spite of having correct file association in Preferences. Other *.ts file opened without error. To get around this, in "Open Resource" (ctrl-shift-r), I used the "Open With" button and selected "JS Editor", and the file opened without problem. After that eclipse knows the editor to use for that file. I solved the problem for one particular file type, but solution probably applies to all file types. Hope this helps someone. Thanks for reading
Check if the MS Office and MS Excel is installed on that server.
Hopefully this is placed in the right area, but I seem to be having an issue with a registered dll.
Our main application is written with Power Builder Version 11, and through various objects, we are able to call registered C# .dll's
The C# .dll is created in Visual Studio 2008 and is installed via an installer that someone else in the building made. When a user runs the installer, they are given the option to register it for everyone or 'Just Me'
The .dll is installed successfully and the user that did the install is able to run the Power Builder application and call the functions inside the .dll.
The issue that arises is that any other user that runs the Power Builder application is greeted with a message box that says: Unable to connect to: [my dll].
I tried to re-register the .dll (using Regasm) but that doesn't work. I have confirmed that the folder is in the PATH System Variable.
The only solution I found was to uninstall the .dll from the Control Panel and re-install it from scratch. But, the same issue arise after the install.
What could the issue be? I'm starting to think that it has to be a rights issue but I can't be 100% positive.
I have just installed a third party app on my Windows Server 2008 server
and I get the
ActiveX Component can't create object
message when I try to access using a CreateObject in VBScript.
It is definitely installed and exists under "Programs and Features". Does anyone have a list of things that I can check to figure out what is going on?
I have now tried to register the DLL using regsvr32.exe /i bob.dll as suggested but I get this error:
The Module "Bob.dll" was loaded but the entry-point DllRegisterServer was
not found.
Make sure that "Bob.dll" is valid DLL or OCX file and then try again.
I should note that this is a 32-bit application on a 64-bit machine at
this point. It also works fine on my machine which is Windows XP 32-bit.
It turns out to get this application working under VBScript, I had to do two things.
Run RegAsm.exe to register the DLLs.
Run the C:\Windows\SysWOW64\cscript.exe to run my VBScript.
If these don't work, check out the other answer here about enabling 32-bit applications in IIS.
It's also worth checking that you've got "Enable 32-bit Applications" set to True in the advanced settings of the DefaultAppPool within IIS.
The app is trying to create a COM Object and even if that COM DLL exists, it may depend on another DLL which isn't installed. You can use DependencyWalker to find out if this is the case.
Check your browser settings.
For me, using IE, the fix was to go into Tools/Internet Options, Security tab, for the relevant zone, "custom level" and check the ActiveX settings. Setting "Initialize and script ActiveX controls not marked as safe for scripting" to "Enable" fixed this problem for me.
Also when you register the component make sure you use the 32-bit version of regsvr32.exe.
If you simply run regsvr32.exe in a elevated prompt, it will default take the standard 64-bit version (which oddly enough is located in C:\Windows\System32)
The version I believe you need is located in C:\Windows\SysWow64\regsvr32.exe
It really looks as though the object you are referencing is not registered on the system. I know you said it's installed, but that doesn't necessarily mean it's registered. To confirm this, search for the progID that you used in your registry.
Example for this code:
set objFSO = CreateObject("Scripting.FileSystemObject")
I would search for Scripting.FileSystemObject in the registry. Then I would look at registry key above the found value, for InProcServer32 value. This will give you the path to the ActiveX file that it was registered from (for Scripting.FileSystemObject the file is "c:\windows\system32\scrrun.dll").
If you can't find your progID in the registry, then it's not registered on your system which is your problem. If it's not registered you need to find out what file registers it, which is usually an .ocx or a .dll in the same folder path of your third party app, and then register these file(s). Here is the command to register a file:
regsvr32 /i "c:\windows\system32\scrrun.dll"
Even if you find the progID value in the registry and it references a file that is present on your system, you may still want to try re-registering the file. I have found that sometimes the registration got broken somehow somewhere and it was easier to re-register the files then it was to fix the issue.
If its a 32 bit COM/Active X, use version 32 bit of cscript.exe/wscript.exe located in C:\Windows\SysWOW64\
I know this is an old thread, but has anyone checked if their Antivirus is blocking Win32API and Scripting on their systems? I have CylanceProtect installed on my office system and i found the same issues occurring as listed by others. This can be confirmed if you check the Windows Logs in Event Viewer.
I also meet the same error in vbscript.
Set objFSO = CreateObject("Scripting.FileSystemObject")
Solution:
Open command line, run :
regsvr32 /i "c:\windows\system32\scrrun.dll"
and it works
I've had the same issue in a VB6 program I'm writing, where a Form uses a ScriptControl object to run VBScripts selected by the User.
It worked fine until the other day, when it suddenly started displaying 'Runtime error 429' when the VBScript attempted to create a Scripting.FileSystemObject.
After going mad for an entire day, trying all the solutions proposed here, I began suspecting the problem was in my application.
Fortunately, I had a backup version of that form: I compared their codes, and discovered that inadvertently I had set UseSafeSubset property of my ScriptControl object to True.
It was the only difference in the form, and after restoring the backup copy it worked like a charm.
Hope this can be useful to someone. Up with VB6! :-)
Max - Italy
I had the same issue with Excel, I was trying to use a 32 COM DLL with an Excel 64 bits version and I got this error. I rebuild the COM dll to a 64 bits version and the error disappears. So be sure that your COM dll has the same architecture (x86 vs x64) than your application.
I had this problem too. I was trying to run an old 32-bit dll in a 64 bit system. I got it working by copying the .dll to the C:\Windows\SysWoW64\ directory and running this:
%systemroot%\SysWoW64\regsvr32 "C:\Windows\SysWoW64\thenameofyourdll.dll"
And also enabling IIS to run 32 bit apps