My c# application uses .net WebBrowser. I need to close child control everytime and I have noticed WebBrowser is not getting disposed and RAM consumption is increasing heavily with each call (around 10 mb on each new control declaration) and application crashes in sometime with OutOfMemoryException. Searched over forums but couldn't find a clean solution.
Tried SetProcessWorkingSetSize(pHandle, -1, -1); but it doesn't reduce virtual memory though RAM uses will be reduced and its not a clean way of overcoming the issue.
Seems this issues exists since years, for more details look at this thread How to get around the memory leak in the .NET Webbrowser control?
Any suggestions ? Tried almost everything but no success yet.
Thanks,
Abhinav
I don't know whether your situation is similiar to mine but I have wasted three days for that weird problem.
My application was performing a search on a web page and my code was like that;
1.Open web page
for(1000 times)
{
2.Write input and click search button.
3.Check the result.
}
As you see my program opens the web page and makes repeated searches.Here opening the page (navigaiton) occurs only one time. My program's memory consumption was continuously increasing even above 1 GB! Then I tried putting the navigation inside the loop it worked.
for(1000 times)
{
1.Open web page
2.Write input and click seach button.
3.Check the result.
}
I exactly don't know the reason but reusing the same page for a long time was the cause of my problem. I hope it helps.
Related
My application is something like Chrome or Firefox and allow to create and destroy tabs with WebBrowser object. It is very rough description, but close to understand what app is doing.
The problem is that the WebBrowser object is based on Internet Explorer (IE) and IE has a memory leak in deep of .Net unmanaged memory if closed site have some JS code or images (which is 99.99% of sites).
I tried every solution from web and finally I have got a confirmation from MS that this issue based on IE architecture and it can't be fixed by any trick from the code perspective (object cleaning or calling GC).
So, I started thinking in different way to solve the problem.
The problem is that the leak happened in unmanaged memory of .Net WebBrowser object and .Net does not clear it properly when WebBrowser object destroyed. But it happens in my application process ID.
So, I am looking for some option to separate memory for my application and for WebBrowser object (create it in a separate process). I know that Chrome is working in similar way (one process per one tab) which makes this idea realistic at least. But I can't find any info how can I do it to display WebBrowser in my app as it was before.
Thanks in advance for help!
I've never seen this issue before, and I'm not even sure if I'm posting in the correct place.
My Co-worker wrote a C# program (windows), that includes a web control. In that web control are a bunch of iFrames. Now, when the web control is populated (max 15 records), everything is fine. 99% system idle process. But once you minimize the program, boom, 99% process goes to the c# program and stays there!
If the web control is not populated. There is no issue with minimizing and maximizing the program.
There are no functions that run when the program is minimized or maximized, so there's nothing to debug...
The program is crashing on two computers, but on the rest (about 8 computers) it runs fine.
The two computers that "crash", are not very similar... so it's proving hard to find what may be causing the issue. One computer is xp, the other is windows 7, one is ie7, the other is ie8.
If anyone could point me in the right direction, or if anyone had a similar situation and has a solution, I'm all ear's and eye's!
I would attach Visual Studio to the "99% CPU" process, break all, and see what's going on in there. That's first step.
Doesn't Windows write inactive (i.e. minimised) application state to disk, to free up resources for active (non-minimised) windows?
One of the hooks / events called when you minimise the application could be causing IO hangs. You should get a diagnostics tool like Sysinternals Procmon to see if IO (or any other process) is hanging based on the minimise event.
Good luck!
Chris.
So my co-worker didn't find the thorough answer as to why it was crashing, but it was crashing due to the .net Web control. He swapped out the control for a VB6 control and it now works.
I have recently rolled out a new ASP .Net application. This application uses .Net 4.0 and the Entity Framework 4. It is a "basic" CRUD application. I almost exclusively used the EntityDataSource for Data Access.
The users have reported "ocassional freezing" of the application (they all use IE 8). If the user closes his browser and starts back up, the app is fine. It happens maybe once or twice per day total, usually to the heavy users. (So, I have been leaning toward memory leack or some other kind of resource limitation.)
Until just a little while ago, I have never seen this happen. It dosn't leave anything in the Event Log on the client PC nor Server. Also, there is nothing in the IIS error logs or the SQL logs.
A little while ago, I finally got it to happen. I was switching all of my EntityDataSources to use a single Object Context per page. I downloaded the EF Profiler (which seems to be a great product) and it pointed out that I am using multiple object contexts on many of my pages, due to the fact that many of them have more than one EntityDataSource. So, I was cleaning all this up and testing each page, when lo and behold....IE stopped loading pages!
At first, the page started loading slowly (and this was a page that I had already modified to use a single Object Context, so although I still believe I need to implement this "singleton" pattern throughout all my pages, I guess it isn't the culprit! Anyway..), then at some point I received:
Message: Sys.WebForms.PageRequestManagerTimeoutException: The server request timed out.
Still, nothing in the Event Log. I also checked the IIS web logs and I don't see anything, but they are pretty tough to read with the naked eye, I may have to download a parser to make sure there is nothing in there.
Anyway, I decided to start up another window and navigate to my app, and sure enough that window worked fine, no problems. I went back to the windows that stopped responding, refreshed it, waited... went to the home page of my app (which is basically just some static html.. and nothing.. ). Next, I opened a new tab in the window that is currently frozen and that tab works fine. So, I go back to the window that can no longer load pages from my app and try some other web sites.... espn.com loads fine, msn.com loads fine, I then enter the URL for my app home page (and tried some other pages in my app) and NOTHING. IIS doesn't even log the attempts in its Log Files (its like IE has just decided not to do anymore "gets" for my localhost!). Finally, after waiting for a while (while I was typing this post) I now have this error message in that window:
Internet Explorer cannot display the webpage. What you can try: The problem can be caused by a variety of issues, including: BLAH BLAH BLAH...
So, I jump back to that window and it can still browse Internet sites just fine. But, once again when I try to go to any of the pages in my app, I get NOTHING (spinning blue circle in the tab). So, once again I start a new tab in that same browser and I can browse around my application just fine.
What has my app done to this browser instance that will no longer let it load any of its pages (in fact, it seems like it isn't even doing a GET on any of the apps pages, since there is nothing new in the IIS logs...except for when I load the pages in these other tabs and/or browser windows that work fine, so the logging is still working...)? I will be forever indebted to the person that can help me figure this out. I am not sure it will do much good, but I am going to leave this browser window up on the chance that someone can tell me some things to try to diagnose this problem. It feel like I am THIS close to figuring it out. I finally have a window up that is misbehaving. I am afraid to close the window or do a new build on the app until I get some good input on things to try....
I should add that when this happened to me, I was running on my local PC, so I was the only user and only had one window open to the app..
Although, I am completely stumped!
We had the same issue and seemed to fix it by adding the following JavaScript to all pages with ajax:
window.onunload = abortRequest;
function abortRequest() {
Sys.WebForms.PageRequestManager.getInstance().abortPostBack();
}
I hope this helps!
sounds like a request just takes too long to execute. A web-browser is only allowed to keep two concurrent connections to a single webserver unless you utilize http pipelining (which isn't well supported anyway). However, My experience is that this is per browser, not per tab.
This is why nothing shows up in your logs, because your browser never initiate a request because it is waiting for the page to finish loading before it can fetch another page. I would start looking into the last request initiated before the lockup, it is probably that page that locks for some reason and never finishes.
ASP.NET utilizes only one thread as long as all request are sequential. As soon as you fire up two request simultaneously, a new thread is initiated (Init() on HttpApplication is invoked), and that can cause intermittent errors if you do funky stuff on Init().
If you think this is related to EF, you might read up on how to avoid locking in multi-threaded environment (because a web application is very much multi-threaded however this usually kicks in a production environment).
Ugh, I feel your pain - I hate these types of issues. Here's my divide-n-conquer process when something like this is happening (adapted somewhat to your case):
Step 1 - Environment Visibility
Get yourself set up so you can roughly see inside your systems. Set up Performance Monitor, and add a couple of important counters (IIS Current Requests, ASP.NET Current Requests, SQL Server - Active Transactions). The idea here with the "active requests/transactions" counters is you want to find out which part of the system is holding on to the request.
Additionally, add counters for total request time in IIS and the DB (so you can see it climbing as something is hanging on).
On your client PC, set up Fiddler.
Step 2 - Reproduce Issue
Usually at this point, the application realizes you can see it and starts behaving perfectly. ;) Stop and make sure you can still reproduce the issue.
Step 3 - Take the DB out of the equation
Create 4 pages in your application:
Static HTML file (.htm) that will NOT go through the ASP.NET runtime engine. This is your baseline for raw IIS.
ASPX page with no tricks (no database access, no processing, just a simple page that ASP.NET can spit out)
ASPX page with one simple database call (of some size, maybe do a single big query or something)
ASPX page with some complex transactions (multiple queries, etc)
Step 4 - Reproduce and measure
Since this issue will probably be pretty obvious once you can see it, find the bottleneck with your performance counters and Fiddler. Your issue sounds like you could have an intermittent connectivity issue (either between client and web server or web server/SQL), especially if IE is giving you the "page cannot be displayed" error, but you should see that in Fiddler. On the server side, you should see one of those performance counters hanging.
well, sounds like the app is waiting for a database operation to complete but is locked, probably because of another operation.
Try using the SQL profiler to trace the activity, and isolate what processes are running for a long time.
You can differentiate the requests using the SPID column in the trace view, it contains a unique ID number for each session from your App.
I have new information regarding this issue.
The application uses Integrated Authentication. This causes every reqest to come back (twice) with access denied, before IE send the credentials.
I can't help but wonder if this is what could be causing the "time outs".
I implemented an Ajax "Loading" animation on every page that prevents the user from clicking a button until the previous request is completed and that has GREATLY diminished the amount of "freezes" the users are experiencing.
Although, it still happens somewhat often.
I wrote a webcrawler which calls a web page in a do while loop amount 3 seconds
totally there are 7000 sites... i parse the data and save it in my DB.
sometimes because the script is loading for a long time, i got a timeout in browser,
but in background i continues. I see that on my database.
Can I prevent this?.. Now it's just possible if I stop webserver.
Thank you and best regards.
Your web page is kicking off a server-side process. Killing your browser or closing it is not going to stop this. It sounds to me like a web page to control this is the wrong approach, and you should be looking at a connected form of application like a WinForms/WPF app. There would be ways to get this to work with ASP.NET, but they are not going to be simple. I think you have just chosen the wrong technology.
Starting an intensive, long running process like this from a web page is almost never a good idea. There are lots of reasons, but the main ones are :
1) If you get a timeout in the browser (this is your scenario) the data you have harvested may not be displayed.
2) What happens if you hit refresh in the browser? Will it attepmt to start the whole process again? this is an easy target for an attacker, if he wants to tie up all your server resources.
3) Is the data you are crawling really likely to change to such an extent that you need "live" crawling? 99% of cases would be served just as well with a background timed job running the crawl, and your front end just displaying the contents of the database.
I would seriously recommend you rethink your crawling strategy to something more controllable and stable.
One of our ASP.NET pages has a significant memory leak. After a process of manual enable/disabling, I narrowed down the issue to a set of collapsible panels which are dynamically built on the code page and placed into an UpdatePanel which is already on the page.
Using sIEve, I was able to see that this control apparently is creating a large amount of script tags, each having the following form (ignore the sIEve hook attribute):
<SCRIPT type=text/javascript __sIEve_hookedNode="true">Sys.Application.add_init(function() {
$create(AjaxControlToolkit.CollapsiblePanelBehavior, {"ClientStateFieldID":"ctl00_Main_branchPanelExtender_ClientState","CollapseControlID":"ctl00_Main_btnBranchExpander","Collapsed":true,"CollapsedSize":0,"CollapsedText":"* ; ","ExpandControlID":"ctl00_Main_btnBranchExpander","ExpandedSize":100,"ExpandedText":"Collapse","ScrollContents":true,"TextLabelID":"ctl00_Main_btnBranchExpander","id":"ctl00_Main_branchPanelExtender"}, null, null, $get("ctl00_Main_BranchPanel"));});</SCRIPT>
I think this is the problem, but I'm not completely sure. sIEve isn't reporting it as a memory leak, but the DOM nodes are definitely increasing and the page size grows out of control. I'm also not sure what to do about it. My best guess is that the corresponding remove_init isn't being called (or doesn't exist) but I can't find either function call in the AjaxControlToolkit library project.
Has anyone else encountered this problem or have any ideas on how to proceed with fixing it?
Edit: Browser Info
This is mainly IE 6, of course, but I also note the issue with FireFox 3. Opera and Chrome don't seem to have the memory leak, but Chrome doesn't render the controls right either.
Further Info:
I've noticed a similar problem on another page using HoverMenuExtender. It seems like the DOM just grows each time the UpdatePanel is posted and IE never frees the memory. Is there maybe a way to catch which items are holding over and manually remove them, or am I being overly cautious and IE will eventually free the memory up if needed?
Well, no answers on this one and I doubt one is coming. The problem can be answered very briefly though as "It's IE6." Sometimes certain DOM elements (the selection elements in an Option tag seem particularly prone) just don't clean up, so they fill the DOM up over time. Nasty, but just another thing to manage in IE6.