cancel
Showing results for 
Search instead for 
Did you mean: 

Installing CR for VS2010 throws 1904 Exception - fails to register many dll

Former Member
0 Kudos

I've seen this issue before, and have tried a lot of the requested fixes with 0 luck. Quicly, heres the scenario.

Windows 7 Professional x64

We've got an existing VS 2008 solution with 3 or 4 crystal reports created with the included CR pack that comes with the installation. Everything works great here.

I've recently installed a copy of VS2010 Professional and attempted to convert the 2008 solution using the built in wizard. The conversion completed, and the only issue at the end was a notification that I must manually install the CR 2010 SDK.

I started with the first d/l link on this page:

http://www.businessobjects.com/jump/xi/crvs2010/us2_default.asp

CRforVS_13_0.exe

I got an exception "Error 1904. ...... ReportPromptEMF.dll failed to register" I ignored another 10 or so similar exceptions and attempted to manually register those dlls. That also fails with "Invalid access to memory location"

I uninstalled and just for S&G ran the SAP Crystal Reports runtime engine for .NET Framework 4 (64-bit). This process completed successfully. I tried the sdk again for VS2010 - same error.

Process Mon shows:

HKLM\SOFTWARE\Wow6432Node\Microsoft\CTF\KnownClasses => NAME NOT FOUND => Desired Access Read

^^ As the last entry for the installer.

I've tried rolling back and reinstalling 3 or so times now with the same results.

I still have VS2008 installed with the CR Basic for VS2008 and CR Basic Runtime for VS2008 / x64 installed.

The only exceptions from my converted solution arise from the rpt files created in the 08 solution. Please help.

-Dave

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Dave,

I did the same and I did not get any errors.

1904 typically indicates there is a missing dependency or an updated version of some dependency we use and it may pop this error up also.

Is your OS a DELL version? If so uninstall the MacroMedia version it installs by default. Install CR again and then you should be able to upgrade the Macomedia from Dell.

Also, I've seen cases where either you do not have enough permissions or your anti-virus software is blocking the install. Try disconnecting from your network and then disable anti-virus and try installing again.

The normal install is extracting to a temp folder, try selecting it directly by typing in c:\cr4vs2010, then a dependency check is done to make you have the correct permissions and then your only option is to continue. Once the initial install is done then it prompts you to click the install for 64 bit OS's and then you are done.

Also, try emptying your temp folders, could be left overs from the beta.

We also do not recommend installing the Beta on production PC's. So uninstall, manually delete the SAP folder and install again.

Thank you

Don

Former Member
0 Kudos

Thank You for the reply, Don.

The machine is an older Dell Latitude D630. I just installed a fresh hard drive a few months ago and Installed a copy of Win7 x64 pro off of my MSDN account. So there is no MacroMedia applications that were installed from Dell from what I can see. There a macromedia flash player application, though in the AppData folder. I'm not sure what to uninstall from the programs screen in Control Panel, tough.

I'm also an admin on the machine in the "Administrators" group - so I should have no issues there.

I had Mcafee and MSE running but killed these processes on my latest try.

I also deleted the SAP Business Objects folder in Program Files and disabled my network adapter to make sure I was disconnected.

AFter removing everything, stopping everything, deleting everything, restarting the computer, starting an admin console and running the setup.exe that was extracted to C:\CRforVS_13_0, I still get the same exact problem. Something like 15 dlls cannot be registered and I ignore and continue when prompted for each one. After the install finishes I'm prompted to install the x64 runtime. This process completes successfully.

My solution still doesn't compile. When trying to view the .rpt in the designer I see the following in a "SAP Crystal Reports ActiveX Designer" dialog:

C:\Users\David~.Mol\AppData\Local\Temp\{guid}.rpt

This document could not be opened.

Edited by: DMolton on Jan 27, 2011 1:49 AM

0 Kudos

Hi Dave,

If you manually try to register one of those dll's what error do you get?

Go to MS's site and download Dependency Walker, then download the VS 2005 C++ Security distribution package 32 bit. CR still has a dependency on that 2.0 framework runtime C++ resources. Dependency walker should show you you are likely missing the mscvc80.dll and the rest of it.

Once you get that installed then try doing a repair install of CR for VS 2010. You may need to do a VS repair also.

Thank you

Don

former_member183750
Active Contributor
0 Kudos

See if installing the following will help:

[Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update|http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en]

[Visual C++ 2005 SP1 Redistributable Package|http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en]

Once you have those, try to reinstall CRVS2010.

- Ludek

Former Member
0 Kudos

