Converting Docx to PDF sometimes fials in .Net 6 API

Hi

We have a solution where we in our .Net API use Aspose to generate dynamic reports, where our customers define a Word template which we then populate with data, converts to PDF, and then return the PDFdocument.

This works fine 99.9% of the time.

But today, registered for the third time in 3-6 months suddenly it breaks, and every function in the API creating a PDF from Docx is broken.

Restarting the API fixes the error, and all is good again.

It is not easy to recreate in a sample application as we have no idea to what happens or is causing this.

We get this stacktrace from our application.
System.ArgumentException: The namespace declaration attribute has an incorrect ‘namespaceURI’: ‘A Namespace Name for xmlns Attributes’.
at System.Xml.XmlDocument.AddAttrXmlName(String prefix, String localName, String namespaceURI, IXmlSchemaInfo schemaInfo)
at System.Xml.XmlDocument.CreateAttribute(String prefix, String localName, String namespaceURI)
at System.Xml.XmlDocument.CreateAttribute(String name)
at System.Xml.XmlElement.SetAttribute(String name, String value)
at #=z7btlXgHixUKCmbV5JB3IOmOtSn016nLAK3GsFXo=.#=z_AJkM7M=()
at #=zu6AdRgQQR8r3Yj$A4nwTdAAIOd9CKWZqK1wOWSY=.#=zLuZ_80fCIoLC(XmlWriter #=zwAMIOpE=, #=zSxFGcqTS98TiTLFs5WUEvdKLW2sb15FgzEH9pYM= #=z4ckI9p8=)
at #=zu6AdRgQQR8r3Yj$A4nwTdAAIOd9CKWZqK1wOWSY=.#=zLuZ_80fCIoLC(Stream #=zRtGho4o=, Int32 #=zzovA47A=)
at #=z2bf_Y9PL$CLSpDtNy_vJP_3AxAXFkUQNwFU4osU=.#=zCYeAl50=(#=zu6AdRgQQR8r3Yj$A4nwTdAAIOd9CKWZqK1wOWSY= #=zJeHmlck=, Boolean #=zeKj$kFwu5Sz_)
at Aspose.Pdf.Document.#=zfFL1ws0=(#=z8bUdn7NB3HniUI$5rsmHmMh_8aU3 #=z4pQ1zvM=, Metadata #=zINv2DAA=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zlSFtZF3LWTWDymgFL$Dmg2Dut09Kwwg4JvfrkDc=(Object #=znWxZeC0=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zcOMt1$BywVdYJE3Ujt5qKW$3LD6PY$UvVl5hwbM=(MethodBase #=znWxZeC0=, Boolean #=z0q$sHwg=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zJIXFSVJDdx$Q5Bnh2osjoKU=(#=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI= #=znWxZeC0=, #=qfTjkMLvhcrB7qxIOrZgPBNk_hKdLj9eQcG6djEAg8HU= #=z0q$sHwg=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=z63onGMbEV0HXUrC48hZr$HxSWsR6eDg25A==()
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zsjK_fV9uaEWWRq10faifSNFz3bXWXg65xw==(Boolean #=znWxZeC0=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zlSFtZF3LWTWDymgFL$Dmg2Dut09Kwwg4JvfrkDc=(Object #=znWxZeC0=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zar9iKCrjVfcTtHldpK3T4KoCC4A5VHJEWKWD1VEijAZi()
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zRwnJkxaXRO4$$qyMqxd_2dIlya5a(Object #=znWxZeC0=, UInt32 #=z0q$sHwg=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zsjK_fV9uaEWWRq10faifSNFz3bXWXg65xw==(Boolean #=znWxZeC0=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zB__sY1nnx$ESQCDkJcSG1TjkLydDAfB2oiy9kOQ=(Object[] #=znWxZeC0=, Type[] #=z0q$sHwg=, Type[] #=zx1hOoR8=, Object[] #=zDQZuDLg=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=z$pgZ5tp_J$X5EIpXGGHxKXLjuBazFwH9Jg==(Stream #=znWxZeC0=, String #=z0q$sHwg=, Object[] #=zx1hOoR8=)
at #=qcfljQivUJApbEjFoNUmIJZrVRINIisFMc9ncnhlLhVI=.#=zo_48T5IxlBNxPdRWmMB_CLissqoDV48HT2dZlso=(Stream #=znWxZeC0=, String #=z0q$sHwg=, Object[] #=zx1hOoR8=)
at Aspose.Pdf.Document.#=zWpTMNTSWhKCW(Stream #=z39JYGBU=, SaveOptions #=z7E92puekiEfC)

In this case we just seem to call Aspose.Pdf.Document.Save() and not much more.

We are running in production with Apose 21.12 at the moment.

Is this a known bug that you have fixed in the last year. Or is this new to you. Or are we doing something wrong?

I hope you are able to provide some feedback though I am fully aware that we have very little information to start from.

Best regards
/Anders

@licenselogimatic,

Is this problem repeatable when you want, or it just happens sometimes?

That is a good indicator that it may be other issues than just the code. There may be some memory leak, lack of storage, network problems, etc. There are many possibilities for issues that are not repeatable on command.

Also, a good indicator to figure it may be a machine issue is if those document that fails work after you restart your API. This doesn’t rule out an API problem, but maybe some of your code is leading to this issue.

I would download the latest version of Aspose.Pdf, which came out this week. Version 23.3, and test it out. There have been so many improvements from the one you are running.

Also, I have not heard or read on the forums that 21.12 was giving those issues. Or when that version came out, the forum would have been flooded with complaints.

I hope this answer helps you in some way.

Hi Carlos

It is not repeatable, I have no idea how to reproduce it.

From the outside it doesn’t seem to be memory leaking, although I am well aware that this is hard to see from the outside.

We have many customers hosted on same server, with their own API’s, so have multiple API’s running side-by-side. The faulty API had not used more memory than the others running, and only one customer had the problem. So doesn’t look like a machine issue.

It was a long shot asking the forum to see if anything came up.

But if you have no guidance we will plan for an upgrade of Aspose, but there is no way I can verify it helps beforehand - or after upgrading as this only happens very rarely to us.

Luckily we rarely run into new issues when we upgrade Aspose.

So fingers crossed.

/Anders

@licenselogimatic,

I hope the upgrade helps to solve this issue. They are the worst ones. But if you ever figure out what may be causing them, don’t hesitate to contact us. And if it is replicable, I will create a ticket for the dev team ASAP.

1 Like