CR for VS2010 deployment - crtslv.dll failed to register

[Former Member]

I'm still having problems with packaging up the CR for VS2010 library with our applications installation.

I'm using InstallShield 2011 for the installation setup.

I've included the CRRuntime_13_0.msm file. (That is the only MSM file I included, are the others needed also?)

I've included the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86 and the x64 versions.)

I have tried to do a test install on both a 64bit and a 32bit Windows 7 computer and it keeps giving me the crtslv.dll failed to register error on both computers.

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

I thought it might just be due to the 32 bit MSM causing the problem on the 64bit computer, but I can't even get it to install on a 32bit computer. (On the 32bit computer install, I even removed the x64 bit version of the MS C++ 2005 Redistributable from the installation setup just to make sure it wasn't causing a problem).

I have even tried having my Install Shield setup 'Chain' the CRRuntime_32bit_13_0.msi file to my main installation (not using the Merge module). Even when that runs, it produces the same crtslv.dll failed to register again.

BUT, if I run the CRRuntime_32bit_13_0.msi manually on the computer it installs correctly. (I even tried using the same /qf parameters that InstallShield is using on it and it also worked OK that way.) So I can't figure out how to get it to run in conjunction with my InstallShield installation.

Can anyone give me any suggestions?

Mike...

[former_member183750 · Accepted solution]

The MSI contains all the CR runtime and dependencies:

[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]

and

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

Due to MS licensing restrictions, the above can not be included in the MSM and you have to ensure the dependencies are included in your deployment project.

Ludek

[anders_gustafsson · Accepted solution]

Sorry for resurrecting this, but I face the same issue, ie crtslv.dll and friends fail to register. Installing the two packages above does not seem to help. I am using InstallShield 2013.

Dependency walker says that crtslv.dll needs msvcr80 and atl80

[former_member11696 · Accepted solution]

Hi Anders,

Install the MS VS 2005 C++ Security MSI first and then it should work.

Don

[anders_gustafsson · Accepted solution]

OK. It certainly would be helpful if MS had not decided to release a plethora of runtimes all my the name of vcredist_x86... Anyway, I decided to follow the scientific approach:

I installed a brand new Win7 64 VM, On such a beast, you cannot even install the CR Runtime MSI, FWIW. Then installed all 163 required updates, then all the optional ones. Did snapshots inbetween.

This machine has no copy of ATL80 and crtslv.dll depends on atl80 and msvcr80. The magic vcredist you linked to contains version 5072 of these DLLs.

My setup.exe fails on this machine, unless I install the vcredist prior, even if my setup project is set to include mfc80 and atl80. I remember seeing somewhere that the CR dependency for ATL is not set so Installshield cannot figure out the correct install order.

I guess I will have to talk to Installshield about this.

[former_member11696 · Accepted solution]

Hi Anders,

The other dependency you may run into is the Framework 2.0 and above. Make sure those are up to date also, which was likely part of the 163 updates by MS...

Thanks again

Don

PS - I did note to the install team that we do have a dependency on the C++ runtime so it should be included in our MSI... But maybe not...

[anders_gustafsson · Accepted solution]

Anyway. This is the way to solve it, until the MSM is fixed