The "Cannot Register dll" dialogs I'm seeing during installation indicate the problem libraries are in the win32_x86 folder. If I try to manually register them, I receive an "Invalid Access to Memory Location" dialog. I can however, manually register all but two dll's If I run RegSvr32 against the win64_x64 folder. The 64 folder seems to have all the problem dlls that the installer can't register in the win32_x86 folder except for two. The solution still doesn't compile.

I will try again now with the suggestions above. .

Thank You,

-Dave

Edited by: DMolton on Jan 27, 2011 5:29 PM

Former Member
0 Kudos

after installing the 2005 VC++ Runtime and SP1 ATL fix and rebooting, I'm still running into the exact same problem.

First I tried a repair which didn't work. I then uninstalled and deleted the left over folder. Rebooted again and tried installing again.

There's a lot of information in the Dependency Walker. I didn't see anything related to mscvc80.dll but what does stick out is:

GPSVC.DLL => Error opening file. The system cannot find the file specified (2).

IESHIMS.DLL => Error opening file. The system cannot find the file specified (2).

Warning: At least one delay-load dependency module was not found.

Warning: At least one module has an unresolved import due to a missing export founction in a delay-load dependent module.

I hope this helps,

-Dave

0 Kudos

Hi Dave,

Go into: C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\logging and look over the CR install log file to see what it reports when trying to register those dll's.

It may help....

I still suspect it's some other third party app that is blocking the install to work properly.

Did you look in those anti-virus logs to see if they blocked anything? Sometimes you have to configure the AV software to show you when it blocks something.

This is a long shot but run Microsoft's installer version checker to verify to have their latest. It should be looking for anything now...

Thanks again

Don

Former Member
0 Kudos

The antivirus logs aren't showing me anything related to blockin the CR install. Their processes have been killed in taskmanager before I ran the installer. The install log also doesn't show anything related to the two dlls I mentioned above that the dependency walker marked.

One of the problematic dll's noted in the error message during install is "commonobjmodel.dll"

Looking through the logs with this as a search reference I see:

[12:01:05:891]: File: C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\commonobjmodel.dll; To be installed; Won't patch; No existing file

[12:01:05:891]: Source for file 'commonobjmodel.dll.1B1BC767.1217.418B.932E.E221D7BC0589' is compressed

[12:07:12:726]: Executing op: RegSelfReg(File=commonobjmodel.dll,FileID=commonobjmodel.dll.1B1BC767.1217.418B.932E.E221D7BC0589)

SelfRegModules: File: commonobjmodel.dll, Folder: C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\

CustomAction +commonobjmodel.dll.1B1BC767.1217.418B.932E.E221D7BC0589 returned actual error code -2147023898 (note this may not be 100% accurate if translation happened inside sandbox)

[12:07:13:159]: Transforming table Control.

Error 1904. Module C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\commonobjmodel.dll failed to register. HRESULT -2147023898. Contact your support personnel.

MSI (s) (DC:A0) [12:07:14:164]: Product: SAP Crystal Reports, version for Visual Studio 2010 -- Error 1904. Module C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\commonobjmodel.dll failed to register. HRESULT -2147023898. Contact your support personnel.

I'm not sure what to make of it, considering I can't register the x86 dll's but I can register the x64 dlls okay. Like I said, all but two which aren't present in the x64 directory. The two dll's I can't register because they aren't in the x64 folder are:

ReportPromptEMF.dll

ReportSourceBridge.

I've tried installling after reboots. No unnecessary processes are running so I'm not sure what could be blocking. The windows event log looks the same as CR install log.

Event Log:

Product: SAP Crystal Reports, version for Visual Studio 2010 -- Error 1904. Module C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\ReportPromptEMF.dll failed to register. HRESULT -2147023898. Contact your support personnel.

Is it possible theres a conflict with the 2008 version. Should I be able to have them both running on my machine?

Thank You,

-Dave

0 Kudos

Hi Dave,

It should not be a problem install with CR 2008 there too... I have the same and no issues.

Do you have the 1.1 -> 4.0 framework installed and all of MS's patches for the framework? You should if you have CR 2008 but checking...

Do you have VM-ware or something similar to see if you can install with just VS 2010 on the PC? Or a clean test PC you can use for testing on?

All I can suggest now is to purchase a case so we can pass logs and other info back and forth. Forums doesn't allow file attachments.

Unless someone else has any suggestions, Dave?

Thanks

Don

former_member183750
Active Contributor
0 Kudos

re. can't register 32 bit dlls but 64 bit dlls are ok.

