Brief
I have an installation package (MSI based) which attempts to register a dll file for use as a Windows Explorer Bar (Internet Explorer Toolbar).
The custom action is defined as follows:
[SystemFolder]\regsvr32.exe /s "pathtodllhere"
The error
The regsvr32 custom action does not work on Windows XP 64-bit.
Output from MSI log:
CustomAction SystemFolder_2 returned actual error code 5. Error
1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Action SystemFolder_2,
location: C:\Windows\SysWOW64\, command: regsvr32.exe /s "C:\Program
Files (x86)\Test Install\test.dll"
MSI (s) (10:F4): Product: Test Install -- Error 1722. There is a
problem with this Windows Installer package. A program run as part of
the setup did not finish as expected. Action SystemFolder_2, location:
C:\Windows\SysWOW64\, command: regsvr32.exe /s "C:\Program Files
(x86)\Test Install\test.dll"
A brief run-down of my tests/thoughts thus-far:
Custom action is in the "InstallFinalize" section, it is therefore run ONLY when the files have been dropped onto the hard drive.
Dll file is not corrupt and is valid.
Regsvr32 custom action works fine (and MSI installation) on: Windows 7 32-bit and Windows XP 32-bit.
Regsvr32 32-bit version is executed during 64-bit install (as it should).
Regsvr32 fails with error code 5, i.e. ERROR_ACCESS_DENIED.
Solutions and Musings
Self-registration - Not using regsvr32 and manually place the registry keys using my MSI Installer.
The dll is a Delphi COM dll which uses the TRegistry component to register itself. Again, I can't think of a reason why this wouldn't work as it is merely a wrapper, but just a thought.
Hopefully I have shown my research here and don't waste anyone's time!
The best practise solution (as you've alluded to) is to extract the registry entries from the component and write them to the registry using the msi.
Background
Regsvr32 requires admin rights and elevated privilege confirmation to register COM components under 64-bit Windows 7 but msiexec doesn't know to request elevated privileges for the custom action.
You can test this requirement by using "Open with..." to run C:\Windows\SysWOW64\regsvr32.exe on the component (which will fail). Whereas if you create a batch file for the registration and then "Run as Administrator" the component will register successfully.
Related
I'm using a Visual Studio Deployment project in VS2010 to install/upgrade my application, and on Windows 2003 and older it seems like it refuses to stop the service before attempting the upgrade. As a result, it requires a reboot after the installation finishes. Here's a snip from the msiexec log where I have program.exe running under the old service and I'm trying to install program.exe as part of the upgrade:
MSI (s) (70:64) [12:00:34:448]: Note: 1: 2727 2:
MSI (s) (70:64) [12:00:34:682]: 1 application(s) had been reported to have files in use.
Info 1603. The file C:\Program Files\company\program.exe is being held in use by the following process: Name: program, Id: 712, Window Title: '(not determined yet)'. Close that application and retry.
MSI (c) (60:BC) [12:00:34:682]: File In Use: -program- Window could not be found. Process ID: 712
MSI (c) (60:BC) [12:00:34:682]: No window with title could be found for FilesInUse
MSI (s) (70:64) [12:00:34:682]: Note: 1: 2727 2:
MSI (s) (70:64) [12:00:34:682]: Doing action: InstallInitialize
Action ended 12:00:34: InstallValidate. Return value 1.
On reboot the software appears to be installed but the files that were in use previously were not re-installed, and the service has not been installed. The shortcut I drop on the Desktop acts as an advertised shortcut - double-clicking it will force MSI to see that the installation is incomplete and it repairs successfully.
BUT, some users may be doing this upgrade without logging back in (to a web server for instance), and I'd like to either:
Complete the installation without requiring a reboot, or
Reboot and complete the installation automatically prior to user login.
Here's what I've tried:
Running msiexec /i <pkg.msi> /norestart - this doesn't help, and if I try to use the shortcut prior to restarting, it attempts to repair the install and fails.
Disabling advertised shortcuts by setting the property DISABLEADVTSHORTCUTS=1 - this doesn't work either, because then the target opens but the install still isn't complete so it won't run properly. The msiexec /f <pkg.msi> can still be used to repair the install.
Adding a RunOnce key to the registry at HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce to invoke the repair operation to finish the install - this didn't seem to run, but it worked if I ran it at the command line so I'm not sure what the issue is here. The value of the string I added to RunServicesOnce using the installer is [SystemFolder]\msiexec.exe /f [ProductCode] /qn, which seems to evaluate correctly to C:\Windows\system32\msiexec.exe /f {my code} /qn.
Editing the .msi with Orca to stop the service (via the ServiceControl table) so that the file is not in use - this doesn't work because it doesn't seem to stop the service until after it has evaluated whether or not the file is held.
I think I'm lost and I hope I'm missing something obvious. Set me straight. Thanks in advance!
I have Windows 7, 64-bit.
I'm trying to register a .dll (comdlg32.dll) using regsvr32. But I get an error that says the dll is read 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".
My old MSComDlg.CommonDialog component is no longer working with 64-bit.
comdlg32.dll is not a COM DLL and cannot be registered.
One way to confirm this for yourself is to run this command:
dumpbin /exports comdlg32.dll
You'll see that comdlg32.dll doesn't contain a DllRegisterServer method. Hence RegSvr32.exe won't work.
That's your answer.
ComDlg32.dll is a a system component. (exists in both c:\windows\system32 and c:\windows\syswow64) Trying to replace it or override any registration with an older version could corrupt the rest of Windows.
I can help more, but I need to know what MSComDlg.CommonDialog is. What does it do and how is it supposed to work? And what version of ComDlg32.dll are you trying to register (and where did you get it)?
comdlg32.dll is not really a COM dll (you can't register it).
What you need is comdlg32.ocx which contains the MSComDlg.CommonDialog COM class (and indeed relies on comdlg32.dll to work). Once you get ahold on a comdlg32.ocx, then you will be able to do regsvr32 comdlg32.ocx.
Registering DLL for Fundsite
Outdated or missing comdlg32.ocx runtime library can be the problem of causing this error.
Make sure comdlg32.ocx file is not corrupted otherwise Download the File comdlg32.ocx (~60 Kb Zip).
Download the file and extract the comdlg32.ocx to your the Windows\System32 folder or Windows\SysWOW64. In my case i started with Windows\System32 but it didn’t work at my end, so I again saved in Windows\SysWOW64.
Type following command from Start, Run dialog:“c:\windows>System32\regsvr32 Comdlg32.ocx “ or “c:\windows>SysWOW64\regsvr32 Comdlg32.ocx ”
Now Comdlg.ocx File is register and next step is to register the DLL
Copy the Fundsite.Text.Encoding. dll into .Net Framework folder for 64bit on below path
C:\Windows\Microsoft.NET\Framework64\v2.0.50727
Then on command prompt and go to directory C:\Windows\Microsoft.NET\Framework64\v2.0.50727 and then run the following command as shown below.
This will register the dll successfully.
C:\Windows\Microsoft.net\framework64\v2.0.50727>regasm "Dll Name".dll
Have you unistalled your Internet Explorer?
I did, and I had the same issues, if so, you have to:
Reactivate IE (Control Panel -- Programs and Features -- Turn Windows features on or off).
restarting the computer
(important!) running Windows Update to get all available updates for Microsoft Explorer
restarting the computer (again)
Finally it works!
I have faced the same issue with COMDLG32.OCX and MSFLXGRD.OCX in Windows 10 and Visual Studio 2010. It's an MFC application.
Then I downloaded its zip file from the google after extracting copy them at following paths:
C:\Windows\System32 (*For 32-bit machine*)
C:\Windows\SysWOW64 (*For 64-bit machine*)
Then run Command Prompt as an Administrator then run the following commands:
For Windows 64-bit systems c:\windows\SysWOW64\ regsvr32 comdlg32.ocx
c:\windows\SysWOW64\regsvr32 msflxgrd.ocx (My machine is 64-bit configuration)
For Windows 32-bit systems c:\windows\System32\ regsvr32 comdlg32.ocx
c:\windows\System32\regsvr32 msflxgrd.ocx
On successfully updation of the above cmds it shows succeed message.
Information about missing entry point error installing legacy VB6 compiled applications on Windows 10 which I hope could be useful to someone.
Missing OCX files can be found in the "OS\System folder" of the Visual Basic 6.0 installer package.
Today I copied the relevant OCX file (from our network) to the local computer
And then I typed the commands below, as administrator, which normally work to register it.
cd \windows\syswow64
regsvr32.exe /u mscomctl.ocx
regsvr32.exe /i mscomctl.ocx
(add the path to the locally copied file for the /i command)
However today I got errors from both these regsvr32.exe commands.
The second error was giving the DllImport missing entry point error which is similar to the error mentioned by the original poster.
To resolve, one of the things I tried was leaving out the switch -
regsvr32.exe mscomctl.ocx
To my surprise it then said it was successful.
To confirm, the application started up properly afterwards.
SOLUTION OF Regsvr32: DllRegisterServer entry point was not found,
Go to systemdrive(generally c:)\system32 and search file "Regsvr32.exe"
Right click and click in properties and go to security tab and click in advanced button.
Click in owner tab and click edit and select administrators and click ok.
Click in permissions
Click in change permissions.
Choose administrators and click edit and put tick on full control and click ok.
Similarly, choose SYSTEM and edit and put tick on full control and click ok and click in other dialog box which are opened.
Now .dll files can be registered and error don't come, you should re-install any software whose dll files was not registered during installation.
I also had the similar problem while registering myinfo.dll file in windows 7. Following work for me:
Create a short cut on your desktop
C:\Windows\System32\regsvr32.exe c:\windows\system32\myinfo.dll
right click on the short cut just created and select as Run as administrator.
My Azure role startup task is invoking a .cmd file:
<Startup>
<Task commandLine="startup.cmd" executionContext="elevated" taskType="simple"/>
</Startup>
The .cmd file contains invokation of regsvr32:
//startup.cmd
regsvr32 PathToMyComServer\MyComServer.dll
for registering a 32-bit in-proc COM server.
Now on 64-bit systems there're two versions of regsvr32 - one in SysWOW64 folder for 32-bit COM servers and one in System32 folder for 64-bit COM servers. Of course only the matching version of regsvr32 can be used for any given in-proc COM server.
When I login onto my development Windows 2008 box and run regsvr32 from a command line the 64-bit version is invoked, but when my startup task runs - both in Compute Emulator and in the live cloud - the 32-bit version is invoked and properly registers my in-proc COM server. This puzzles me.
Why is 32-bit version of regsvr32 invoked in Azure startup task?
Please try running your Startup task in as Real User Context as described in the link below, this should solve this problem:
http://www.davidaiken.com/2011/01/19/running-azure-startup-tasks-as-a-real-user/
On Azure VM i tried using PxExec tool to launch Regsvr32
psexec regsvr32 -> Launches 32bit version of regsvr32
psexec -s regsvr32 -> Launched 64bit version of regsvr32
In both cases psexec was launched in 32bit mode on Azure VM running Win2K2008 64bit.
Thats why there is a reason I suggested to try launching startup task in real user context because on my 64bit machine, limited user rights, launching regsvr32.exe actually launch 32bit REGSVR32 and with admin user context same command launches 64bit regsvr32. Because startup task is not launched in real user context, I suspect this could be the one reason.
Another option is that you can use "PsExec -s" option to launch 64bit version of regsvr32 as well.
I have an installer package, at the last step user can select launch application or not. the installed application is 32bit, during the installation we select the installation folder to "c:\Program Files", while it will always install application to "c:\Program Files(x86)" folder, then we meet problem, we can not launch the application, we have tested that if we choose the default installation folder(which means c:\program files") it works well. so I guess the problem is that windows launch 32bit application as 64bit, so it failed. how to solve it?
Your installer should know the path the application was installed to. You should use it, your EXE file key; for a WiX example see Well Done section of the tutorial.
If your installer package is MSI-based, then the installer is a 64 bit process, and it sees both Program Files (x86) and Program Files. I think it is the problem why you can't start your program. (A 32 bit executable will see only Program Files (x86) under the name of Program Files).
I thought this was a privilege issue but I logged on as admin and still couldn't get more than a brief flash of the command window. I am just double clicking on the exe file I found in the 7.0 sdk
As a side question, can you just go into the GAC manually and delete something??
Cheers,
Berryl
It's a command-line utility. You ran it without arguments (by the sound of it) and it quickly exited. Run cmd.exe and run gacutil from there.
You can also use the Windows Explorer extension to delete assemblies - just browse to C:\Windows\assembly (or whatever your Windows directory is).