Last post Nov 01, 2019 03:59 PM by R_P
Jul 20, 2012 09:44 AM|bhansen-conexus|LINK
I am currently working with a .rdlc report within my .NET 4.0 MVC solution. The reason I am posting here in Web Forms is because of the nature of the Report Viewer in VS2010, my solution must be built on a .aspx page and loaded into my MVC application. (I
am using MVC 3). I have read a lot about the Report Viewer memory leaks in the past and all signs point to it being fixed in the latest version, however I am experiencing a problem.
The Problem that I am seeing is that the memory on the web server (IIS, w3wp service) keeps building and eventually the report receives an 'Out of Memory' exception. Every time a report is run, the memory jumps about 200mb, after which it may or may not
be released, but never in its entirety. No matter what the memory grows at least 20mb perminately until an iisreset or the appPool is recycled.
These are large reports by anyones standards, ranging from 10 pages, to 2500 pages.
Any help in recovering this memory would be extremely helpful.
A few notes:
Jul 20, 2012 02:05 PM|cachet.net|LINK
please have a look at this
I am not sure, i never faced this type of problem
Jul 25, 2012 03:51 PM|Cathy Mi - MSFT|LINK
Although it is hard to tell without debugging the memory leak, can you try the following?
Add NetFx40_LegacySecurityPolicy entry in your web.config file:
<?xml version="1.0" encoding="utf-8" ?>
<!-- enables legacy CAS policy for this process -->
<netFx40_LegacySecurityPolicy enabled="true" />
And use the following code in Page_Load method:
PermissionSet permissions = new PermissionSet(PermissionState.Unrestricted);
Jul 27, 2012 01:45 PM|bhansen-conexus|LINK
Thank you for your suggestion. I have now tried to use an object data source but that still results in an out of memory exception. Additionally I have attempted to dispose of the dataset after binding to the report but I have not found a way to do this without
causing the report to receive an error about an unavailable data source.
Jul 27, 2012 01:59 PM|bhansen-conexus|LINK
Maybe I am attempting to do this the wrong way but adding the Legacy Policy in the Web config doesn't seem to be working in my application. The report throws an error that states that the Legacy CAS Policy must be enabled - however, I have already followed
the instructions you gave to enable it. Do you have any other suggestions? Is there anything that I am missing.
The main problem still remains: the memory on the w3wp service on the IIS server is going up and the memory used by the reports is never released. Thanks again your continued help is appreciated.
Jul 27, 2012 02:45 PM|Cathy Mi - MSFT|LINK
Sorry, case-sensitivity problem?
Jul 27, 2012 04:49 PM|bhansen-conexus|LINK
I was finally able to get the policy to work and let me run reports again. With the cae change in my web.config file and a small code cahnge I was able to get them running. The code is as follows
protected void Page_Load(object sender, EventArgs e)
A slight variation on what you mentioned before.
Unfortunately the problem is still occuring. As I run the report, the server releases a small portion of memory every time it runs, but also perminately keeps some of the memory occupied. After running a few reports with different parameters (10 - 15 reports)
the viewer returns a report processing error stating that it is 'out of memory'. The funny thing is that the w3wp service is only at about 700 mb at this point and the serer has plenty of memory remaining to work with.
So sadly, the problem remains. Without an AppPool refresh or an iisreset, the memory is still consumed and remains 'in use', causing problems.
Aug 06, 2012 04:42 PM|Cathy Mi - MSFT|LINK
At this point, I would suggest having a case created for a more in-depth level of support. Please visit the following link to see the various paid support options that are available to better meet your needs.
If Microsoft determines that a problem is the result of a defect in a Microsoft product, you will not be charged for that incident.
Sep 14, 2012 11:22 AM|bhansen-conexus|LINK
So, I'm going to make a long story short. This has taken over a month to get taken care of, but I wanted anyone dealing with this issue in the future to have the information.
I spoke with Microsoft Support and started a case with them. After being bounced around from department to department, my case was given to the IIS/.NET department. They used all sorts of Memory Dump tools and Application Pool Monitors, and I even sent them
a sample of our reports in an application.
They told me the problem is not in the Report Viewer product, so they only had two suggestions: 1) Run the web application in a 64 bit environment, or 2) USe server side reporting.
Server side was out, so we played around with settings and here is what we found:
Our MVC3 Applicaiton is build for "Any CPU" meaning it will run in 32 or 64 bit environments. In the Application Pool Advanced settings, you can enable or disable 32 applications for the pool (on a 64 bit server). Disabling 32 bit applications forces the
web application to run as 64 bit. And... We are not getting the "Out of Memory" message anymore!
So, being in a 32 bit environment caused the w3wp service to max out on memory and not handle things well., but forcing 64 bit managed to avoid the error. We are now doing more extensive testing.
Apr 18, 2019 09:09 PM|MetalKid007|LINK
Hey all! I'm pretty late to this, but I have a real solution and can explain why!
It turns out that LocalReport here is using .NET Remoting to dynamically create a sub appdomain and run the report in order to avoid a leak internally somewhere. We then notice that, eventually, the report will release all the memory after 10 to 20 minutes.
For people with a lot of PDFs being generated, this isn't going to work. However, the key here is that they are using .NET Remoting. One of the key parts to Remoting is something called "Leasing". Leasing means that it will keep that Marshal Object around
for a while since Remoting is usually expensive to setup and its probably going to be used more than once. LocalReport RDLC is abusing this.
By default, the leasing time is... 10 minutes! Also, if something makes various calls into it, it adds another 2 minutes to the wait time! Thus, it can randomly be between 10 and 20 minutes depending how the calls line up. Luckily, you can change how long
this timeout happens. Unluckily, you can only set this once per app domain... Thus, if you need remoting other than PDF generation, you will probably need to make another service running it so you can change the defaults. To do this, all you need to do is
run these 4 lines of code at startup:
LifetimeServices.LeaseTime = TimeSpan.FromSeconds(5);
LifetimeServices.LeaseManagerPollTime = TimeSpan.FromSeconds(5);
LifetimeServices.RenewOnCallTime = TimeSpan.FromSeconds(1);
LifetimeServices.SponsorshipTimeout = TimeSpan.FromSeconds(5);
You'll see the memory use start to rise and then within a few seconds you should see the memory start coming back down. Took me days with a memory profiler to really track this down and realize what was happening.
Hope this helps!
Nov 01, 2019 03:59 PM|R_P|LINK
Thanks a lot MetalKid!!!!!!!!!!!!!
Still reading up on this but an initial run shows this solution reduces memory usage dramatically!!! ~30 reports, reduced ~1g