General failure when trying to deploy OCR on client machine

When trying to deploy a C# app using OCR the application throws the following error:

LEAD Error: General failure

at LTRASTERDOCLib.LEADRasterDocumentClass.Recognize(Int16 iStartPage, Int16 iPageCount) ...

This application has been deployed on two other clients and works.  I've tried comparing to one of the working clients and as far as I can tell, everything is the same.  I've tried copying the entire LeadTools folder from the working client, compared system32 files and ensured that files were registered...all to no avail.  Does anyone have a suggestion on what to look for?

Thanks for any help!

Copy all files in the OCR\Redist folder in the:
 \Program files\LEAD Technologies, Inc\LEADTOOLS 14.5\Redist\OCR

And make sure that your main program points to the OCR files in the other folder using the EnginePath property (I.e. set the RasterOCR.EnginePath property)  This will tell our .NET classes where the OCR files are located.

Let me know if this helps


Thanks,
Ali Abo Al-Rob
LEADTOOLS Technical Support

First of all, I'm using version 14 with the patch applied not 14.5.  Our application resides on our server and is run using a mapped network drive.  We have two other machines using the same version/patch combination running our application across our network and they both work.  On the new machine, originally I installed from CD and then applied the patch, but since then I've copied over the entire \Program files\LEAD Technologies, Inc\LEADTOOLS 14 folder and subdirectories from a working machine (just to make sure I have everything it needs and the right versions) and it still doesn't work. 

I searched through our source code and config files, but saw no mention of an EnginePath property.  So I'm not sure how the files are being located, but since the Leadtools directory is the same as the machine that works, the files should be visible.  I've insured that the MSVCRT.DLL, MSVCIRT.DLL, MFC42.DLL, MSVCP60.DLL, OLE32.DLL, OLEAUT32.DLL, OLEPRO32.DLL files are in the \Windows\System32 folder and they are all the same or newer than what is in the Leadtools folder (they are the same version as the working machines are using in their System32 folders).  Am I missing a file in the System32 folder? 

Thanks for your reply!

Since you are using C#, I thought at first that you were using our .NET OCR classes. But since you're using the COM objects, there is no EnginePath property. Instead, you need to place the OCR engine files in the same folder where you register the OCR COM object.

In your previous post, you mentioned the problem happens when you call Recognize. Does this mean the Startup and other methods, such as AddPage and FindZones work? Does the problem happen always or does it depend on the image being recognized?

Thanks,
Ali Abo Al-Rob
LEADTOOLS Technical Support

We are calling both AddPage and AddZone methods from the LEADRasterDocumentClass successfully just before the call to the Recognize method.  This problem always happens on this new machine. 

The images that are being loaded are queued in a database and the other machines will later process the same TIFFs without any problem (each instance of our program pulls images from the same queue, but each instance locks the image while it's being processed). 

Thanks for you continued help. 

Okay, it's finally working now, but here are the steps I had to follow. 

1)  I installed the v.14 SDK on the client machine

2)  Overwrote the files with the v.14 patch

3)  Ran the MFC OCR demo (inserted a page then recognized the text)

Our application would not run and continued to throw the "General failure" exception until step 3 (the demo) was run.  One of our production machine's OCR stopped working due to an abrupt loss of power and was also throwing a "General failure" exception.  Following this procedure fixed that machine as well.

Apparently something is being installed or intialized when the demo runs, that our application either isn't doing or can't do.  Any ideas what it might be?  While our only deployments are in-house, I'd rather not have to go through the headache of installing the entire SDK just to get a client running.

Thanks.

Since our demos work so it might be problem in your sample. does you sample failed with specific images or with all images?

please put your code in a very small project and send it to me in a ZIP file. (Please don't send your full application) along with the exact steps to reproduce the problem, I want the code to behave just like yours.


Thanks,
Ali Abo Al-Rob
LEADTOOLS Technical Support

Our application's call to your API fails on all images.  However, the same image it fails on, another machine running the same application will process just fine.  So, I would think this has to be a DLL that isn't properly registered or loaded and your demo must be registering it. 

After the previously mentioned "solution", the application runs fine even after rebooting the machine.  Therefore, it can't be a matter of your application merely loading a file into memory that our application can afterwards access.  Rebooting would have cleared it out of memory. 

Can you please look through your MFC OCR demo and see if any DLLs are being programmatically registered?  I can put together a scaled back version of our application, but it'll take some time because of the way it's integrated into our system.  Unfortunetly, because of the time already spent on this issue my task list has become quite large.

Any help would be greatly appreciated.

Thanks.