1

So I've been trying to figure out why the application pool keeps crashing every now and then, and I've pinpointed the page that is cau seems to be causing the issue.

When I open the site in the browser, and visit the Shipping cart page (after adding stuff to the cart), the entire browser becomes unresponsive, and I open Task Manager, and see that IE (browser) is using 99% CPU, so I right-click > Create DUMP > Try to read DUMP but WinDBG does not seem to like DMP files; won't read them.

So I move on, and try to figure it out without the dump files. I fire up Visual Studio, open the site in question, and then follow the same process (add stuff to cart, then visit cart page). And to my surprise, everything is OK.

Not sure what to do now. Any suggestions? How would you determine the cause of the hanging, when everything runs perfectly, locally - and when everything used to run perfectly online, but no longer runs fine online?

Arrow
  • 2,784
  • 8
  • 38
  • 61

1 Answers1

2

If the browser becomes unresponsive and eats 99% CPU, that's a client side problem; it most likely doesn't have anything to do with IIS or your server side code.

Could it be that you have some javascript in your page is buggy and goes into a busy loop? I think it's worth a shot to test this (use either IE's developer tools (F12), Visual Studio's javascript debugging functionality, or FireFox in combination with FireBug).

Edit It strikes me as odd that your AppPool crashes, and in doing so, causes the web browser to turn non-responsive. With non-responsive, do you really mean that the browser itself stops working (i.e. navigating a page back or going to another url such as google.com is impossible?)

Anyway, if you think the problems occur on the server-side, you could try the following things (in order of increasing effort):

  • After an AppPool crash, check the windows event log (run 'eventvwr' from a command prompt) and see what information that gives you.
  • View the IIS log (you might have to turn it on first), see if it contains any weird request patterns, such as your page getting hammered)
  • Run your website from IIS, but attach a debugger from Visual Studio (under Tools, Attach to process - include only managed code) to the IIS worker process (usually w3wp.exe). If your page throws an exception, VS should be able to catch it.
  • Add more tracing to your page, the Global.asax's Application_Error seems like a particularly good candidate.
Leon Bouquiet
  • 4,159
  • 3
  • 25
  • 36
  • Thank you, but if that is the case, why doesn't this problem occur on my local PC when debugging locally (since both online and offline versions are identical)? – Arrow Nov 25 '12 at 13:58
  • You say online and offline, I take it you mean working locally versus working from another machine? Or locally versus hosted on a production web server? Good question, do you use exactly the same browser (i.e. on the same computer) to connect to it? – Leon Bouquiet Nov 25 '12 at 17:26
  • Yes, that's exactly what I mean. And yeah, I use the exact same version. (but a client who is also experiencing this version is using a different browser (Safari)). – Arrow Nov 25 '12 at 18:11