We currently run a Windows Service and process our conversions from HTML to PDF via Hangfire (www.hangfire.io). It doesn't happen all the time; however, at times, our servers will stop processing all jobs and it'll just hang. No errors from Hangfire or EO.PDF.

We've done a number of memory dumps and have analyzed them, and each time appears to show a deadlock from EO.PDF. In review with Hangfire, the following question came up:

I see that most of the workers are performing background jobs as expected, executing EO.Internal methods. What I also see is that there are a lot of thread pool threads blocked on the EO.Internal.nt.a method, and this looks like a deadlock that may occur due to the specifics of the Parallel.For (and Parallel.ForEach) method's implementation. And since EO.WebEngine.Engine.Start method (that's called by the EO.Internal) is itself blocked by a wait handle, the probability of deadlock is very high.

What do you think? We can check this consideration by avoiding to use Parallel.For methods, and execute them sequentially instead or schedule each conversion to thread pool via Task.Factory.StartNew (and await its unwrapped result).

Can you provide any guidance here? This is not something that is easily reproducible in a test project.

I've confirmed we are on the latest release. As I mentioned above, there are no errors thrown, we're just in a deadlock situation. I can send a link to download our 7GB memory dump if that will assist.