You can use the Prerequisite Editor (http://helpnet.flexerasoftware.com/installshield20helplib/installshield20helplib_CSH.htm#helplibrary...) to create your own prerequisite which will run that install before your install begins. That is assuming you have the Premier or professional versions of InstallShield and not the Express version.. No, I see no justification to fork up 2000$ or 4000$, plus an annual 1000$ fee just to fix this. Fortunately, there is a far easier way.

Setup tree, item 5, Custom action, highlight "after ready to install dialog", create a custom action that runs the Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update executable with a /q:a commandline.

This is the far easiest way, the installation will not be totally silent, but I only see that as a plus as the person installing might otherwise think the install has hung.

If you are hell-bent on doing it silently, then see: http://blogs.msdn.com/b/astebner/archive/2006/08/23/715755.aspx

Hope this helps someone!

[Former Member · Accepted solution]

Anders and Don--

Thank you!  I've been struggling with this issue for weeks and I didn't have to do the custom prerequisites like you described, but just added the correct C++ 2005 Security Update that you and Don Williams described (I'd tried the straight C++ 2005 before and it failed), and I had not heard of the ATL dependency before, so added the version that a dynamic scan came up with (3.xxx) and it worked.

I hope the 7,000+ viewers of some of the pages on this subject that I visited will find your answer that finally WORKS!

Thanks again,

Charlie Carroll

[anders_gustafsson · Accepted solution]

You are welome. I have had tremendous help from fora like this in the past so I try go "give back" whenever I can.

I guess it is of no help that there is a plethora of vcredists around, all by the same name and only the right one works. I have now saved that one for posterity, under an unique name.

[Former Member · Accepted solution]

Hi Ludek,

Apologies for asking another question on this a while after it was last looked at, but I'm getting a very similar problem and was hoping you could offer some advice.

I am trying to install CRRuntime_32bit_13_0_14.msi as a pre-requisite for a click-once application.  This works fine on a fresh VM with XP, Windows 7 and Windows 10, but I get the following error on 8.1 (x64).

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\crtslv.dll failed to register.  HRESULT -2147010895.  Contact your support personnel.

Looking around I don't think the issue will be the 2005 C++ runtime as stated on here that is included in the MSI file.  The product.xml pre-req file states that .Net 2 is needed for this - is that definitely the case?

It would explain why it worked out of the box in XP and Windows 7, but not why it works on a fresh Windows 10.

Do I definitely need to have .Net 2 installed (or in windows 8 speak have that product feature enabled) for the CR runtime to install?

Thanks,

Paul

[former_member11696 · Accepted solution]

Hi Paul,

We do have a dependency on the C++ runtime so it must be installed first.

Also, on Windows 10 it appears the 3.5 framework is not installed by default and we've been having issues trying to get it installed. Seems to be a problem with Windows 10.....

We are looking into it...

Don

[Former Member · Accepted solution]

Hi Don,

Thank you very much for coming back to me on this.  Please can you confirm which of the many C++ runtimes there are that are required?

We are already installing the 2010 x86 10.0.40219 version as part of our bootstrapper, and I know that 2008 is already on the VM before we start.

I thought your MSI bundled the C++ in with it?  That is what seemed to be implied above.

This is an odd problem which I've only seen a couple of times on windows 8 - I've installed it many many times on Windows 10 without an issue.

I've since changed to use the 13_0_15 CR runtime and this has installed on 7, 8 and 10 over 5 times each without issue.

Is it a timing issue going on internally in the CR msi?

Hopefully by moving to v15 it isn't a problem any more.

Thanks,

Paul

[former_member11696 · Accepted solution]

Hi Paul,

Ah yes, correct, they do, all but the Merge module do not.

The installer does create a log file, assuming you did not uncheck the option.

Look for it in: C:\Users\XXXX\AppData\Local\Temp

It should list what the issue was...

Don

[Former Member · Accepted solution]

Hi Don,

All the log file had in it was the message above:

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\crtslv.dll failed to register.  HRESULT -2147010895.  Contact your support personnel.

Helpfully everytime I ran this with full MSI logging on it always worked (the line where I *assume* it would have fallen over was: MSI (s) (C4:58) [09:56:27:403]: Executing op: RegSelfReg(File=crtslv.dll,FileID=crtslv.dll.7AFD3E43.366D.426F.A538.D5B2BE1CE228))

Paul

[former_member11696 · Accepted solution]

Hi Paul,

1904 error is generated by MSIExec, typically means there are dependencies missing the CR runtime needs. Run Dependency Walker on that file on the redist PC and it will tell you what is missing.

Or could be permissions, make sure you are running the setup.exe under a local PC admin account.

Does that PC have any other version of CR installed? Search for crpe32.dll, if it does it could be side by side issue...

Don

[Former Member · Accepted solution]

Hi Don,

Thank you for continuing with this.  I did download dependency walker a few times but typically it has never fallen over when I had it there.

It is definitely being ran as an admin account as the bootstrapper product.xml file would cause the setup.exe to fail if the user didn't have admin privileges.

It was also a clean VM - so no previous CR install.

What I don't understand is that if there is a dependency missing why this isn't an issue that happens every time I run the bootstrapper all the way through.  The VM always starts in the same state and then we install the same programs before getting to the CR msi, so why has it died a couple of times due to a missing dependency - surely the files are there or not every time?

That is what made me think that it is something internal going on with the CR MSI itself (if that is bulk installing multiple MSM's, e.g. the C++ runtime) it is possible that these are potentially run out of order which would result in this dependency issue?

Thanks,

Paul

[former_member11696 · Accepted solution]

Hi Paul,

What happens if you run the CR MSI by double clicking on it? Not through your installer....

That may show us if it is a timing thing or not.

Don

[Former Member · Accepted solution]

Hi Don,

Yes I did try this a couple of times after it had failed during the bootstrapper from the installer directly.

Once it failed again with exactly the same reason, the other time it completed without a problem.

Paul

[former_member11696 · Accepted solution]

Hi Paul,

I don't know then, others have no problem so it has to be something within your environment.... Without being able to reproduce the problems you have it's impossible to keep guessing...

All I can suggest is look at the install logs and fix what ever it's indicating is either missing or access denied errors and/or use Dependency Walker ( I heard version 2.2 is out ) to check what is missing.

Tslv dll is used to uncompress the report files, maybe your AV software is detecting it as a Trojan or something like that and stopping it from working.

Check your AV logs, others have run into this problem with their AV software blocking installs.

Don

[Former Member · Accepted solution]

Hi Don,

Thank you for trying to help - I will speak with the guy that set up the VM to see if there is any AV running.

I haven't yet had this issue on 13_0_15 so hopefully whatever it was has been resolved any way!

I'll get back in touch if anything goes wrong in further testing.

Thanks again.

Paul

[anders_gustafsson · Accepted solution]

Sorry for the lateness of my reply, but activate full MSI logging (voicewarmup) and have a look at the log files. also, running process explorer to catch any failed file opens might help.

[Former Member]

I finally got past this issue and got things to install, with a few hackish work-arounds.

First the CR13 msm redistributable appears to requre the 32 bit version of "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security" that you'll read about in every post.  On 64 bit machines I found that even when it was installed,I would still get a crtslv.dll failed to register message, followed several other dlls not registering.  Once I installed the 32 bit version on the 64 bit OS, the crystal 13 redistibutable installed fine everytime.  I did this on several 64 bit VMs all running Server 2003,XP, and Windows 7.  It ran fine every time.

The problem you'll face is how do you install the 32 bit version of this ATL security pack on a 64 bit machine.  You may be able to download and run the 32 bit version from Microsoft's site with the link Ludek has posted.  That wouldn't work for me because I had to distribute it with my software so I used the prerequisite available for InstallShield.  The prereq however is designed to only run on 32 bit machines, so I edited it in InstallShield and modifed the conditions to allow it to run on both 32 & 64 bit operating systems. 

The next problem encountered is that this 32 bit prereq getting installed on a 64 bit machine will result in an error being returned that the installation appears to have failed.  Well it is a 32 bit installation not intended for a 64 bit OS and we're not supposed to do that.  I did say hackish work-around.  The 32 & 64 bit files are installed to different directories and the 64 bit version does not get overwritten.   If you check the event viewer you'll see a message logged in that the installation of the ATL prereq completed sucessfully.  So I modified the behavior of the prereq in InstallShield to "continue the setup if the condition still indicates it is required after completion".  Now it runs without error and everything for Crystal installs sucessfully.

The final problem was also with the pre-requisite.  The code determines if it is already installed by looking for the file:

[WindowsFolder]\WinSxS\x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_473666fd\ATL80.dll

I found on some machines it was previousy installed to:

[WindowsFolder]\WinSxS\x86_microsoft.vc80.atl_1fc8b3b9a1e18e3b_8.0.50727.4053_none_d1c738ec43578ea1\

This results in the prereq being required every time because the file it's checkig for is not found.  Furthermore, it fails every time, most likely because it's alreday installed and not supposed to be installed again.  So once again, I modified the prereq conditios in InstallShield and made it look for the file in both locations to determine if it was installed.

I haven't seen any problems since with either the Crystal runtime or the ATL update.  Happy day.

The part I stll don't understand is that SAP says they can't distribute the ATL update in their MSM because of licensing issues, but we can sell our software and distribute it freely.  Microsoft even create the prereq so that we could distribute it freely.  So why can't SAP distribute the required files for their runtime?  A lot of people on these threads have wasted a lot of time and money on this issue.  Ludek provides great support but maybe this issue needs to be investigated further by development.

[former_member11696]

Hi Tim,

As for the hack work arounds you are doing in InstallShield I suggest to contact them as Ludek suggested in the post and ask them why you had to do it that way.

As for the Prerequisits in our Merge Modules that's the way it is for Merge Modules, you include CR's, Microsoft's and any other third party libraries your app may reference. It's the nature of merge modules. I believe Microsoft has a merge module for every dll, or did at one time.

And as Ludek indicated using Crystals MSI it includes all of the dependencies because we can package it as a complete app, same as what you are doing. This way its under your control, if we included everything then it may conflict with your dependencies or someone elses which could also cause an installer issue. It's better to include just our files in merge modules so you, the developer/install builder, can manage what gets distributed and only one copy of the files.

Thanks for the info and solution you managed to find... But log the issue with Bitness with InstallShield....

Don

[Former Member]

Thanks Don, not including the ATL update does make perfect sense as you explained it.

Now I have another question.  On your site, http://scn.sap.com/docs/DOC-7824 , you do have 32 & 64 bit MSIs for installing the Crystal fils, but you only have a 32 bit version o the MSM.  Is there any reason why you don't have a 64 bit version of this? 

[former_member11696]

Hi Tim,

For ease of distribution files it is simply easier to use the MSI. We actually had plans to stop creating the 32 bit ones also because Microsoft was going to do the same but too many people complained so we added them back in but 32 bit only...

Thanks again

Don

[Former Member]

Don,

I have been struggling with the same problem. Once i finally got a copy of the c++ merge modules and tried my newly build install package, i got the same error message as above.

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

So i decided to investigate how to order the installation of merge modules, which is not possible via an ordinal of some kind. The visual studio setup project determines merge module install order based on merge module dependencies. 

It seems that when the merge module for crystal 13_r4 was created, the only dependency specified was ".net framework."  See attached screen shot. This looks like the reason why even after adding the needed c++ msm's to the project it cannot install.

Would it be an easy fix to add the appropriate dependency merge modules and rebuild the package? It seems that the merge module's missing dependencies is the source of the problem.

[former_member11696]

Hi Michael,

THe reason we created the MSI redist package is to include everything we need to run. Merge Modules means you have to include all dependencies which als means the Framework dependencies.

Couple of things to try, use the MSI rather than the MM's to see if that resolves the 1904 errors, which typically indicates there is a missing dependency OR enable MSIExec install logging, it should indicate what dependencies are missing or why it failed to register a component.

Any tool is Dependency Walker, you can open every dll the reports an error and see what dependencies are required and then include the MM for them also.

Don

[Former Member]

But my only problem (which may be due to my full understanding of InstallShield) is how to put these EXE files into my InstallShield installation setup program so that they would run and install themselves before the MSM tries to run and install?

[former_member183750]

I'm not sure about that. Perhaps posting the query to InstallShield may be an idea?

Ludek

[Former Member]

We have moved from VS2008 to VS2010 and are required to use CR for VS2010.  We use InstallShield 2010.  Additionally, we distribute CR XI SP6 for our VB6 components.  We get same error (1904) as above on the CRVS2010 components.  I found the pdf article on distribution: "

Using Crystal Reports for Visual Studio 2010 Merge Modules (MSM) to create a Setup project".  I have included the dependencies listed and Microsoft_VC80_MFCLOC_x86.msm also (which is listed as a dependency for CR2008).  I moved these mergemodules in the order of installation to install prior to CRRuntime_13_0_3.msm.  Still no luck.  If I install the CRRuntime_32bit_13_0.msi before my install, my install works.  It appears to me that there is some dependency in your install that has not been documented in the article.  The msm does not have any dependencies listed.  How do we get a comprehensive list of dependencies for the runtime?  We've been using Crystal reports since about version 6.  Have never had these difficulties in installing the runtime before.  CR 14 does not have developer components, and CR2008 doesn't work with VS2010.  We're stuck!!  I've been working on this issue for a couple of weeks.  I've seen numerous articles requesting help and no real answer.  SAP passes the buck to Microsoft or InstallShield.  InstallShield passes the buck to SAP.  How about some help?

[former_member183750]

Hello James

Re. passing of the buck. Please note that if you create an install project using MS Visual Studio, the issue is not present...

As I do not have InstallShield 2010 available, all I can do is suggest couple of troubleshooting steps:

1) If it is a dependency that is missing, you should be able to determine that by using the Depends utility; continue with the install to completion, then open the dll that is throwing the 1904 error in Depends.

2) Using Process Monitor may also provide useful info. Again, on completion of the install, try to register the dll using regsvr32 while running Process Monitor. Check the ProcMon logs for any exceptions and "Access Denied" error messages.

3) I am not familiar with InstallShield at all, but it should be able to provide some sort of detailed logging(?). If InstallShield somehow hooks into MS Installer, then the MS Installer will create very verbose logs for you, perhaps there will be some useful info there.

