PDFsharp & MigraDoc Foundation

PDFsharp - A .NET library for processing PDF & MigraDoc Foundation - Creating documents on the fly
It is currently Wed Dec 13, 2017 7:03 am

All times are UTC


Forum rules


Please read this before posting on this forum: Forum Rules



Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sat Jul 30, 2016 8:18 am 
Offline

Joined: Sat Jul 30, 2016 7:45 am
Posts: 1
I have encountered a strange issue with MigraDoc. I use MigraDoc to generate PDF-files in ASP.NET website. I run this website in MS Azure as App Service.

Error occurs after calling MigraDoc.Rendering.PdfDocumentRenderer.RenderDocument() and the mysterious error is: "Win32Exception (0x80004005): The operation completed successfully". Stack trace is below.

This does not reproduce in my testing environment, which is also in Azure. I connected testing to production data. Production environment was working very well yesterday (and for weeks), but now it fails every time.

My website is not very popular and it gets like 1000 hits per day. It's safe to assume that only one PDF is generated at a time.

After some googling, it seems that this issue might be related to running out some resources.


Is there something I should know about running MigraDoc in ASP.NET application? Or in Azure?

Does anyone have any clue what is this issue and how to fix it?

Edit:
I am using WPF-version (MigraDoc.Rendering-wpf.dll) and version number is 1.50.3638.0.


