System.ComponentModel.Win32Exception

GemBox.Document
#1

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

Parametros (Parameters):

{“MargemSuperior”:20.0,“MargemInferior”:20.0,“MargemEsquerda”:20.0,“MargemDireita”:20.0,“TipoFolha”:9,“Orientacao”:0}

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

#2

Hi Reinaldo,

What version of GemBox.Document are you using?
Please try again with the current latest version, does that solve your issue?

Regards,
Mario

#3

We have on our solution GemBox.Document version 25.3.30.1143 and GemBox.SpreadSheet version 39.3.30

#4

I see, note that those are old versions that have an issue with WPF Dispatcher.

You should either upgrade your licenses and use the latest versions, or use something like this:

public static class GemBoxExtensions
{
    public static void SaveSafe(this ExcelFile workbook, string path, GemBox.Spreadsheet.PdfSaveOptions options)
    {
        var thread = new Thread(() =>
        {
            workbook.Save(path, options);
            System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
        });
        thread.Start();
        thread.Join();
    }

    public static void SaveSafe(this DocumentModel document, string path, GemBox.Document.PdfSaveOptions options)
    {
        var thread = new Thread(() =>
        {
            document.Save(path, options);
            System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
        });
        thread.Start();
        thread.Join();
    }
}

I hope this helps.

Regards,
Mario

#5

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.

#6

Hello,

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.

#7

Just in case, can you please try again with the current latest version:

If the problem remains, can you send us a small Visual Studio project that reproduces your issue so that we can investigate it?

#8

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.

#9

Hi,

You mentioned this:

Start EXE, EXE converts docx to pdf, end or kill exe

Can you please share with us exactly how you’re executing this workflow?
We would like to recreate it and observe the GemBox behavior in that context.

Regards,
Mario

#10

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