Installing CR for VS 2010 Error 1904 dtsagent.dll failed to register

[Former Member]

We are getting this error while installing CRforVS_13_0_1.exe on a windows 7 machine with Visual Studio 2010 Ultimate. All of our machines are getting this error. Please help.

Error 1904. Module C:\Program Files (x86)\ SAPBusinessObjects\Crystal Report for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win 32_x86\dtsagent.dll failed to register. HRESULT -1073741819.Contact you support personnel.

We tried Crystal Runtime also and getting the same error. we deploy our application to around 300 users.

[former_member11696 · Accepted solution]

Search here first before posting. It's an installer error generated by MSExec. A dependency is missing, Likely either the 2.0 to 4.0 Framework or the VS C++ Security runtime.

Thank you

Don

[Former Member · Accepted solution]

It doesn't seem to be missing dependency issue, as per KB published by SAP , it seems that 32 Bit installer for SAP Crystal Reports for VS 2010 is picking wrong version of cryptocme2.dll.

[Former Member · Accepted solution]

Hi, forgive any ettiquette mistakes, but I've searched the forum to no avail to the solution to the same problem.

I'm including the "SAP Crystal Reports runtime engine for .NET Framework 4" into my InstallShield installation project along with the .NET framework 4.0 Full installation and the Microsoft Visual C++ 2005 Redistributable Package and the SP1 package. I'm installing onto an XP SP3 32 bit machine and I can see all of the Microsoft prerequistes installed from the Add/Remove programs. However, when my installer gets to working through the CR merge module, I get the same 1904 error, however the first one I hit is the crtslv.dll. If I run regsvr32 on that DLL (before hitting cancel and having the install roll back), I get "LoadLibrary("crtslv.dll") failed - This applicaiton has failed to start becuase the applicaiton configuration is incorrect. Reinstalling the applicaiton may fix this problem."

Any suggestions that I can try? And if indeed this is already answered somewhere, a pointer to that would be very much appreciated.

[former_member11696 · Accepted solution]

I find 1904 error, which is generated by MSIExec, is due to missing dependencies or in this case the way dependencies are added to your project.

Download Dependency walker and open those dll's up in it and it likely shows the msvc*.dll are missing.

See this [Kbase|http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes_boj/sdn_oss_boj_bi/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/scn_bosap/notes%7B6163636573733d36393736354636443646363436353344333933393338323636393736354637333631373036453646373436353733354636453735364436323635373233443330333033303331333533333334333333393333%7D.do]: SAP Note 1534393 - "Error 1904. Module C:Program FilesSAP BusinessObjects..dtsagent.dll failed to register ..." when installing Crystal Reports for Visual Studio 2010 MSI runtime

Don

[former_member183750]

So, which thread do you want to work the issue on? This one or:

Cross posting or creating two posts in the same forum really does not help. Just confuses the issue.

Actually, I'll assume you want to work on the issue here so I'll lock the other one...

- Ludek

[Former Member]

Thanks Ludek. I am sorry for creating two thread, I replied in that thread but wasn't sure if will get a reply there and so created a new thread as well. Yes I am ready to work on the issue in this thread.

After analysis we found that we get this error only on the 32 bit version of the CR. The dll which is conflicting is the one in C:\Windows\SysWOW64 folder and if we rename it , the installs happen succefully. It makes the issue little better because as per KB it was asked to rename all instaces of this dll and the one referenced by Mcafee could only be renamed after stopping anti virus and which would have been a huge issue for deployement.

This is still a huge issue for deployment as now we will create a simple batch file to first rename the file under C:\Windows\SysWOW64 and then rename it back again. Hoepfully we will not have surprices on other machines.

Does SAP has any plans to fix this issue in later releases.

[former_member183750]

Let's rewind this one a bit and see how things shake out. It may very well be that there is another "variable" or reason that causes the issue. SP1 resolved most of the incorrect loads we were aware of - with the exception of:

1) system environment variable "R_SHLIB_LD_LIBRARY_PATH"

2) we are using SP 1 MSI from here:

http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_redist_install_32bit_13_0_1.zip

3) there was not, nor is there at this time any sniff of Beta 1 or Beta 2 of CRVS2010 on the computer

If all of the above are satisfied, then we are looking at another reason \ variable for the issue and I don't think you will see it on hundreds of computers - unless they are on the same site and created off of the same image. Not that I'm trying to minimize the issue, just trying to put it in perspective.

A few other ideas \ requests, etc.:

1) it would be good to have the version of the cryptosme32.dll in the syswow64 directory

2) any idea who installs it (tough one - I know).

3) I'd also like you to run [Modules|https://smpdl.sap-ag.de/~sapidp/012002523100006252802008E/modules.zip] on one of the computers that had the install issue (but you resolved it there by renaming the cryptosme32);

a) Run the app, get a report processed

b) Leave the app running

c) Start Modules (Go to File | New List -> Memory Modules)

What version crpe32.dll is loaded? Do you see any CR dlls of version 13.0.0.99 or version 14.x loaded? (They will mostly be loaded from C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86).

- Ludek

[Former Member]

Hi Ludek,

system environment variable "R_SHLIB_LD_LIBRARY_PATH" is not present on our machines. I also looked at other environment variables on the machines and none of the seem to be pointing to any of the location where this dll is present.

We are using correct msi.

