Capicom.dll 64-bit Windows 10
Desmond Hutchins
I am running InstallShield 2019 R3 (Premier Edition) in Windows 10 and it crashes when I perform a "Build Release". The last log I see is "Extracting COM data from 1 component(s)" and then it freezes up.
Can you check, all the dependencies of capicom.dll are in place during the COM extraction. According to the Microsoft link, this DLL is supported in the Windows Vista, XP and server 2008. See, in what operating system you are building, and all the dependencies for this DLL is present during the COM extraction. [CAPICOM is a 32-bit only component that is available for use in the following operating systems: Windows Server 2008, Windows Vista, and Windows XP.]
InstallShield provides three different methods to extract the COM information, but at a time InstallShield extract the information based on the method configured in the registry. UseAPIRegistryHooks registry value located in HKEY_LOCAL_MACHINE\Software\InstallShield\RegSpy key (on 32-bit machines) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy key(on 64-bit machines) holds the method configured to extract the COM information.
InstallShield provides a utility tool named RegSpyUI to cross check the values extracted from COM component, extracted by the method specified in the registry. RegSpyUI tool is available in the InstallShield support folder(C:\Program Files (x86)\InstallShield\2019\Support), this tool can be used to verify the COM extraction done by InstallShield.
and set the value to 1, my problem no longer occurs. Why exactly is this change is necessary? Is this an indication of a problem with the file capicom.dll?
Is there a way to configure UseAPIRegistryHooks as part of the installation of InstallShield? Manually adding a registry entry seems like an archaic way to configure InstallShield to work with capicom.dll.
By default, installshied uses the latest methodology to extract COM information (ie Value "2"). In some cases, if the kernel driver methodology is not working, it can be switched back to the other methodology by changing the values in the registry.
I'm receiving System Error 5003 (4060) when I try to select the database for Dynamics SL 2011. The error pops up after I select the database name. I know that the database name and location are correct, and other users are able to access the system, it's only my computer that cannot.
I followed the instructions in this post to enable Named Pipes and TCP/IP. If I set the alias as instructed the program becomes unable to even find the list of databases, so I removed the alias but kept the protocols enabled. I am able to ping the server. Manually registering capicom.dll does fix the problem. I have allowed Dynamics SL through my local Windows Firewall.
Cause 1
The servername value in the domain table in the Microsoft Dynamics SL system database does not match the name of the
instance of the SQL Server that contains the Microsoft Dynamics SL databases. See Resolution 1.
Cause 2
An alias in the Client Network Utility points to an old server. Make sure that the alias in the Client Network Utility is
correct. See Resolution 2.
Cause 3
The Named Pipes protocol and the TCP/IP protocol are not enabled in the Client Network Utility. See Resolution 3.
Cause 4
Occurs when you try to log on to a new Microsoft Dynamics SL application database, and the name of the database begins
with a number. Because there is a limitation in SQL Server, the database names are required to begin by using an
alphabetical character. See Resolution 4.
Cause 5
You cannot establish a Named Pipes connection to the server because you have insufficient Windows permissions. See
Resolution 5.
Cause 6
TCP/IP is configured incorrectly. See Resolution 6.
Cause 7
The database is set to Single-User mode. See Resolution 7.
Cause 8
The Capicom.dll file on the computer where the error is being received is either corrupted or the version is incorrect. See
Resolution 8.
Cause 9
The Windows Firewall on the SQL Server is blocking the access to the SQL Server/SL databases. See Resolution 9.
Cause 10
You use the Windows Authentication security model in Microsoft Dynamics SL. However, you have not linked the user ID in
Microsoft Dynamics SL to the user ID in Windows. Additionally, you manually created the same user ID in the Microsoft
Dynamics SL system database in SQL Server. See Resolution 10.
Cause 11
The Microsoft Dynamics SL user account is a member of the ADMINISTRATORS group in Microsoft Dynamics SL. However,
the related Windows domain user account is not a member of the sysadmin role in SQL Server. See Resolution 11 and
Resolution 12.
Cause 12
The Windows Firewall in Windows Server 2008 R2 is blocking the access to the SQL Server/SL databases. See Resolution
13.
Cause 13
Occurs in the Find Database (98.000.01) screen when you click to select an application database in the Database
Name box. See Resolution 14.
Cause 14
Occurs in the Find Database (98.000.01) screen when you click OK after having selected the Server Name and
Database Name. See Resolution 15
Resolution 1
Verify the servername value in the domain table to make sure that the value matches the name of the instance of the SQL
Server where the Microsoft Dynamics SL installation is located.
1. In SQL Server Management Studio, run the following statement on the Microsoft Dynamics SL system database.
Resolution 2
Remove the alias that refers to the old server. To do this, follow these steps:
1. Click Start, click Run, type cliconfg, and then press ENTER.
2. On the Alias tab, verify that all aliases listed are accurate and are for current servers. If any of the aliases refer to
old servers, use the pointer to put the focus on the one that you want to remove, and then click Remove.
3. Click OK.
On a 32 bit computer:
Go to start > Run > type cliconfg
On a 64 bit computer:
1. Browse to C:\Windows\SysWOW64
2. Run cliconfg.exe located in that folder
Resolution 3
Verify Named Pipes and TCP/IP are enabled in the Client Network Utility.
1. Click Start, click Run, type cliconfg, and then press ENTER.
2. On the General tab, verify that the Named Pipes protocol and the TCP/IP protocol appear in Enabled protocols
by order. If these protocols are not enabled, use the pointer to put the focus on each one, and then click Enable.
3. If the Named Pipes protocol is not the first protocol in the list, select the Named Pipes protocol and use the arrow
keys to move it.
4. Click OK.
Note: Typically, there is no set recommendation on which protocol should load first. Depending on network
configurations, one protocol may work better than the other.
On a 32 bit computer:
1. Go to start > Run > type cliconfg
2. Make sure both Named Pipes and TCP/IP are enabled.
On a 64 bit computer:
1. Browse to C:\Windows\SysWOW64
2. Run cliconfg.exe located in that folder
3. Make sure both Named Pipes and TCP/IP are enabled.
Resolution 4
Create a backup of the existing Microsoft Dynamics SL application and system databases, and then restore the databases
to the same server by using alpha database names. For more information about how to back up and restore the
databases, click the following article number to view the article in the Microsoft Knowledge Base:
846350 ( ) Steps to take to move the Microsoft Dynamics SL databases to
another computer that is running SQL Server 2000, SQL Server 2005, or SQL Server 2008
Note: In step 4, make sure that you restore the database to the same SQL Server.
Resolution 5
Grant user sufficient permissions in Windows.
Note: SQL Server cannot read the Registry Settings to establish a Named Pipe connection because the user has insufficient
permissions in Windows. Contact the Network System Administrator for help.
Resolution 6
Verify that TCP/IP is configured correctly.
1. If you use DHCP to assign IP addresses, make sure that the computer that generates the error is letting the DHCP
server to assign the address, instead of assigning a static IP address.
2. Verify that the workstation can ping the server by or .
3. If you use static DNS resolution, add the server that is running SQL Server to the DNS Server Search Order list
that is found in Network - TCP/IP Properties - DNS Configuration, or to the Host file on the workstation computer.
Contact the Network System Administrator for help.
Resolution 7
Clear Single User Access in Database Properties.
1. Open SQL Server Management Studio.
2. Expand Databases.
3. Right-click the Microsoft Dynamics SL application database, click Properties.
4. On the Options page, and verify that Single User is not selected as the Restrict Access value.
Resolution 11
Synchronize the ownership and security on the Microsoft Dynamics SL databases. To do this, follow these steps:
1. Open the Database Maintenance (98.290.00) screen.
2. In the Destination SQL Server Name box, type the name of the server.
3. In the Login ID box, type sa.
4. In the Password box, type the password for the SYSADMIN user.
5. Click Connect.
6. On the Update Database tab, iIn the System Database Name box, click the system database.
7. In the Databases column, select your application database.
8. In the Update Scenarios area, select Synchronize All Ownership & Security.
9. Click Update Database.
10. Close the Database Maintenance (98.290.00) screen.
Resolution 12
Remove and re-add all users to the ADMINISTRATORS group in Microsoft Dynamics SL. To do this, follow these steps:
Note This resolution assumes that one or more Microsoft Dynamics SL user accounts with administrative
permissions can log on to Microsoft Dynamics SL, so is probably not applicable...
1. Log on to the domain by using a Windows domain user account that is linked to a Microsoft Dynamics SL user
account that has administrative permissions.
2. Click Administration.
3. In the System Manager pane, click Group Maintenance under Security.
4. In the Group ID box, type ADMINISTRATORS, and then press TAB.
5. Note the user IDs listed in the Detail area.
6. Delete all users from the list except for the user ID you are currently logged on as.
7. Click Save.
8. Add the user IDs, and then click Save.
9. Close the Group Maintenance (95.280.00) screen.