I have been testing your HtmlToPdf conversion tool for use in a solution I am working on. I need to use the tool in a multi-threaded windows service, but I ran conversions in a console application for testing purposes. The solution I am working on reads data from a database and generates html on request. Each request typically consists of quite a few html documents (an average of perhaps 200-400) of varying size and complexity. I loop through the documents and convert each to pdf, then examine the results object for certain known Element IDs. When I find the Element IDs (if they exist), I save their location for use later. I do not try to write to the request object or even to the generated PDF at this point. The PDF is saved, and I am done with the EO.Pdf assembly. For each request, this process happens several hundred times in succession.

I am using build 4.0.25.2

Testing was going very well until I built the tool into a test service. I never saw any errors when running the process via a console application. However, when I call ConvertHtml inside the service, every so often, the following exception is thrown:

[System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at EO.Pdf.Internal.df.aq.Invoke(IntPtr A_0, String A_1) at EO.Pdf.Internal.df.b(IntPtr A_0) at EO.Pdf.Internal.df.a(g A_0, Int32 A_1, Int32 A_2, Int32 A_3) at EO.Pdf.Internal.df.m.Invoke(IntPtr A_0, String A_1, String A_2, Boolean A_3) at EO.Pdf.Internal.df.a(String A_0, Boolean A_1, String[] A_2, Byte[] A_3) at EO.Pdf.Internal.df.a(String A_0, Boolean A_1, Boolean A_2, Int32 A_3, t A_4, String[] A_5, Byte[] A_6, h0 A_7) at EO.Pdf.Internal.df.a(HtmlToPdfOptions A_0, String A_1, Boolean A_2) at EO.Pdf.Internal.df.b(HtmlToPdfOptions A_0, String A_1, Boolean A_2) at EO.Pdf.Internal.df.a(hi A_0) at EO.Pdf.Internal.lo.c.a(hi A_0) at EO.Pdf.Internal.lo.c.a(Byte[] A_0)]]

So far, the exception has been unpredictable. It happens at different points in the process and with different generated html documents each time. Any insight into the problem and possible solutions would be greatly appreciated.

I have been working on a project to emulate the service we are building, and so far I have not been able to reproduce the exact error we are trying to resolve here. However, in the project I have built, I do receive a different error once I begin threading requests. When I run 9 threads, I very quickly get an IndexOutOfRangeException. (Stack trace below). I would be happy to zip the project up and send it to you for review; perhaps the errors are related. The solution has both a console app and a service, and both produce the same exception.

I am using the latest build as of last Friday. I am still trying to reproduce the AccessViolationException.

Stack trace from the error above:
System.ArgumentException occurred
Message=Source array was not long enough. Check srcIndex and length, and the array's lower bounds.
ParamName=""
Source=mscorlib
StackTrace:
at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
at System.Collections.Generic.Dictionary`2.Resize()
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at System.Collections.Generic.Dictionary`2.set_Item(TKey key, TValue value)
at EO.Pdf.Internal.mp.a(Int32 A_0, Single A_1)
at EO.Pdf.Internal.gf.a(Int32 A_0)
at EO.Pdf.Internal.ev.a.a(i2 A_0)
at EO.Pdf.Internal.ev.a(gf A_0, i2 A_1)
at EO.Pdf.Contents.PdfTextContent.a(br A_0)
at EO.Pdf.Contents.PdfContent.b(br A_0)
at EO.Pdf.Contents.PdfContent.a(br A_0)
at EO.Pdf.Contents.PdfTextLayer.a(br A_0)
at EO.Pdf.Contents.PdfContent.b(br A_0)
at EO.Pdf.Contents.PdfContent.a(br A_0)
at EO.Pdf.Contents.PdfContent.b(br A_0)
at EO.Pdf.Contents.PdfContentContainer.i()
at EO.Pdf.PdfDocument.a()
at EO.Pdf.PdfDocument.Save(String fileName)
at IppEmulationClasses.CIppEmulator.Emulate() in C:\MISC\IPPEmulation\IppEmulationClasses\IppEmulationClasses\CIppEmulator.vb:line 77
InnerException:

Hi,

Please download the latest build from our download page (4.0.29.2) and see if that fixes the problem for you. We did fix one threading issue recently but we have not seen it causing the error you posted. However we have not been able to reproduce the problem with the test app you sent to us on build .29.

Thanks!

Then we are having a little trouble here ---- your test app is still running with no problems. We will try to run it on a different machine and see if it gives us a different result. We will have to see the problem in order to find out exactly what's causing it.

Thanks!

Hi,

Thank you very much for the suggestion. We have reproduced the problem. We are still investigating it but it does appear to be a bug in our code. Once confirmed we should be able to get you a fix either late today or tomorrow.

Thanks!