We never installed BETA 1 or 2 on these machine. We do have Crystal Reprorts Runtime for Visual Studio 2005 on all our machines.

Not the information you asked for

1. Surprisingly cryptocme2.dll in C:\Windows\SysWOW64 on Win 7 or C:\Windows\System32 folder on XP doesn't have any version Information. There is a cryptocme2.sig file with this dll and which has following information

<Version>CRYPTO-C ME 2.1.0.0</Version>

2. Couldn't confirm who installs it but it may be Mcafee.

3. The crpe32.dll loaded is 13.0.1.220 and it is loaded from c:\program files (x86)\sap businessobjects\crystal reports for .net framework 4.0\common\sap businessobjects enterprise xi 4.0\win32_x86\crpe32.dl

CryptoCme2.dll by my application also seems to be loaded from c:\program files (x86)\sap businessobjects\crystal reports for .net framework 4.0\common\sap businessobjects enterprise xi 4.0\win32_x86\cryptocme2.dll

and the version is 3.0.0.0

There is another version of CryptoCME2.dll loaded and it is from Mcafee c:\program files (x86)\mcafee\common framework\cryptocme2.dll. There is no version information on this dll and size of the file is same as what I have under SysWow64 / system 32 folder.

Please let me know if you require any other information.

Edited by: gamepop on May 10, 2011 11:10 PM

[former_member183750]

Still, back to the number of users that the app will be installed to. In your original post on this thread you say:

We are getting this error while installing CRforVS_13_0_1.exe on a windows 7 machine with Visual Studio 2010 Ultimate. All of our machines are getting this error...

My point is, that when it will come to installing your app, you will use the CR runtime MSI or MSM:

http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_redist_install_32bit_13_0_1.zip

or if 64 bit:

http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_redist_install_64bit_13_0_1.zip

You will not be installing CRforVS_13_0_1.exe on the runtime computers.

Thus

1) Are you getting the same issue with the above runtime MSI files also?

2) Will all of those runtime comptuers actually be created equal (e.g.; same image as your computers)?

- Ludek

[Former Member]

I should have clarified that better,

When we installed CRforVS_13_0_1.exe on the devlopment machines we got this error. , Then we found the workaround published by SAP and thought Ok, if the work around is just for dev mahcines we can do that.

Then we tested the same on Deployment machines (Actual target machines with no development environment whatsoever) , using this file CRRuntime_32bit_13_0_1.msi and we got the same error.

As I mentioned earlier we do not get error with 64 bit version of runtime, but for the next release our release is going to be 32 bit and hence we need 32 bit version.

Yes all images in my organization are created equal. We are supporitng XP and Windows 7 machines currently and getting this error on both type of machines.

[former_member11696]

Hi gamepop,

The problem is generated because a legacy application ( McAffee ) is not following the new OS rules. You should not add your app path to the PATH statement. Second you should not copy anything into the \windows\system folders. All third party applications should be putting all of their runtime in the own APP Path.

The cause is when McAffee starts up it loads their older crypto dll's. CR uses an updated version but because McAffee loads first and the way Windows works is if the dll is shared and in memory any other app will use it thus causing issues like this.

I never did find out what version of McAffee used the \system folder but it's the cause.

You could try copying the one crypto dll CR installs into the \syswow64 and McAffee folders and then see if it works. If so then great, if not then all we can do is suggest you contact McAffee to "fix" their installer and to follow Microsoft Certification guide lines.

There is one other program from Computer Associates that also cause CR the same problem. In their case they too are using an older set of Crypto dll's and they put their app location in the PATH statement.

Thank you

Don

[Former Member]

Hi Don,

I understand your point of view and probably I will work with Macafee too but I think there should be soemthing SAP can do to avoid this kind of error instead of circumvent the issue by saying it is someone else's problem.

The problem we are facing here is with the CR installer and not with any other.As I found out Adobe also uses this dll but their installer doesn't fails and they also use a different version of dll then what macafee puts. I am also a developer and I know that if I need a dll I check for correct version and ensure that my application picks it from the correct place.

These are enterprise applications and hence we don't live in a perfect world where all the application follows rules, there are bound to be some exceptions , different upgrade schedules and so installer/appliction should be tested throughly to cover as many scenarios as possible and if users find some issue , they should be addressed by proper mechanism.

Hope you understand.

[former_member11696]

I Totally understand.... but at the same time we can't be responsible for updates to those legacy versions.

Ah yes, Adobe was the other one. Check the file size, I believe you'll find all of them are smaller in size than the one CR uses. Meaning we have new API's for our use that those don't have. I've tried to find out if they are a "open source" type of dll so in theory the latest version should not break any older application requirements but I have not been able to confirm this. Which is why I suggested renaming and replacing our dll over their dll to see if everyone is happy working together. It will at least get you going until updates are applied.

What happens if you install CR on a VM-ware image that doesn't have McAffee or Adobe installed, you don't get the error correct? So now what happens when you install McAffee and Adobe, does your app work or does it then fail?

It could simply be an order of install as a solution. We use McAffee Agent 4.5.0 here and none of us have ever had this problem.

Not to push this onto someone else but we can't do anything else simply because of the way Windows works and shares common files. It's one of those "dll hell" issues....

As for asking McAffee and Adobe to "fix" their install I believe it has more weight coming from you rather than from us.

Thanks again

Don