I think this is your problem:
Crystal Reports 11.5 in a Windows Service to send emails in a multi-threaded environment using VB.NET in .NET 4.0.
CR 11.5 (XI R2) is not supported with VS2010. Only Crystal Reports for Visual Studio 2010 (CRVS2010) is supported in VS2010. You can download CRVS2010 from here:
http://scn.sap.com/docs/DOC-7824
Download the latest (SP3). Update your project to that and see how things go.
- Ludek
Follow us on Twitter
Got Enhancement ideas? Try the SAP Idea Place
Hello Ludek and thanks for your answer.
I must apologize, I am using Crystal Reports 13 with support pack 2. Sufficient for running smoothy I think. The problem has occurred twice more. Every error has two logs. Perhaps they will help (sorry, the logs are Dutch again).
Toepassing met fout PrintServiceHost.exe, versie 1.0.0.0, tijdstempel 0x4fb12484, module met fout ntdll.dll, versie 6.0.6002.18327, tijdstempel 0x4cb73436, uitzonderingscode 0xc0000005, foutmarge 0x00066579, proces-id 0x%9, starttijd van toepassing 0x%10.
Toepassing: PrintServiceHost.exe
Framework-versie: v4.0.30319
Beschrijving: het proces is beëindigd als gevolg van een onverwerkte uitzondering.
Uitzonderingsinformatie: uitzonderingscode c0000005, uitzonderingsadres 77546579
------------------------
Toepassing met fout PrintServiceHost.exe, versie 1.0.0.0, tijdstempel 0x4fb12484, module met fout ntdll.dll, versie 6.0.6002.18327, tijdstempel 0x4cb73436, uitzonderingscode 0xc0000005, foutmarge 0x000665d6, proces-id 0x%9, starttijd van toepassing 0x%10.
Toepassing: PrintServiceHost.exe
Framework-versie: v4.0.30319
Beschrijving: het proces is beëindigd als gevolg van een onverwerkte uitzondering.
Uitzonderingsinformatie: uitzonderingscode c0000005, uitzonderingsadres 775465D6
Do you think installing service pack 3 will fix this problem? Because I didn't see anything like this in the Fixed Issues wiki.
There is nothing in SP3 specific to this, but it is relatively painless to try(?). If this would ever come to escalating for some sort of a fix, it would have to be with SP3 anyhow.
From testing we've done on CRVS2010 SP3;
Since the license model for CRVS2010 is 3 Concurrent Processes, on a quad machine we were able to get three threads per CPU, thus 12 threads on a quad. This was very reliable and efficient. Any more threads resulted in performance issues (the more threads, the worse the performance) - not actual crashes as in your case, but this leads to the following questions:
How many threads is the app spawning now?
Is this perhaps occurring when the load is higher than normal?
- Ludek
Installing SP3 is relatively easy, but I can't do this myself. It will probably have to wait until next week.
The app is now spawning one thread per report, but the second does not spawn before the first one is complete. If I put the app back in it's original state there's approximately four threads using ReportDocuments simultaneously.
As for server load, I don't think that's the problem, but I'm not ruling it out either. As I said everything works well for a couple of days and then it crashes. Sometimes it crashes again five minutes later, or hours later or days later. There's no clear pattern.
Could it have something to do with the OS version?
I don’t think the OS has anything to do with it. To me, it seems more like a threading issue or race condition causing the AccessViolation.
I wonder if you could try using GC to see if that helps and/or clean up the reportdocument object before the smtpClient and MailMessage objects:
_ReportDocument.Close
_ReportDocument.Dispose
_ReportDocument = Nothing
smtpClient.Dispose
mailMessage.Dispose
GC.WaitForPendingFinalizers()
GC.Collect()
- Ludek
Thanks again for your reply.
I will try what you have suggested. It may take a while to see if it works though. The service hasn't crashed since last week, but that is without your solution though. If I've implemented this it may take another week before I know if it actually works.
Hi Ludek,
I have done a stresstest sending 1000's of emails using your solution. Unfortunately the environment (OS, Crystal Version) I tested on is different from the environment where the service is crashing.
Anyway, here are the results:
The calls to the GC messed up the entire service. Since I'm reading and writing from/to a database elsewhere in the service I got deadlocks and Concurrency issues (which is pretty weird, since I never got that before, even when threading).
Anyway, I did not get any crashes in this environment (either with or without the GC calls). Perhaps it helped to just switch the dispose methods around. I first disposed SmtpClient and EmailMessage then the ReportDocument. Now I first dispose the ReportDocument then SmtpClient and EmailMessage. Not sure why this would help, but the fact remains that the service did not crash even after 1000's of emails. Of course this could also be because of the different environment.
I am going to put the change to the test in the clients environment and I will let you know if the problem (crashes) persists. If it does I am pretty sure the problem is the clients OS or crystal version (I think they're running 32-bit while we run 64-bit).
Thanks and I'll let you know.
Hello Ludek,
I've found a solution to the problem. We've moved the service to another server and we've had no problems since then. I guess the problem was with the OS after all. Or maybe Crystal Reports conflicted with other software on that server. Whatever the problem was, it's gone now.
Just thought I'd let you, and everyone else who was wondering, know.
Thanks again for your help.
Much appreciated.
We'll chalk this one up to a "black box" thing... 
Happy coding
- Ludek