There are two versions of regsvr32.exe on 64-bit operating system. The one located at C:\Windows\SysWOW64 is 32-bit version. The one located at C:\Windows\System32 is 64-bit version.

The 32-bit version of regsvr32.exe under C:\Windows\SysWOW64 should register 32 bit files.

- Ludek

former_member208657
Active Contributor
0 Kudos

Another thing that could cause this is an incorrect version of a file called cryptocme2.dll. This is the angle that Don was coming at when referring to other 3rd party applications that are on the system.

We have our own copy of cryptocme2.dll in the following directories:

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86

and

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win64_x64

Search your C:\ drive for all instances of cryptocme2.dll. If you find one in a different path, such as C:\Windows\System32, or any other path that might be included in your environment variables - you'll need to move or rename the file while doing your install of Crystal Reports for Visual Studio 2010.

Former Member
0 Kudos

Thanks for the suggestions guys.

I do have all the frameworks and I believe they are all up to date:

v1.0.3705

v1.1.4322

v2.0.50727

v3.0

v3.5

v4.0.30319

I do believe we have a clean Win7 VM sitting around somewhere we can throw VS2010 on and try to install CR again. I suppose I can have some other team member try to install CR for 2010 on their machines as well since we all have the same hardware and OS. I'm hoping my issues are isolated just to my setup.

As for regsvr32.exe in syswow64 and in the System32 folder, when trying to reregister those failed dlls in the x86 folder, I'm still seeing "Invalid Access to Memory Location" no matter the RegSvr32 used.

I did some more reading on this 1904 issue and it's frustrating because I haven't seen a solid cause/solution to it yet. I'm wondering if Dell's are the common denominator now?

Edited by: DMolton on Jan 27, 2011 10:54 PM

0 Kudos

Hi Dave,

Check David's info above. There was a Beta install issue that was caused by some early version of Adobe and I believe Mcaffee that installed the Crypto file into the \system32 folder and it was a smaller file size than the one we install. Because it' in memory, even though you disable I think they still run, ti will cause problems.

If you have one in there see if you can rename it and then repair CR, no need to uninstall first.

Search here also on that file name, you'll find Beta post and more info one ways around it...

Oh and it was only the OEM build of Windows for Dell that caused the issue because they installed a newer version of MacroMedia than we use. It wasn't a hardware problem.

Thanks again

Don

Edited by: Don Williams on Jan 27, 2011 2:04 PM

Former Member
0 Kudos

hallelujah!

cryptocme2.dll was indeed the culprit here.

I found 3 instances of cryptocme2.dll and cryptocme2.sig on my C drive inside the following folders.

Program Files (x86)\CA

Program Files (x86)\Adobe

Program Files (x86)\McAfee

I renamed each cryptocme2.dll and cryptocme2.sig file inside those folders and postfixed the filenames with a "-old" and repaired the CR 2010 installation and everything went through fine. I can now compile my converted solution and view the RPT files.

Thank You all for your help,

-Dave

0 Kudos

Great to hear Dave....

Right, CA was the other one. They put their software resources in the PATH statement.

We'll Kbase this since it seems to be something common.

Thank you for all your patience and posting confirmation how to resolve the issue.

Don

former_member208657
Active Contributor
0 Kudos

There was already an existing kbase on this, but it has been updated to better outline the error messages you see.

Check out kbase 1534393 for more info.

Former Member
0 Kudos

Following the workaround in the knowledge base article allows me to install CR 2011, however when I rename the conflicting DLL back to its original name (and restart Visual Studio) then the code generation fails and my application fails at runtime when creating report objects.

At the moment this means that I cannot use CR for VS2010. I am also concerned that the CR runtime v13 will have the same problem, which means that I cannot ship applications built using this runtime since my customers may also have a conflicting DLL. I can't tell them to temporarily rename DLLs.

Is there something SAP can do to fix this problem?

The conflict is found at "C:\Program Files\ca\SC\ETPKI\lib" on my development machine.

0 Kudos

Hi Richard,

I believe we are hard coding the location of our dll, problem is something else comes up then it too may break. The real issue is CA should not be putting their dll in their PATH statement.

You should report this issue to CA also, they may also be able to help these conflicts with other software....

Thank you

Don

Former Member
0 Kudos

Hi Don,

