ISA Server 2006 stops answering requests

1. Introduction

Recently we have had some cases where customers call complaining of the following behavior:

· ISA Server randomly stops answering requests.

· Apparently there is no resource depreciation.

· ISA Server logs the error FWX_E_NO_BACKLOG_PACKET_DROPPED 0xC0040016 in the Monitoring/Logging.

Per Microsoft Internet Security and Acceleration Server 2004/2006 SDK Error Codes article this error means: A packet was dropped because the rate of requests for incoming connections was too high. In summary the firewall was receiving traffic at a higher rate than it was able to process. Unfortunately the error itself plus the symptom doesn’t give us a straight answer which means that further investigation is necessary.

2. Analyzing the Data

In this type of scenario netmon trace will assist but most likely will not give you the precise answer of what is causing such behavior. In addition to that this type of scenario also requires: ISA Data Packager and a memory dump of the WSPSRV.exe process

Some patterns that you will see in the data analyzes are:

· In the Netmon Trace: high number of name resolution request from ISA

· In the user mode dump you may notice threads in critical section that have a stack similar to the one below:

2f2cebc8 77c7fcf0 2f2cec04 2f2cebe8 77c80673 ntdll!KiFastSystemCallRet

2f2cebd4 77c80673 2f2cec04 76ed42d8 2f2ceff0 rpcrt4!I_RpcSendReceive+0x23

2f2cebe8 77ce315a 2f2cec30 284b5680 00000000 rpcrt4!NdrSendReceive+0x28

2f2cefd0 76ed5049 76ed42d8 76ed421c 2f2ceff0 rpcrt4!NdrClientCall2+0x1a8

2f2cefe8 76ed4f69 00000000 29321d98 00000001 dnsapi!NetInfo_Copy+0x5c2

2f2cf044 76ed6f5d 29321d98 00000001 00000000 dnsapi!NetInfo_Copy+0x4e2

2f2cf078 76ee9d0c 00000003 2f2cf354 00000001 dnsapi!DnsValidateName_W+0x31f

2f2cf0a0 62ea7442 2f2cf354 00000001 00000000 dnsapi!DnsQuery_A+0x20

2f2cf0ec 62ea789e 2f2cf354 00000001 2f2cf130 msphlpr!ProxyDnsCacheInit+0x5ed

2f2cf110 62ea6583 2f2cf354 2f2cf130 62ea6257 msphlpr!ProxyDnsCacheInit+0xa49

2f2cf458 647484a2 2cf510e8 2cf51168 00000000 msphlpr!ProxyGetHostByName+0x32c

2f2cf498 64748e4e 2cf51168 00000000 00000000 W3Filter!DllUnregisterServer+0x2d4d0

2f2cf4e0 6476676f 01f3f668 00000000 00000000 W3Filter!DllUnregisterServer+0x2de7c

2f2cf530 64773614 00000000 01f3f008 281ad100 W3Filter!DllUnregisterServer+0x4b79d

2f2cf56c 647746d4 00000000 00000000 00000000 W3Filter!DllUnregisterServer+0x58642

2f2cf58c 64727a4e 01f3f008 281ad708 281ad100 W3Filter!DllUnregisterServer+0x59702

2f2cfe1c 6472829a 00000000 00000000 0000000c W3Filter!DllUnregisterServer+0xca7c

2f2cfe90 0046d838 281ad100 00000001 00000000 W3Filter!DllUnregisterServer+0xd2c8

2f2cfefc 0046e598 000000d2 00000000 00000001 wspsrv+0x6d838

2f2cff20 0046e69f 2828ff00 0046e50e 2f2cff50 wspsrv+0x6e598

Note1: this stack is using Microsoft public symbols, for more info on how to configure WinDBG with Public Symbols check the Debugging Tools and Symbols Page.

Note 2: To view the threads in user mode use the command ~*kv.

3. Conclusion

The problem was happening because this customer had a global deny rule like the one below:


Figure 1 – Firewall Policy.

This is an access policy that handles “all outbound traffic” and applies to a Domain Name Set as destination. This policy configuration cased ISA to attempt to perform a reverse lookup for every connection request matching the source network regardless of protocol in order to determine if the IP address matches the DN Set. Note that normally URLs only apply to HTTP and as such this rule should have been limited to HTTP protocol. The DNS lookups generally will fail but ISA has to wait until DNS timeouts. This will exhaust the ISA server connection resources resulting in dropped frames due to the backlogged packets.

With the policy showed in Figure 1, ISA must perform a reverse lookup for every connection made from the Internal network to anywhere. If the policy was HTTP/HTTPs only, then the general effect would be minimal as normally web connections are made to FQDNs rather than IP addresses, not to mention the fact that this policy would not apply where the reverse lookups fail to resolve or don’t match like as show in the example below:


Default Server:





Non-authoritative answer:




> set type=ptr




*** can't find Non-existent domain

Note: If you use perfmon and monitor \ISA Server Firewall Packet Engine\Backlogged Packets you will notice that the counter is going up, normally this counter would almost never go higher than 10.

In other words: any rule which use destination Domain name sets should ONLY apply to HTTP/HTTPs protocol (since URL set is already used only for HTTP/HTTPs). Besides this general recommendation you should use the Firewall Policy Best Practices as your main reference for scenarios of this nature. Here are a couple of key highlights:

The following rule elements require additional networking information and therefore are evaluated more slowly:

· Domain name sets and URL sets

· Users

· Content type

Rules that contain such elements should be placed at the bottom of the rule list.

Global deny rules. Rules that deny specific access to all users. These rules should use the rule elements that require simple networking information. An example of such a rule would be a rule that denies all users access from anywhere to anywhere on protocols used for peer-to-peer file sharing.

This type of problem can be mitigated by following the best practices for firewall policy and how to order those in a proper way.


Yuri Diogenes

Security Support Engineer

Microsoft CSS Forefront Security Edge Team

Billy Price

Security Support Engineer

Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Vic Singh Shahid

Escalation Engineer

Microsoft CSS Forefront Security Edge Team