- Ludek

Follow us on Twitter

Got Enhancement ideas? Try the SAP Idea Place

Share Your Knowledge in SCN Topic Spaces

[Former Member]

Depends tells me that ATL80.dll and IESHIMS.dll are missing, but both are present.  I've see many of your posts with this same answer as above, but adding those runtimes as merge modules or as stand alone install does no good.  Regsvr32.dll reports that the file (crtslv.dll) has an incorrect side by side configuration.

In my previous post I asked for a comprehensive list of dependencies.  Specifically those that you distribute in your runtime install package.  I presume that you're telling me that the VC ++ runtimes are the only dependencies.  But that just doesn't seem to be the case, since your runtime install installs the components and the stand alone VC ++ runtime installs don't.

This has been very frustrating and quite expensive in time spent.  Again, can you give me a list of any other dependencies you include in your install?

[former_member183750]

I do not have a list of dependencies. However, you can download the Orca utility from Microsoft, open the MSI in Orca and see all the dlls included in that MSI.

BTW.; perhaps when Depends is reporting that a dependency is missing it means that it is not available. E.g.; it is in a directory that is not in search path, there are not enough permissions, etc., etc.

- Ludek

[Former Member]

An examination with Orca reveals that your install is using version 8.0.50727.4053 rather than 8.0.50727.762.  However, there are no merge module downloads available for 8.0.50727.4053.  I tried updating an old install of VS2005 (as suggested in another thread) but the newest version is 8.0.50727.6195.  I tried adding that version to the install, but get the same error.  I built a simple install in VS2010 using a VS2010 setup project and an InstallShield LE (free limited edition) setup project.  Both failed with the same error.

