Craxdrt.dll

[Hermalindo Lepicier]

Downloadcraxdrt.dll below to solve your dll problem. We currently have 1 version available for this file.

If you have other versions of this file, please contribute to the community by uploading that dll file.

Errors related to craxdrt.dll can arise for a few different different reasons. For instance, a faulty application, craxdrt.dll has been deleted or misplaced, corrupted by malicious software present on your PC or a damaged Windows registry.

In the vast majority of cases, the solution is to properly reinstall craxdrt.dll on your PC, to the Windows system folder. Alternatively, some programs, notably PC games, require that the DLL file is placed in the game/application installation folder.

Do you have information that we do not?

Did our advice help or did we miss something?

Our Forum is where you can get help from both qualified tech specialists and the community at large. Sign up, post your questions, and get updates straight to your inbox.

As I need to run the VB6.0 application and the report in a different machine. I have copied the craxdrt.dll file into the new system and when I try to register the craxdrt.dll file into the registery by putting the file into the C:\WINNT\System32\ folder and goind to the command window

Please let me know how can I register the craxdrt.dll file for 11.5.8.826 version from the command window, for accessing the dll reference from the VB6.0 applicaion code. I have the reports developed in the Crystal reports XI R2 SP2 version, which I need to run in the new systems with VB6.0 code.

It looks like you haven't deployed the necessary merge modules. You can't just copy over the craxdrt.dll and try to register it. There are too many dependencies. Manual deployment of the necessary runtime files hasn't been supported since Crystal Reports XI (v11.0). You will need to create a Report Designer Component (RDC) distribution package. Here's some information that should help.

These documents were written for CR XI (v11.0), but the process is the same for CR XI R2 (v11.5). You just need to use the v11.5 merge modules. You can find links for downloading the merge modules in the sticky post at the top of this forum.

Eventhough I was not able to register the craxdrt.dll 11.5 version in the above machine, I was able to register the Craxdrt.dll 11.0 version in the machine. And my Crystal Reports 11.5 were working properly with the craxdrt.dll 11.0 version in the Windows 2000 machine now, without any difficulty.

When I am trying to register the craxdrt.dll version with the Windows XP machines, I was not able to register both the 11.0 and 11.5 versions of the craxdrt.dll , because of which the reports are not working. Please suggest the solutions for this problem in XP machine.

Try getting to Service Pack 6 for both your DEV PC and the runtime Merge Modules as Dan suggested. It is actually easier to copy your keycode using LicenseManager.exe, uninstlal CR and then download Service Pack 4 and SP 5 and 6. I recall there was an issue with earlier versions of craxdrt having the same GUID ID for both versions.

Also I found out that the crdb_oracle.dll is not registered though it should get registered automatically duing the installation of merge modules for SP2 R6 version in the system. Then when I tried the manually register the crdb_oracle.dll versions 11.0, 11.5, 12.1 by RegSvr32 through command prompt, I am getting the error:

For checking whether the Crystal Installation was installed properly in the XP machine, I unistalled the Crystal Reports SP6, SP5 and SP4 Full build from the XP system and then again reInstalled the Crystal XI SP4 Full build on the XP machine. I am getting the following error messages during the installation for which I pressed 'Ignore' to continued with the Installation:

When you get this error it typically indicates some dependency is missing. If you use a tool Called Depends you can open up that dll and it should tell you what it's missing. Likely some C++ file like msvc dll.

We are doing some ground work on which Version and Service Package to select. Hope if we select the appropriate version then half of the work should be complete. We were not clear with the version of Crystal Reports last time but as per the advise we received from SAS forums, we initially tried with Crystal Reports Version XI Service Pack 2 but it was not working and after that we tried with SP3,4,5 but it was not working either and finally the XP machine got corrupted.

Could you please mention the Service Pack. Since our XP machine got corrupted when we tried installing SP 2,3,4 and 5. But it was not working. In our initial installation we registered the below mentioned (merge modules)msm packages

We have a legacy VB6 application that uses Crystal Reports XI to generate printed reports. We've found through experience that the Crystal Reports print engine crashes if it picks up the wrong version of usp10.dll (the Windows Uniscribe library).

