Connection_Abandoned_By_ReqQueue Problems

Question

I have this strange problem. I have 3 sites using the exact same code. All are on the same dedicated server and all have their own app pool. It's Windows 2008 R2 server. One of the sites keeps having the Connection_Abandoned_By_ReqQueue problem every few hours. Again, same code on all 3 sites, but only one is running into that. App pool has default settings.

I read that I should use Microsoft's Debug Diagnostics app and I installed it on my dev machine to play with it first and none of the reports showed nothing recognizable (.NET) so if it's the same on the server I'm not sure how that will help me track down the problem.

What's the best of finding the cause of these Connection_Abandoned_By_ReqQueue errors? I've read many things can cause this, which doesn't help.

Answer 1

I found this site: http://blog.leansentry.com/the-server-logs-you-need-to-know-to-fix-any-iis-aspnet-error/ that explains where the IIS errors can be found.

Important is that this error message is specific to Vista and Windows 2008. Other people have met with the same problem and found various solutions:

• Memory corruption: https://forums.iis.net/t/1156530.aspx
• Cryptographic exceptions caused by server overload: https://serverfault.com/questions/227648/iis-worker-process-recycle-without-killing-w3wp
• Low pagefile: http://mvolo.com/low-pagefile-can-cause-503-service-unavailable-on-azure-web-roles/
• long running or very large result sets from database
• this was interesting because it was about a version mismatch: https://blogs.msdn.microsoft.com/rakkimk/2009/08/07/iis-getting-connection_abandoned_by_apppool-defaultapppool-file-version-mismatch/

Without more information I cannot find a single reply to your question other than just try all of the above.

Answer 2

Just to clarify to other readers - the error Connection_Abandoned_By_ReqQueue is logged in the IIS Http error log (under %SystemDrive%\Windows\System32\LogFiles\HTTPERR)

Other potential causes here are Stack Overflows, and Access Violation type exceptions, which can be difficult to track down as the app's standard fault / exception handling code and logging may be skipped.

Be sure to also examine the Application Log in Event Viewer. With some luck, each failure will log an Application Error, and if the W3WP process crashes, a Windows Error Reporting crashdump entry may be logged.

Here's an example of a Stack Overflow (0xc00000fd)

Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x52157ba0
Faulting module name: clr.dll, version: 4.0.30319.34209, time stamp: 0x5348961e
Exception code: 0xc00000fd
Fault offset: 0x00001ffb
Faulting process id: 0x3918
Faulting application start time: 0x01d2398c5d2febfc
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: a796f4a2-a581-11e6-80eb-0050569051a9
Faulting package full name: 
Faulting package-relative application ID: 

The WER Crash Dump record in the Application Log will show you where you can locate the dump (These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue) which you can then scrutinize with a debugger like WinDbg.