We’ve been fighting an intermittent error with our report viewer for the last couple years that’s been just terrible to track down and I think we finally made some progress today. We use a reporting tool called Data Dynamics Active Reports to generate our Screen and Paper reports. Their tool is basically a set of Dot Net assemblies that allow you to design and code a component called an Active Report.
At runtime, you execute this Active Report and then pass it into another component called an Active Report Viewer for displaying to the user. We found occasionally our users would get stuck in an infinite loop of error messages while displaying a report. Exceptions would pop up looking like this…
(IndexOutOfRangeException) Index was outside the bounds of the array.
at DataDynamics.ActiveReports.Viewer.-0011.-3cbd()
at DataDynamics.ActiveReports.Viewer.-dabf.-31a1()
at DataDynamics.ActiveReports.Viewer.-b212.-afcd()
We could never recreate this on demand, but probably five times a month we would get a hundred error messages coming in from a client site like this. Eventually the client would give up pressing “OK” on our error handler, and kill the process.
When we’ve tried to troubleshoot this in the past it’s been extremely difficult because Data Dynamics obfuscates their code so it can’t be decompiled. Obfuscation basically takes design-time code, and mixes it up so that it’s unreadable, hence the funky function names above. Unfortunately this gives you no sense of what’s actually happening in their app.
A little bit of digging on their support forums today did find a link to a similar issue by another user - http://www.datadynamics.com/forums/85506/ShowPost.aspx
Basically what they’d found was that in a Terminal Services environment, their users would click their “Print” button multiple times – the old adage, keep pressing the button until something happens. What this causes in some instances is for the second “click” to get handled by the newly created Active Report Viewer, even though it’s just in the process of being displayed. Now, if the Viewer is in a funny spot, it can try and interact with this click event while loading the document – that’s what seems to cause the issue.
Once we had a sense of what was causing the issue, it’s pretty simple to disable the ReportViewer until the report has generated its first page and sure enough this causes the issue to go away.