cxlibw-5-0.dll was not found

[Former Member]

Hi All,

  We are using Crystal for 2010 SP3.  To optimize performance, we are loading the crystal framework in the background by using the following code:

    Public Class frmMain

        Inherits ProjectBaseForm

        Public Sub New()
            MyBase.New()

            'This call is required by the Windows Form Designer.
            InitializeComponent()

            Dim t As New Thread(AddressOf LoadCrystalFrameworkBackground)
            t.Start()
        End Sub

        Private Sub LoadCrystalFrameworkBackground()
            Dim crv As New CrystalDecisions.Windows.Forms.CrystalReportViewer
            Dim rpt As New CrystalDecisions.CrystalReports.Engine.ReportDocument()

            Thread.CurrentThread.Abort()

        End Sub

       End Class

However every once in a while we are getting the following error message: 

"This application has failed to start because cxlibw-5-0.dll was not found.  Re-installing the application may fix this problem."

The error message is not consistently reproducable.  We'll run the program the first 20 times and everything will be fine.  Then run it and this error message shows up.  Looking for any causes or anything we can do to avoid this.  Note we are experiencing this from workstations where we have had the plug in for visual studios installed and also from workstations where we've had just the redistributable installed.

Any advice greatly appreciated.

[Former Member · Accepted solution]

I do exactly the same thing, and have exactly the same problem.

**** EDIT 2 ******

Found the solution based on the conclusion in the first edit.

I am now able to start my app a 100 times without any error (was: about 1 error in 5 times opening)

Add the following code to your app (VB.Net) - this will add the correct folder to the searchpath of your application so the dll's will be found:

<System.Runtime.InteropServices.DllImport("user32.dll", SetLastError:=True)> _

Public Function SendMessageTimeout(ByVal windowHandle As IntPtr, ByVal Msg As Integer, ByVal wParam As IntPtr, ByVal lParam As IntPtr, ByVal flags As Integer, ByVal timeout As Integer, ByRef result As IntPtr) As IntPtr

End Function

Public HWND_BROADCAST As New IntPtr(&HFFFF)

Public Const WM_SETTINGCHANGE As Integer = &H1A

Public Const SMTO_ABORTIFHUNG As Integer = 2

Public Sub SetCrPath()

Dim CrPath As String = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) & "\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\"

If Environment.Is64BitProcess Then

CrPath &= "win64_x64"

Else

CrPath &= "win32_x86"

End If

Environment.SetEnvironmentVariable("path", Environment.GetEnvironmentVariable("path") & ";" & CrPath)

SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, IntPtr.Zero, Runtime.InteropServices.Marshal.StringToHGlobalUni("environment"), SMTO_ABORTIFHUNG, 5000, IntPtr.Zero)

End Sub

Public Function Main() As Integer

SetCrPath()

'rest of the code

End Function

**** END EDIT 2 *****

**** EDIT ****

The solution below is causing the next dll to be not found.

If you use the process monitor, you can see that the files are really not found, because the correct locations are not in the search path of the os.

And for the record: this is done on the development machine.

The problem only occurs in the compiled version, not within visual studio.

***** END EDIT *****

Solution for 64 bit machines:

Copy

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win64_x64\cxlib-5-0.dll and cxlibw-5-0.dll to C:\windows\system32

and

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\cxlib-5-0.dll and cxlibw-5-0.dll to C:\windows\syswow64

Solution for 32 bits machines:

Copy

C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\cxlib-5-0.dll and cxlibw-5-0.dll to C:\windows\system32

And the problem is solved (at least at my side).

Regards,

Theo

[Former Member · Accepted solution]

Hi Theo,

My apologies on not respoding sooner . . . I never got the notification that this had been replied to again.

We're looking into this as a possible solution.  Thanks very much.

-Kyle

[Former Member · Accepted solution]

And so?

I have experienced exactly the same issue (using the latest VS2010 plugin and runtime installer) , and furthermore multiple other DLLs are reported as 'missing', i.e. all together I have had the following DLLs reported as missing:

cxlib-5-0.dll and cxlibw-5-0.dll

boezlib.dll
TraceLog.4-0.dll

Icuuc30.dll

Icudt30.dll

BCM-4-0.dll

The errors with the DLLs were resolved by copying them from the install path c:/program files etc etc (Windows 7 Pro 32bit system) to the windows/system32 folder...

Which is leaving me worried that once a different 'type' of report is used it will complain about a different DLL missing and crash the program?!?!?!?!?!?

What is the problem so I can resolve it permanantly? Is the installer buggy and not registering all it's DLLs?

EDIT:- with thanks to Theo I made a few amendments to his solution to get it working for C# and it seems to work nicely...

public void SetCrystalReportsPath()

