Hello everything is fine?
I’m getting the following error below and we’ve been trying to identify what it is for months, but without success. Can you tell us if there is any common error in Gembox that generates this message?
Tipo Arquivo (Archive type): HTML to Tipo Arquivo (Archive type): PDF
System.ComponentModel.Win32Exception (0x80004005): The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper…ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook hooks)
at System.Windows.Media.MediaContextNotificationWindow…ctor(MediaContext ownerMediaContext)
at System.Windows.Media.MediaContext…ctor(Dispatcher dispatcher)
at System.Windows.Media.MediaContext.From(Dispatcher dispatcher)
at System.Windows.Media.Visual.VerifyAPIReadWrite()
at …ctor(DrawingContext , , , )
at .()
at .(Boolean )
at .()
at .()
at . ( )
at GemBox.Document.PdfSaveOptions.67tg5rkvl9zwp8v7723mndgzuc3b4vj8 (DocumentModel , Stream , String )
at SC.SDK.PDF.WebAPI.Util.Converter.ConverterParaPDF(Byte documento, TipoExtensaoDocumento tipoExtensao, PropriedadesPagina propriedadesPagina) in xxxxxxx :line 63
at xxxxxx.ConverterArquivo(Byte arquivo, TipoExtensaoDocumento tipoArquivo, TipoExtensaoDocumento tipoArquivoDestino, PropriedadesPagina propriedadePagina) in xxxx :line 103
Today we have many projects connected with the old version. We try to upgrade vesion but this caused a lot of bugs on the systems. I will try the solution that you send to me and monitor how the system works. Thanks a lot for the support.
we get a similar error:
System.ComponentModel.Win32Exception (0x80004005): The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper…ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook hooks)
at System.Windows.Threading.Dispatcher…ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.Media.DrawingCollection.get_Empty()
at System.Windows.Media.DrawingGroup…cctor() — Ende der internen Ausnahmestapel berwachung —
at ? …ctor(Boolean , ? , Double )
at ? . ( ? , Boolean , Double )
at ? …ctor()
at GemBox.Document.PdfSaveOptions.67tg5rkvl9zwp8v7723mndgzuc3b4vj8 ? (DocumentModel , Stream , String )
at GemBox.Document.DocumentModel.Save(Stream stream, SaveOptions options)
at x2.Services.Pdf.Processor.Program.SaveToPdfInternal(DocumentModel documentModel, PdfConformanceLevel level, PdfReturningObject returnObject) at x2.Services.Pdf.Processor.Program.<>c__DisplayClass2_0.
We use the Gembox.Document NuGet v35.1265 which should have fixed the problem with the WPF dispatcher. In addition, we have implemented the recommended workaround using System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown as shown in your example.
Unfortunately, the above error still occurs. We believe that in our case, the above error with Gembox.Document v35.1265 occurs much more frequently.
We use Gembox.Document in an EXE to convert docx documents to PDF. This exe is restarted by a Windows service running as LocalSystem for each individual docx document and the exe is terminated after the conversion.
Start EXE, EXE converts docx to pdf, end or kill exe
again
Start EXE, EXE converts docx to pdf, end or kill exe
again …
What was fixed with regard to the WPF Dispatcher? As mentioned ee believe that in our case, the above error with Gembox.Document v35.1265 occurs much more frequently.
Hello Mario,
unfortunately the issue with NuGet package v35.0.1331 still exists.
We can’t reproduce the error on our developer machines unfortunately. The error also occurs irregularly with customers.
As already mentioned, we have integrated Gembox.Document in a .NET 4.7.1 EXE to generate a PDF from Docx. This EXE is started per document and terminated again after the PDF generation. Thus, all native Windows resources (handles) of the process should be released again after the EXE is terminated.
However, the exception indicates that no further system resources are available to generate a dispatcher when the EXE is (next) called with an error. That would mean however, Gembox occupies or uses global Windows resourcen, which are released possibly not again or not fast enough again? Is that so?
What would you recommend? Should the EXE perhaps not be started and ended per document? Would it be better for Gembox.Document regarding the dispatcher issue to start the EXE only once and then use this one instance of the EXE to convert all the docxs to PDFs?
Background info: The EXE is called by a Windows service running under the LocalSystem account, as said once per document.
Hello Mario,
we have opened a support ticket with further descriptions and uploaded a zip file with relevant parts of our source code.
Ticket: Login - GemBox Support Center