1) Check your own code. When a worker process pegs the CPU, it's usually caused by coding errors such as circular references (e.g. code that eventually calls itself inadvertely), multi-threading issues (e.g. bad locking strategy), and so on. If you want to find it quickly (of course you do), then create a process dump of the worker process when it's pegging the CPU, and analyze it in WinDBG with the help of SOS (see http://support.microsoft.com/kb/892277 ). If you aren't familiar with using a "real" debugger, it might be a bit challaging at first. There are, however, many tutorials on the net that will help you pretty far (Google!). 2) Call Microsoft PSS and let them help you. They have experts who will find the error in no-time, especially if you can provide them with a process dump. If it's caused by an ASP.NET bug, it won't cost you anything and you'll receieve a hotfix or a work-around.

Try using dotTrace to get a clue on what's taking so long to perform. Our company had to "rescue" a site built by a large well known swedish software company with similar problems. We ended up fixing it by optimizing two or three functions. Main problem was that hughe amounts of data was stored in the users profiles (+1000 rows of properties for some users) of which news was actually read (and also which wasn't read, hehe) which took forever to load. dotTrace is an awesome tool for finding these sorts of problems. // Björn Sållarp Avantime AB