According to your reply in [this thread|; the issue is being tracked as "ADAPT01491541 - CR will load our file from our folder and ignore the other ones" and is due to be fixed in CR13 SP1, is that correct? Or is this a different issue?

0 Kudos

Yes.... And I just checked. It has been fixed and will be in SP1.

Thank you

Don

Former Member
0 Kudos

As a footnote: I just solved this problem with Crystal 2010 & a CA product conflicting over cryptocme2.dll. For the SiteMinder product, the offending dll is only used in 'fips' mode. This is a special encryption protocol required for secure communications with US government agencies. If you are not using fips, you can permanently rename these files and all will be well.

SP1 should still be a good fix for folks who need fips.

former_member183750
Active Contributor
0 Kudos

Many thanks for the tip.

Still waiting for SP 1 and we will post a sticky, tweet, etc., to make sure it's known when it finally sees the light of day...

- Ludek

0 Kudos

SP1 is now available:

[original link is broken]

Thank you

Don

Former Member
0 Kudos

I am still seeing the same symptoms with SP1 (13_0_1), what am I doing wrong?

Initially the installation was an upgrade from v13, which failed and I canceled the installation. Then I removed v13 (using the Control Panel), rebooted and installed v13 SP1, which still fails.

The error is "Error 1904: Module C:\...\ReportPromptEMF.dll failed to register" on Windows XP SP3.

0 Kudos

Could be a few issues. Dependency Walker indicates that file has dependencies on:

c:\program files (x86)\sap businessobjects\crystal reports for .net framework 4.0\common\sap businessobjects enterprise xi 4.0\win32_x86\CXLIBW-5-0.DLL

c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCP80.DLL

c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5\MSVCR80.DLL

Either you have not installed the VS C++ 2005 runtime or the crypto2 issue is still a problem for you.

Uninstalling by the way does a complete removal of CR and then installs the update. The error suggest something else may not be right. you did not say what the error was so I can't say what the cause was.

If you have CA installed then rename the folder or remove the path from your PATH statement. CR SP1 then should specifically load our cryto2 dll and dependencies. Then change it back.

Thanks

Don

0 Kudos

Hi Dave,

I've been working with the Developer who patched this issue in BOE 4.0 ( same code stream as CR for VS 2010 ) and there is one condition that could cause this and that is in the System Environment variables you may have a value: R_SHLIB_LD_LIBRARY_PATH which may also have the CA path in it.

A few suggestions, try removing that value and the other was to point that path to our folder, it means CA would be using our RSA files but if the RSA files are truly backward compatible then the CA software should work. This is just a temp work around until we can figure out a way both of us can work on the same PC. If we can, it could mean we simply can't play together on the same PC.....

Please test and let me know the results?

Thanks again

Don

Former Member
0 Kudos

In answer to your questions:

  • The error is the same as in this thread: Error 1904 failed to register

  • The "Microsoft Visual C++ 2005 Redistributable" is installed

  • There is an environment variable R_SHLIB_LD_LIBRARY_PATH that has the value C:\PROGRA~1\CA\SC\ETPKI\lib

I'm guessing you don't have a system with CA installed to try this on?

My test was to run a command prompt, do "SET R_SHLIB_LD_LIBRARY_PATH=" to delete the environment variable and then run the setup from this command prompt so that the setup inherits this modified environment. This failed with the same error.

The error is:

Dialog box title: SAP Cyrstal Reports, version for Visual Studio 2010 Se...

Dialog text: Error 1904. Module C:\Program Files\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\ReportPromptEMF.dll failed to register. HRESULT -2147023898. Contact your support personnel.

Abort/Retry/Ignore

If Crystal Reports can't exist on the same computer as CA then that means our product can't either, which means that we will have to remain with v12 until we change away from Crystal Reports for our product. Which feature that is in v13, but not v12, has caused this problem?

0 Kudos

Hi Richard,

Thanks for testing that option, even though it did not work it was worth trying. No we don't have CA's software but we do have another software package that does the same thing as CA, updates the PATH statement and uses an older version of the RSA files. It too was an issue if the variable was in the System. The software we used does not add the value so it wasn't a problem.

In any case the PATH is the issue as well as older versions of the RSA files being loaded into memory on start up.

CA is an OEM Partner of ours so I have initiated a dialog with their Product group to see if they can use our version of the RSA files or possibly an even newer version, this would resolve the issues. It will take them time to do the testing if they agree to pursue the issue for us and you.

Also, I don't believe running the option in a command prompt would change the option, CA's RSA files would still be in memory under the admin control which would have a higher priority than a user Command window.

Do you have that line in your System Environment variables?

Thank you for your patience, we are still trying to find a solution. Not just for you but anyone using CA's software and trying to use CR 2010.

Don

Answers (0)