Error 1904 when installing Crystal Reports 2010 Redistributable

[Former Member]

Hi,

I'm having trouble installing the CR 2010 Redistributable on a few machines. We've installed all the windows updates and have reinstalled all the C++ 2005 redistributables including the newer ATL update. On install, a bunch of dll's can't register including commonobjmodel.dll

Using dependencywalker we see that it's missing the reference to MSVCR80.dll.

Is there a way the the Restributable can include the C++ redistributable instead of being dependent on it?

Thanks

[former_member183750 · Accepted solution]

If by "CR 2010 Redistributable" you mean CRRuntime_32bit_13_0.msi, then the file is included there.

If you mean the msm (CRRuntime_13_0.msm), then no this is not possible due to Microsoft licensing issues.

E.g.; if you are using the CR msm files, you are responsible for including the VC++ and ATL dependencies .

Ludek

Follow us on Twitter http://twitter.com/SAPCRNetSup

Got Enhancement ideas? Try the [SAP Idea Place|https://ideas.sap.com/community/products_and_solutions/crystalreports]

[Former Member · Accepted solution]

Hi Ludek

I do mean the CRRuntime_32bit_13_0.msi. If the file is included - what would cause the installer not to be able to register those files then?

Thanks

[former_member183750 · Accepted solution]

Not sure what would be preventing an install of the VC++ file(s). Perhaps downloading the VC++ msi from Microsoft and trying to install it may give you some clues.

Ludek

[Former Member · Accepted solution]

Hi Ludek,

The VC++ files(s) are all installed. All Window Updates are applied. If we hit ignore on the could not register messages, a bunch of other dll's can't register either.

After if we try to manually register the commonobjmodel..dll we get the generic Invalid Access to Memory Location.

Any other ideas we could try?

[former_member183750 · Accepted solution]

Are you doing this install as a local Admin?

One other idea;

When you are attempting to manually register any of the dlls, run [Process Monitor|http://technet.microsoft.com/en-ca/sysinternals/bb896645.aspx]. Filter it for regsvr32 before proceeding so that you limit the log file. Then check the log for any permission issues (registry, files, folders).

Ludek

[Former Member · Accepted solution]

Hi Ludek,

Thanks for the direction. I looked at 2 servers that we have both Server 2003. One installed the redist OK, the other failed.

Looking at the processMonior - one thing that popped out, it was was doing a bunch of open/reads on

c:\program files\CA\Shared Components\Etpki\lib\cryptocme2.dll

That is coming from an ArcServe Backup utility, that is installed on a bunch of machines. When we uninstalled it, we could installt he Redist without issues.

Is there anything on your internal database that would point to a workaround for this? Why would it reference arcserve and not the cryptocme2.dll in the SAP folder?

Thanks!

[former_member183750 · Accepted solution]

Environment path?

Ludek

[Former Member · Accepted solution]

Hi Ludek,

Yes there is an PATH environment variable that points to the ArcServe folder.

The workaround that has worked for us is renaming the cryptocme2.dll in the C:\Program Files\CA\SharedComponents\Etpki\lib\ folder, installing crystal redist 2010, then renaming the file back.

Is there anything you can do to resolve this? Or is this simply a window dll problem in which Windows will take that cryptocme2.dll over the crystal reports one because it's in the path environment variable.

Thanks

[former_member183750 · Accepted solution]

My take on this is as you put it;

simply a window dll problem in which Windows will take that cryptocme2.dll over the crystal reports one because it's in the path environment variable.

But I'm willing to entertain the thought that this may also be a CA issue, SAP issue or all of the above... So much for end to DLL hell...

I suppose doing a static load on the dlll would help, but I'm not sure. Something I'll suggest to Program Management.

Ludek

[Former Member]

I have the same issue with an already registered cryptocme2.dll file.

After renaming the folder the installation was successful. But, when i renamed the folder again to it's old name CR stopped working. CR is probably looking at the wrong DLL file again. The "wrong" dll file is in the PATH. I can't remove it because i don't know what it will do to the clients software.

How to resolve this? And how can this happen in the first place? If the files are different, shouldn't they be registered separately? I have never had any troubles like this with any other installation.

[Former Member]

See Note on ArcService dll conflict