One customer is consistently having printing issues on their Windows 7 machines (running Windows 7 Enterprise, 32-bit). However, we have a few other customers running various editions of Windows 7 that are not having any problems.

On one of the machines that was having printing issues, I noticed that there was an older version of usp10.dll (one incompatible with Crystal Reports XI) in the folder C:\Program Files\Common Files\Microsoft Shared\Office10\. I'm not sure what application installed these files, because the customer doesn't have Office 2002 installed (so I assume another application installed them). However, I temporarily renamed the file and our application was able to print correctly, so it seems that our application was loading that version of the file originally, which was causing the crashes.

The crash only happens the moment the user tries to print a report. Our application has direct dependencies on craxdrt.dll (the Crystal Reports ActiveX Designer Runtime library) and crviewer.dll (the Crystal ActiveX Report Viewer library), and the crash happens whether we print directly through craxdrt.dll or through the Report Viewer control.

In the past, we have resolved this issue by copying a known good version of usp10.dll into our application's directory and creating an .local file to enable DLL redirection. At the customer site, I tried this, and also tried the alternate approach of creating a .local folder for our EXE and placing the usp10.dll in there, but neither approach worked on the machine I was connected to.

I did notice that usp10.dll is a "known" DLL in Windows (it has an entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs), but I tested our application on another Windows 7 machine (running Professional Edition, 32-bit) here that also had the DLL listed as a known DLL in the registry, and by using Dependency Walker, I could see that the redirection was working on that computer. This is somewhat confusing, since the Microsoft documentation states that known DLL's cannot be redirected. Also, as I implied in the question title, our main EXE does not use a manifest file (the Microsoft documentation states that the presence of a manifest, embedded or standalone, disables DLL redirection).

So, my question is, is there any other reason why DLL redirection would work on some machines and not others, and does this have anything to do with differences between Windows 7 and Windows XP? I had considered deleting everything in the KnownDLLs registry key, but since the redirection was working on a machine here that had the same set of KnownDLLs, I'm not sure that would actually resolve the issue, and I don't want to delete that key if I don't need to. I haven't yet had a chance to connect to the customer's machine again to run Dependency Walker, but I'm not sure I would be able to interpret its logs anyway (even on the machine where it was working, I saw a lot of LoadLibrary calls for usp10.dll pointing to a folder other than the redirected folder, but some calls were apparently redirected, so I'm not sure what that means either).

EDIT: I should have also mentioned that every computer we've checked also has another copy of usp10.dll in the System32 folder. Looking at Chris's answer and this blog post by Larry Osterman explaining a bit more about how known DLLs work, I realized that that probably doesn't factor into the problem at all, since our program isn't loading the copy of usp10.dll that is in the System32 folder.

EDIT #2: After playing around with Dependency Walker some more on my VB6 development machine (Windows XP SP3), where the printing has always worked, I was able to glean some information. I profiled our application in Dependency Walker and set it to log full path names, and it looks like one of the Crystal Reports dependencies (another Crystal Reports DLL) tries to load usp10.dll from multiple (hard-coded) paths before giving up and just asking for it by filename. It turns out that it tries to load it from the Crystal Reports bin folder first, then tries to load it from from C:\Program Files\Common Files\Microsoft Shared\Office10\usp10.dll. If it can't find it at either location, it just asks Windows for usp10.dll (which will grab the one in System32). But even this isn't consistent. Sometimes it asks for the file in the Office10 folder, and then appears to ignore the fact that it couldn't find the file, while other times there are a series of LoadLibrary calls where it looks like the Crystal Reports code is actively looking for alternate copies of the file in different locations. Even more confusing is that at least one of the Crystal Reports components looks like it actually has a load-time dependency on usp10.dll, so that component always seems to get the copy in System32.

I'm still not 100% clear why the .local redirection wouldn't work in this situation on this customer's computers, but I think that partly explains why this particular customer is having problems, since all of the computers with the problem have an Office10 folder with an apparently incompatible version of usp10.dll in it.

3a8082e126