{

               string crystalReportsPath = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) + "\\SAP BusinessObjects\\Crystal Reports for .NET Framework 4.0\\Common\\SAP BusinessObjects Enterprise XI 4.0\\";

               if (Environment.Is64BitProcess)

               {

                    crystalReportsPath += "win64_x64";

               }

               else

               {

                    crystalReportsPath += "win32_x86";

               }

               Environment.SetEnvironmentVariable("path", Environment.GetEnvironmentVariable("path") + ";" + crystalReportsPath);

               IntPtr intPtrZero = IntPtr.Zero;

               SendMessageTimeout((IntPtr)0xffff, 0x001A, intPtrZero, "Environment", 2, 5000, intPtrZero);

}

[former_member200290]

I have some experience with Crystal and multithreaded applications. I have not seen or run into this before but have never tried this on the creation of a form.

Now the general rule for threading and Crystal Reports  is to

• Keep the ReportDocument object contained inside its own thread.
• Do not pass ReportDocument objects between threads.
• Do not reference ReportDocument object in  thread from outside the tread.

The only exception is the main thread should be fine.Now if your task is just to load the runtime in the background, then I would skip creating the CrystalReportViewer, you will get a greater benefit by just creating the ReportDocument object and loading a report with it, as the load will cause more of our runtime to be loaded. Try doing this instead and see what happens.

Kind Regards,

Trevor Dubinsky

[Former Member]

Trevor,

Thanks for the reply. The goal is to load as much of the runtime as we need at the startup this way by the time the user gets to the report in the application the framework is already loaded and therefore a good user experience.

The new thread is spawned, then the ReportDoc is created.  The thread is then aborted and the Report doc isn't being referenced anywhere else so it doesn't violate:

Now the general rule for threading and Crystal Reports  is to 
Keep the ReportDocument object contained inside its own thread.  
Do not pass ReportDocument objects between threads.  
Do not reference ReportDocument object in  thread from outside the tread.

The performance of the application and loading of the report itself is fine once we add this code.  But we need to address the dll issue. 

Thanks.

[former_member200290]

Hi Kyle,

This would be something I would need to test on my side, but at this point it is not something I could look at until at least next week. The next steps in testing this would be to narrow down what is causing the issue creating the report object or creating the viewer control.

My gut feeling on this is that it is the viewer control that is causing the issue. Handling controls and updating UI has to be handled through delegates and depending on what assumptions made by our developers who knows what may be happening. So I would suggest comment out the viewer code and just use the report code and see what happens.

Again it is the reportdocument.load method on the report that causes the biggest delay in code as it really opens our report engine and causes the database layer and extra dlls to be opened. Just having our viewer control on a form really doesn't havemuch of an affect.

Kind Regards,

Trevor Dubinsky

[Former Member]

Hi Trevor,

Thanks for the input.  Just for full disclosure we upgraded to service pack 4 yesterday (saw it was released last week). 

If we encounter the error again we will take out the Report Viewer to see if that helps.  Will keep in communication regarding this.

Thanks for the suggestions.

-Kyle

[Former Member]

Hi Trevor,

Just an update that we are still getting the error with SP4.  We're going to remove the Report Viewer and will let you know if we encounter the error again.

-Kyle

[Former Member]

Hi Trevor,

Even with the report viewer commented out we are still getting this error.  It has to be in the instantiation of the CRV or one of it's underlying objects.

I'm going to switch the lines to see if the report document will throw an error, but as the CRV takes the longest to load we'd appreciate if there's some kind of work around to avoid getting this popup so we can continue to load it in the background.

Please let me know what we can do.

Thanks.

[former_member200290]

Hi Kyle,

I have run this through over a 100 times and I cannot get the error even with the viewer code. It would be interesting to know if your error happens with just the viewer or just the report document or both.

What OS are you testing on? Does your main form do anything after it shows?

Kind Regards,

Trevor

[Former Member]

Hi Trevor,

We've tried this on both a windows XP (32 bit) machine and a server 2008 machine (64 bit but the apps run in 32 bit mode) and have seen the error message.

We're running various version of the .Net Framework (depending on the sub app . . . see below) with windows forms.

I can confirm that it happens when just the report document is the only thing in their (and hence can occur with both).  We're waiting to see if it just happens with  the report viewer.  Like I said the message is sporadic . . . sometimes we don't see it for a week and then other times it happens within a day or two.

I'm trying to get you something reproducable but we haven't been able to isolate anything concrete yet.

Our full workflow looks like this:

1)  Call a single signon app to login to our applications

2)  Launch a sub application

3)  Sub application MAY call another sub app (we only have a max depth of 3 so far).

4)  Any sub app that uses crystal will call that sub routine.

For some of our sub apps, there are standard data calls to the database (either populating a datagird or loading a record from the DB but nothing weird there.)   One app where we get this error it just loads and then waits for user input (no calls to DB.  Waits for user to click a button to load a second form so they can select a record).

We also use a control suite called Janus but I don't think that should have anything to do with this error.

I will let you know if we encounter the error with the report viewer.  I know the intermittent errors are the hardest to work on and appreciate the help.  If you have any other thoughts would be glad to hear them.

-Kyle