The namespace declaration attribute has an incorrect ‘namespaceURI’: ‘http://www.w3.org/2000/xmlns/’

Hi,

We got this error on a PDF save:

(Stack Trace Level 1) The namespace declaration attribute has an incorrect ‘namespaceURI’: ‘A Namespace Name for xmlns Attributes’. at #=zNNpBdbFbFCsnz7oJFf7pINXHcghi5dJkTAwjJNw=.#=zoCZ2ipY=()

at #=zBss$sH9hwsVhlw49xR$Ve9nmB5Q7OkInen2bqYI=.#=z3xU2l7XleUfG(Stream #=zNKLhlGg=, Int32 #=zDwrL8VM=)

at #=z8wVmTvg2mzL$Dv97mfEy3tZ$lghiVUiXMDpOGKM=.#=z2NgTANs=(#=zBss$sH9hwsVhlw49xR$Ve9nmB5Q7OkInen2bqYI= #=zHMYoRFg=, Boolean #=zdNRHd2yKshVQ)

at Aspose.Pdf.Document.#=ztDMmz5Y=(#=zckWu7wdh5nUe3Kp28SZtG5eBlT$L #=ziEJ85EQ=, Metadata #=zGXHb9_k=) at (Object, Object[])

at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=ztIMw7AgOyAFfMqUwfcdao07KMY8lZffK2eWSQbXVr8kN(MethodBase #=z841yL7w=, Object #=zibHBY7E=, Object[] #=ztJiDIAE=, Boolean #=zhYaYijI=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zwT35uVo5gbCTJ1n$P4ssO6k=(MethodBase #=z841yL7w=, Boolean #=zibHBY7E=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=z0g93aaUJg8f7qTNNcTl0n2T8SwLjSbz$kg==(dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd #=z841yL7w=, #=qNTrdywJvmbvprlPBuY5pQogEhN_RA8Xq4lpEpLvYs7A= #=zibHBY7E=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zaICsEJ5MhFOOauCOgZ0gn9bRWa6p(Boolean #=z841yL7w=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zJ9U9EfcQSP5ZhxhpfkSQcc0j9X0G(Object #=z841yL7w=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zB1kQq4GJnSSmR3VyHag6rMOt9eAVnuQZIvtJ3QE=(Object #=z841yL7w=, UInt32 #=zibHBY7E=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zaICsEJ5MhFOOauCOgZ0gn9bRWa6p(Boolean #=z841yL7w=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zD_v9SEqG0gLVGCm0EbmwmCPhlffoqcENAcXpqphzRkqy(Object[] #=z841yL7w=, Type[] #=zibHBY7E=, Type[] #=ztJiDIAE=, Object[] #=zhYaYijI=) at dje_q3YE9EWSAU9Q6CY85NLTP6ZXS9KNKJHCQ66XXJTXP2QCZUJELVHMQ_ejd.#=zCPYQdhDfjXxtmxCs_Llov9c=(Stream #=z841yL7w=, String #=zibHBY7E=, Object[] #=ztJiDIAE=) at Aspose.Pdf.Document.#=zRDUUHiERYQ0V(Stream #=zbMelC3c=, SaveOptions #=zcg95f769zBEM) at Aspose.Pdf.Document.Save(Stream output)

This started immediately after an application pool recycle late on the 17th Jan 25 and occurred at least 2270 times. It stopped 24 hours later when the application pool was recycled again. This only occured on one of our servers and only on one of the partitions on that server that we can see. The application pools on these servers (we have over a dozen of them on AWS and Azure in different timezones) recycle every 24 hours and we haven’t seen this error occur before. It looks like the library faulted on the recycle and then loaded correctly on the next recycle.

I can see this problem was also reported on Jan 23

In that case the recommendation was to upgrade versions, we are currently on 24.8 which is much higher than the version in that case, so we don’t believe upgrading is going to fix the problem. We will be upgrading soon in any case, but in the meantime we have put in place code to catch the error if it occurs again and alert so the application pool can be recycled.

Are there any thoughts on what might be causing this or how we can prevent it from occurring?

I note that the relevant process on that server generates the same documents (many thousands of them) every day and has done so for many months. There was no change to the relevant code flow or to the documents.

@mkothe
The attached stack trace shows that the exception occurred while updating the document metadata.
Is it possible for you to identify and pass on the document that caused it - perhaps you have the appropriate logs.
There may be different assumptions - problems in the environment after reboot, a document with invalid metadata, an error in the library that occurs when processing a specific document.
Perhaps you can provide some additional information that would help identify the cause.

Hi Sergei,

We have spoken to the client but the documents are unfortunately considered to be confidential and we can’t provide them to any 3rd parties. They have given us completed copies and we have requested the original unmodified copies as well. I am happy to try to compare them if you can give me some ideas of where to look and what to look for.

I do note the following:

All pdfs on the affected system failed to generate, this was a range of different source documents not just one document or a few of the documents.

So they have several pdfs eg: 1.pdf, 2.pdf, 3.pdf (not their real names) and they generate many of these per day eg: 1000 of 1.pdf and 3000 of 2.pdf and 2500 of 3.pdf etc. None of the generations worked in the affected time period.

The time periods during which the failures occurred line up very closely with the recycle times for the application pool. Documents are generated all day so we are pretty certain about this.

No changes of any kind have been made to the documents for many months - these are documents for official purposes so they are only modified at very specific times. All documents were working fine prior to the point when the errors started and the same documents are all working fine since the errors stopped. Thousands a day. We have recycled the application pool a number of times since the problems and have had no further issues, in fact no other user has ever reported this before.

Obviously we would love to find the root cause so we can prevent it from happening again. Recovering and regenerating all the affected documents has been extraordinarily time consuming :wink:

Many thanks

Michelle

@mkothe
According to the information provided, it turns out that the work is carried out with the same documents.
Are they simply modified somehow (always uniformly?) and saved?

I still suggest that you run the check for all used documents to be sure that this is not the reason.
In the enumeration, for each of the documents, execute:

using var pdfDocument = new Document("fileName.pdf");
pdfDocument.SetTitle("Check doc");  // Internally, a metadata update is called
pdfDocument.Save("tmp_out.pdf");

Hi Sergei,

Just to clarify, the source documents are always the same and never change.
The process copies the bytes from the source document (in a thread safe way) and then works with the copy only.

The original documents are not being changed or saved to and have not been changed in many months. They are essentially templates used to generate the final document for the user to download and use.

As the originals are stored in a database and writes are controlled, we can be sure that modifications are not occuring to the originals.

Also, we had the same code and same files running on several virtual instances at the same time, checking our logs, only one instance had this problem. Parallel instances processed everything just fine.

So I don’t think the problem is that a file is being used concurrently.

@mkothe
If it is as you described (especially in this fragment)

-then the most likely reason is some error with the launch of the initialization of the environment and then the library. Here I see it possible to implement the execution of a number of typical tasks with documents from the database and control of the resulting documents. After making sure that everything is fine (the tests are passed), start the work itself.