The files reported missing by depends are there and in the search path and have appropriate permissions.

[Former Member]

We finall got CRforVS2010 dependencies to install.  We had to obtain the 8.0.50727.4053 version of the VC++ merge modules.  They are only available as updates to VS2005.  I installed VS2005 on a lab machine, updated to SP1, then downloaded only Microsoft Update for KB971090.  This updated the merge modules to ...4053.  We copied these to our build machine and built the install.  The install still fails when trying to register the crystal components, so we ignore all failures.  Then we immediately run a repair on the install and they register.  This will not work for distribution to our clients, but it is a step in the right direction.  Seems that the crystal msm is installed prior to the VC++ msm even if they are added to the Crystal msm as dependencies, thus the failure the first time through.  We've tried several techniques to order the install of the msm, but have not found the solution to that as of yet other than running your runtime installer.  If we have to do that, then the merge modules are useless.

Ludek, you might look into somehow getting the 8.0.50727.4053 msm available for download since your components require that specific version.  You might also download the free Installshield LE to test simple installs to make sure your components are distributable.  This has been a nightmare for us, and I'm sure it has been for other companies that use your components.

The only real help I found was an article re Crystal 2008 (http://scn.sap.com/thread/1480315)  in which this same issue occured.  That user obtained the correct msm in the same way and advised you, Ludek, of the procedure.  It would have been nice to know this from the beginning.  I only found that article when I discovered that your runtime installation used those merge modules.

[Former Member]

We never could get the VC++ merge modules to install before the Crystal merge module.  In the end we had to configure vcredist_x86.exe as an InstallShield prerequisite.  I assume that something similar can be done in a Visual Studio install project.  This caused the redistributable to install before any of the application files.  There was an issue in installing on x64. See http://community.flexerasoftware.com/archive/index.php?t-192056.html for help on that.

[anders_gustafsson]

It depends on the version of InstallShield. I was told it was trivial once you buy the full (ie 2000$) version... In the version that people actually can afford to buy... You hit bullet point #5 in the GUI and "Custom Actions". Add one after "After ready to install dialog", "Launch an executable". Enter the path where you have the patch and run it with and command line of /q:a

You do not need to add the file itself to the project, it will be included automatically.

Do that and Robert is your father's brother...