Receiving JavaScript error when attempting to view certain PDFs
Problem reported by James Long - January 26 at 10:19 AM
I've integrated your Document Viewer into a Web App that I'm working on currently. When I attempt to view certain "complex" PDFs, I get the following JavaScript runtime error.
Unhandled exception at line 1, column 474926 in
0x800a139e - JavaScript runtime error: Error loading document: Invalid XPZ file: Zip end header data is wrong size!
Can you please advise on how to fix it?  I've also submitted a ticket to support for this.

2 Replies

Reply to Thread
Cem Alacayir Replied
January 26 at 10:53 AM
Employee Post
I tested your file on the live demo and it seems it’s loaded correctly.
Do you see any rendering issue?
Note that DocumentViewer caches files according to their file name, file size and file last modified date.
For example, if you are using Stream constructor and if you do not provide varying values for each different file then the same cache key would be generated for files.
When you load a file on disk, these values are automatically retrieved from the disk.
However when you use a Stream, you are responsible for supplying correct values (at least they should differ for different Streams/Byte arrays).
The cache key is important because browser also caches the requested file parts.
For example “Invalid XPZ file: Zip end header data is wrong size” error is usually caused when the browser cache does not match the request.
You should see that it’s fixed when you CTRL + F5 in your browser or in Chrome F12 to open console and while it’s open press and hold the browser’s refresh button and it will give you “Empty Cache and Hard Load” option.
Cem Alacayir Replied
February 3 at 12:32 PM
Employee Post
For future reference, this was resolved like this:
The first and actual error message you get in DocumentViewer is “bad allocation” with clean DocumentCache folder.
So it's possibly about insufficient memory. 
An exception of type 'System.Runtime.InteropServices.SEHException' occurred in NativeDocumentEngine.dll and wasn't handled before a managed/native boundary
Additional information: External component has thrown an exception.
So something went wrong during conversion of the file to the special web-friendly format XPZ.
After this error occurs, on your second viewing of the page you start getting javascript errors, these errors are caused because the XPZ file is 0-byte as the conversion failed. Normally with other type of exceptions 0-byte will be deleted automatically but SEHException is a special exception (caused by native DLL) so it's not caught by .NET and as a result the empty file is not deleted from cache.
To fix it:
  1. You need to enable 64-bit mode of IIS Express in Visual Studio Options
    When you launch a web project in Visual Studio, by default is uses the 32-bit version of IIS Express. To change that you can enable the 64-bit version through Options.

    So, head to:
    •    Tools
    •    Options
    •    Project and Solutions
    •    Web Projects and check the option
    •    “Use the 64 bit version of IIS Express for web sites and projects”


  2. Before you try again make sure you delete contents of App_Data\DocumentCache folder (or only delete the corresponding cache file).

    Once the conversion is failed you will have 0-byte XPZ cached file and this will keep you giving javascript errors which are not the main problem they are the result of first error.

    After enabling IIS Express 64-bit mode and started debugging with a clean DocumentCache, I was able to display your test.pdf without any problems.

More information:
  • I also use IIS Express with default 32-bit mode on my machine, for example with my sample empty projects the error does not happen. I think only when you add Telerik stuff and use IIS Express 32-bit mode, the error happens. However when you use IIS Express 64-bit mode, all libs live happily
  • I will investigate further why the error happens with Telerik and IIS Express 32-bit combined.
    However there is no disadvantage to use IIS Express 64-bit, actually it’s better from memory perspective so you can consider it fixed. 64-bit can handle more than 2GB process memory so the problem seems to be about memory. Probably Telerik also uses a lot of memory and there there is not enough left for DocumentUltimate to successfully convert complex PDF documents. Note that I am talking about max memory that a process can use, that’s 2GB for 32-bit, even if you have 16GB in your machine 32-process will not be able to use more than 2GB.

Reply to Thread