I’ve got a bit of a weird issue that started back in May. We’re using version 49.0.0.1225.
Randomly some of our reports have been killing our app pools when run due to a stackoverflowexception. All we see from debug diag is:
Faulting application name: w3wp.exe, version: 10.0.19041.1, time stamp: 0x58c67bf3
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x00007ff8da8cd015
Faulting process ID: 0x2488
Faulting application start time: 0x01d9824fd06f3941
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: unknown
Report ID: 76727743-5769-4c2a-a862-6d81c22ed8df
Faulting package full name:
Faulting package-relative application ID:
The issue occurs when accessing external references, e.g. the 2nd reference/link in this example:
If I remove the offending link, then the report runs through successfully without issue. Note that these external links aren’t required, so our support team has just been removing them when we identify an issue with the report.
Weirdly I’ve tried to replicate this in a standalone example and we can’t. Do you have any idea why this suddenly started happening? Our code around this area hasn’t changed for ages and reports all previously ran. The only thing that changed perhaps was the external datasources no longer being available.
Is there any way for us to use GemBox to automatically remove the external references?
Additional image of references as I didn’t have permission to add more one than media item:
Can you send us that file which reproduces the issue?
The only thing that changed perhaps was the external datasources no longer being available.
Yes, I suspect that could be the case.
Are you able to return that original external Excel file to its previous place?
Perhaps there is some kind of circular reference occurring here?
Nevertheless, just in case can you also try using the current latest bugfix version if perhaps this issue was fixed:
Install-Package GemBox.Spreadsheet -Version 49.0.1435-hotfix
Regards,
Mario
It’s a client confidential file so I don’t want to include it here. I can email it to you? What’s the best address?
I can’t restore the location because it’s a location on the client’s own network which was previously linked via a public URL (our software is cloud based, but we have no way to get that file back in the original location).
I’ll try the latest version too.
You can send us the file via email or support ticket, see the Contact page.
You mentioned that you will try the latest version, but can you reproduce the issue without having that external data source?
The issue goes away when you remove the external reference/link. We’ve had this around 10-15 times since May and the support team just download the base file, remove the external link, re-upload it and the issue goes away.
The reason the links are there is that the client sends us an existing report they use internally. Our implementation team then use that file to add a load of custom markup to it which we then run through our reporting engine to generate the reports dynamically. So the external links/references (whatever the correct terminology is) are never necessary.
File sent - ticket 31071.
We were able to confirm that the issue is resolved in the current latest bugfix version.
1 Like
