CAPICOM - Windows Server 2003 R2 64 bit - OLE automation error
Mark
R2 64 bit DB server. We ran syswow64\regsvr32.exe and it reported a
successful registration. The capicom.dll is physically located in the
system32 folder. However, when we attempt to instantiate CAPICOM.HashedData
the error message returned is "OLE automation '-2147221164'." Is there a 64
bit version of capicom.dll? Is there an additional registration step required
for 32 bit dlls like this one? Any advice would be appreciated.
--
Mark
Walter Wang [MSFT]
As far as I know, there's no 64-bit version of CAPICOM.DLL, sorry.
Although capicom.dll is a COM DLL, it's still recommended to put 32-bit
DLLs in %windir%\syswow64 instead of %windir%\system32.
Here's some test steps to verify if CAPICOM.dll is working on x64:
1) copy capicom.dll %windir%\syswow64
2) %windir%\syswow64\regsvr32.exe %windir%\syswow64\capicom.dll
3) create a simple vbscript file "test.vbs" with content:
Set x = CreateObject("CAPICOM.HashedData")
4) Now, we have to use 32-bit cscript.exe or wscript.exe to run this
test.vbs; do not double-click it: by double-clicking it, by default it's
using 64-bit wscript.exe and it will fail since 64-bit process cannot use
32-bit in-process COM component directly.
%windir%\syswow64\wscript.exe test.vbs
If your process is 64-bit, it's not possible to use the CAPICOM.dll
directly. You will have to use out-of-process wrapper to use the 32-bit com
component, such as use dllhost.exe or COM+, as described here:
http://www.64advantage.com/files/64-bit%20Insider%20Volume%201%20Issue%207.p
df
Hope this helps.
Sincerely,
Walter Wang (waw...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Walter Wang [MSFT]
If you see this, would you please reply here to let me know the status of
this post? Thanks.
Regards,
Walter Wang (waw...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
Mark
Thank-you for your advice and the reference material regarding "out of
process wrappers". I considered using COM+ as the middleman, but decided
against it due to the associated performance hit. Instead, since we were
calling CAPICOM.HashedData from SQL Server 2005, I decided to take advantage
of its new CLR integration. This involved refactoring the CAPICOM hashing
functionality that we used as a CLR SQL Server User-Defined Function
employing the System.Security.Cryptography.SHA1Managed class. The resulting
implementation performs the same work as its predecessor at one-quarter the
execution time. So it seems this problem turned out to be a blessing in
disguise.
Thanks,
-Mark