Intermittent APPCRASH when opening a form with CrystalReportViewer

Question

We have an application that, as part of the functionality, allows users to generate and preview a report. It uses CR for VS 2010. The report preview dialog is a Windows Form that includes a CrystalReportViewer.
This functionality works, most of the time, but we are observing intermittent APPCRASH/Stackhash crashes when this form is opened of this nature:
Problem signature:
  Problem Event Name:  APPCRASH
  Application Name:      ****
  Application Version:    ****
  Application Timestamp:           4dd40fa4
  Fault Module Name:    StackHash_7698
  Fault Module Version:  6.1.7600.16385
  Fault Module Timestamp:         4a5be02b
  Exception Code:         c0000374
  Exception Offset:        00000000000c6cd2
  OS Version:    6.1.7600.2.0.0.256.48
  Locale ID:       1033
  Additional Information 1:          7698
  Additional Information 2:          7698c42b9ee8da1ebad3b3c9521cacfd
  Additional Information 3:          ad41
  Additional Information 4:          ad418ba72161d4cd11d7688fd368f113
This crash occurs intermittently. We have an automated script that tests the GUI and it may run for 5 minutes or several hours before encountering this error, with a handful, to tens, perhaps over a hundred report generated successfully.
As we understand it, the error code c0000374 means:
// MessageId: STATUS_HEAP_CORRUPTION
// MessageText:
// A heap has been corrupted.
CR is not the only part of our application that uses unmanaged memory, but this crash consistently happens when opening the dialog with a CR component in it (which renders a report).
I realize I've left out a lot of potential information, but will add more upon request. This problem is causing us quite some headaches and I just wanted to see if anyone else has experienced something similar.
Any ideas?

Answer 1

Hello Zamir.
Many thanks for the great answers (I wish I could post this thread as an example to all ).
Same to you. Debugging issues like this is never fun, but I know from experience that clarity from both sides helps us get to a resolution
Let's start with SP1. You may already be using it. Check the version of the crpe32.dll (C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win64_x64). It should be 13.0.1.220, if it is, we're on SP1. If it is not, understanding your concerns, going to SP1 will still be the DE thing to do. E.g.; I will not do any testing unless you are on SP1 (sounds bad I know, but just laying the cards on the table - face up )...
I checked both my development machine and a production system that I have access to in-house (which is able to reproduce the problem via a script). Luckily for me, both are at version 13.0.1.220.
The fact that you are not able to reproduce the issue on your development system my actually be quite encouraging and perhaps a starting place for us (given the SP1 conundrum). It will be interesting to compare the dlls (both Crystal and database client). Normally the Modules utility is very useful for comparing dlls loading on a computer that works and one that does not. As this is a 64 bit app, it will be a bit trickier. Modules works really well on 32 bit apps. On 64 bit apps it does not save the log. You can still see it, but not save it. Anyhow, I am attaching a 64 bit version of Modules. You will have to check the versions of the CR DLLs and database client DLLs by looking at the logs and writing the info down
I'm having a bit of trouble with the Modules utility. I launched it and when I get it to generate a list, I cannot see the process for our application in the list. It is running and appears in the task manager, but it is not listed under the list of processes, nor do I see any of it's loaded DLLs. Any ideas?
Re. apps compiled as "Any CPU". These should work - as long as only the correct "bitness" CR runtime is deployed. E.g.; On a 64 bit OS, do not deploy both a 32 bit and a 64 bit runtime. This may cause issues. My recommendation in the previous post was a rather blanket recommendation that quickly eliminates all kinds of confusions for many people.
Thanks for the clarification. I am going to stick with 'Any CPU' because I know that we only deploy the x64 runtime and if I switch to explicit x64 compilation, Visual Studio reports some false-positive warnings that I'd rather not have (it's a bug in Visual Studio).
Re. the database - SQL Server CE v3.5 SP2, OLE DB. Make absolutely sure the db client is the same on the problem computer as it is on your development computer. Use Modules for that. If htere is a later SP, apply that. I can not overstate the importance of this.
As above, I could not use modules, but I did confirm the DLL versions in their respective Program Files location on both machines and they were the same (3.5.8080.0).
It will be important for these users to let us have screen shots of the issue as they get it. I realize this may be an inconvenience to the customer, but what is essentially a hearsay evidence from what is typically a non technical user is always something to take with a grain of salt.
I just talked to one of our field engineers and he has seen screenshots to confirm it is the same issue as the one we can reproduce in-house.
One thing to be absolutely sure of is that you are using .Close and .Dispose on the report objects as the user is done with them.
We do, in general, make these calls and recently have gone through our code for memory leak possibilities, so this was recently checked for by developers.
One other possible source of issues; printer drivers. Specifically printer drivers not designed for the particular OS. Ensure that the printer driver(s) used by the customer on that WIN 7 are designed for WIN 7 - even if they are only viewing and or exporting. CR has a large dependency on printer drivers.
We use the Samsung CLP-320 and the driver package it installs are "Win 2000/XP/2003/Vista/2008/Win 7(32,64bit)", so I assume the correct version gets installed on our Win 7 x64 system.