Stacktrace:
Quote:
[Win32Exception (0x80004005): The operation completed successfully]
MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d) +96
MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks) +978
System.Windows.Threading.Dispatcher..ctor() +612
System.Windows.Threading.Dispatcher.get_CurrentDispatcher() +64
PdfSharp.Drawing.XGraphics..ctor(DrawingContext dc, XSize size, XGraphicsUnit pageUnit, XPageDirection pageDirection) +71
MigraDoc.Rendering.DocumentRenderer.PrepareDocument() +397
MigraDoc.Rendering.PdfDocumentRenderer.PrepareDocumentRenderer(Boolean prepareCompletely) +148
MigraDoc.Rendering.PdfDocumentRenderer.PrepareRenderPages() +22
MigraDoc.Rendering.PdfDocumentRenderer.RenderDocument() +16
Foo.Foo.Foo.CreateMinutes(TemplateModel model, Boolean withResults) +262
Foo.Controllers.ReportController.CreateMinutes(Nullable`1 id, Nullable`1 id2) +611
lambda_method(Closure , ControllerBase , Object[] ) +215
System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters) +209
System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters) +35
System.Web.Mvc.Async.AsyncControllerActionInvoker.<BeginInvokeSynchronousActionMethod>b__39(IAsyncResult asyncResult, ActionInvocation innerInvokeState) +40
System.Web.Mvc.Async.WrappedAsyncResult`2.CallEndDelegate(IAsyncResult asyncResult) +71
System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethod(IAsyncResult asyncResult) +43
System.Web.Mvc.Async.AsyncInvocationWithFilters.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3d() +72
System.Web.Mvc.Async.<>c__DisplayClass46.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3f() +386
System.Web.Mvc.Async.<>c__DisplayClass46.<InvokeActionMethodFilterAsynchronouslyRecursive>b__3f() +386
System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeActionMethodWithFilters(IAsyncResult asyncResult) +43
System.Web.Mvc.Async.<>c__DisplayClass2b.<BeginInvokeAction>b__1c() +30
System.Web.Mvc.Async.<>c__DisplayClass21.<BeginInvokeAction>b__1e(IAsyncResult asyncResult) +186
System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeAction(IAsyncResult asyncResult) +39
System.Web.Mvc.Controller.<BeginExecuteCore>b__1d(IAsyncResult asyncResult, ExecuteCoreState innerState) +29
System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +67
System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) +53
System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +36
System.Web.Mvc.Controller.EndExecute(IAsyncResult asyncResult) +39
System.Web.Mvc.MvcHandler.<BeginProcessRequest>b__5(IAsyncResult asyncResult, ProcessRequestState innerState) +44
System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +67
System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) +39
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +657
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +146


Top
 Profile  
Reply with quote  
PostPosted: Mon Aug 01, 2016 8:30 pm 
Offline
User avatar

Joined: Sat Mar 14, 2015 10:15 am
Posts: 308
Location: CCAA
Hi!
pjaakko wrote:
After some googling, it seems that this issue might be related to running out some resources.
A limit that does not apply to desktop applications.

I found this post:
http://stackoverflow.com/a/16298573/1015447

Maybe InvokeShutdown must be called inside the XGraphics class or somewhere else for long-lasting joy under MVC/Azure.
At the moment I have no idea where to do it. Or even how to replicate it.

I tried creating PDF documents in a Console application and I got 70000+ without any exception.
It seems the crash occurs after 10k.


I made a change to the "void Dispose(bool disposing)" method of the XGraphics class:
Code:
#if WPF
                if (_dc != null)
                {
                    _dc.Close();
#if !SILVERLIGHT
                    _dc.Dispatcher.InvokeShutdown();
                    _dv = null;
#endif
                }
#endif
It still works for a console application.

You can download the source for MigraDoc, apply this change - and hope your issue does not occur again.
Feedback will be welcome.

_________________
Best regards
Thomas
(Freelance Software Developer with several years of MigraDoc/PDFsharp experience)


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 03, 2016 5:38 am 
Offline

Joined: Tue Aug 30, 2016 10:56 am
Posts: 4
It has taken me a while, but I've finally been able to implement your suggested solution, although I put InvokeShutdown outside the #if !SILVERLIGHT because I think that is more correct, although I don't think it matters as I'm not doing anything with silverlight.

Code:
#if WPF
                if (_dc != null)
                {
                    _dc.Close();
                    _dc.Dispatcher.InvokeShutdown();
#if !SILVERLIGHT

                    _dv = null;
#endif


I only made this change today, so I will report back if any new exceptions occur or when it has run for about a month without any exceptions.


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 03, 2016 10:51 am 
Offline
empira Employee
User avatar

Joined: Mon Oct 16, 2006 8:16 am
Posts: 2740
Location: Cologne, Germany
Tarostar wrote:
It has taken me a while, but I've finally been able to implement your suggested solution, although I put InvokeShutdown outside the #if !SILVERLIGHT because I think that is more correct, although I don't think it matters as I'm not doing anything with silverlight.
Your code is slightly less correct (where "slightly" means "100%" :wink: ).
Your code leads to an error during compilation:
error CS1061: 'AgDrawingContext' does not contain a definition for 'Dispatcher' and no extension method 'Dispatcher' accepting a first argument of type 'AgDrawingContext' could be found (are you missing a using directive or an assembly reference?)

Please note that code inside "#if !SILVERLIGHT" is NOT used for Silverlight.
By placing that line before "#if !SILVERLIGHT" you break the Silverlight version.

Thanks for your feedback.
I'd be glad to get some more feedback from long-term testing.

_________________
Regards
Thomas Hoevel
PDFsharp Team


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 04, 2016 7:04 am 
Offline

Joined: Tue Aug 30, 2016 10:56 am
Posts: 4
Thomas Hoevel wrote:
Your code leads to an error during compilation:

That is interesting, because I got the latest source from github for both PDFSharp and MigraDoc and I compiled the enitre solution for both with no errors. I just rebuilt now to be sure with platform solution set to Mixed platforms which I understand to be all platforms... (I could be wrong). All the dlls were built, MigraDoc compiled and PDFs are being generated. Not sure why you are getting an error about first argument for Dispatcher when there are no arguments?

Thomas Hoevel wrote:
Please note that code inside "#if !SILVERLIGHT" is NOT used for Silverlight.
By placing that line before "#if !SILVERLIGHT" you break the Silverlight version.

Ok. Once this is tested I can move it to be inside of !SILVERLIGHT if that is correct. I'm not familiar with the PDFSharp source so I'm sure you are right, but I figured that since _dc.Close(); was done before !SILVERLIGHT and the only thing done inside the if test was to do with dv (i.e. _dv = null;) that everything related to _dc should be done in all cases of WPF regardless of SILVERLIGHT.

Thomas Hoevel wrote:
Thanks for your feedback.
I'd be glad to get some more feedback from long-term testing.


I appreciate the help very much, so the least I can do is provide feedback!


Top
 Profile  
Reply with quote  
PostPosted: Fri Dec 02, 2016 8:38 am 
Offline

Joined: Tue Aug 30, 2016 10:56 am
Posts: 4
Just an update. I've been running with your modification for one month now on a heavily used production server (IIS) and there have been zero exceptions! :D

I think you should put this into the next version.

Thank You!


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 20, 2016 5:40 am 
Offline

Joined: Tue Dec 20, 2016 5:17 am
Posts: 1
Tarostar, I also have an Azure AppService which is used to generate PDF files and in my Production environment I am seeing a spike in the time the PdfDocumentRenderer.RenderDocument method call takes for the exact same data/file. Usually the time increases after a restart of the AppService, i.e. it is around 3-4 seconds right after a restart for awhile, but then after a few days of running, it can spike up to 10s or even 34s for the same exact data/file/output.

Did you see that at all before you implemented the fix for the exception? I am wondering if the long running AppService is not releasing resources which is causing the fluctuating performance for the rendering and that your fix (although it was specific to an exception) is similar/related to the issue I am seeing.

Thanks for any insight you can provide,
Shannon G.


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 25, 2017 11:45 am 
Offline
User avatar

Joined: Sat Mar 14, 2015 10:15 am
Posts: 308
Location: CCAA
Update: Calling "_dc.Dispatcher.InvokeShutdown();" as suggested in this thread causes problems with WPF desktop applications.
See also:
viewtopic.php?p=11064&f=1#p11064

NuGet packages "1.50.4589-beta4" include this line, the next version will not.

To do: find a way that frees resources that are no longer in use without closing WPF windows that are still needed.
Otherwise the "server people" have to get and modify the source code ... :(

_________________
Best regards
Thomas
(Freelance Software Developer with several years of MigraDoc/PDFsharp experience)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: Bing [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group