IIS7 - Security

Re: Dynamic IP Restrictions - Bug Report

naziml — Tue, 09 Jun 2009 00:53:25 GMT

We have a patch released for this issue. Follow the patch links on the right hand side in the landing page http://www.iis.net/extensions/DynamicIPRestrictions

Re: Dynamic IP Restrictions - Bug Report

jennylaw — Mon, 20 Apr 2009 18:30:42 GMT

This is a bug, it will be fixed in the next release.

Thanks,

Jenny

Re: Dynamic IP Restrictions - Bug Report

WillHughes — Sun, 19 Apr 2009 05:55:46 GMT

(For the benefit of anyone else having or monitoring this issue - dump files sent.)

Re: Dynamic IP Restrictions - Bug Report

jennylaw — Sun, 19 Apr 2009 02:55:01 GMT

Can you send the dump to jennylaw@microsoft.com -

I will take a look. Thanks, Jenny

Re: Dynamic IP Restrictions - Bug Report

JaroDunajsky — Sun, 19 Apr 2009 01:14:53 GMT

Will,

thanks for reporting the problem to us. I pass the information to feature owners on my team.

Dynamic IP Restrictions - Bug Report

WillHughes — Sat, 18 Apr 2009 17:09:21 GMT

Hey,

Not sure exactly why, but when I installed this module (via the Web Platform Installer 2.0 Beta) - it caused a few application pools to stop working.

I hadn't done any configuration of the module at all.

Any request to sites on those application pools would give a 'Connection Interrupted' type error, and the following would show up in the Event Log:

Faulting application w3wp.exe, version 7.0.6001.18000, time stamp 0x47919413, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a7a6, exception code 0xc0000374, fault offset 0x000b015d, process id 0xad0, application start time 0x01c9c03e217b6255.

Search results indicated that this is likely a PHP issue, but it occurred even for requests not running through the PHP handler (eg static HTML files), and when PHP was disabled.

Disabling the Dynamic IP Restrictions module resulted in requests being processed as normal. I'm not sure if it's a conflict between this module and others also loaded.

I did capture a minidump through the Debug tools when this was occurring. If you want, I can send it through.

The application pool configuration didn't seem to matter (Classic or Integrated, .NET 2.0 or no Managed) - and other successfully working sites and their AppPools were configured identically.

The only commonality between functioning sites and non-functioning sites seemed to be that the ones working had W3SVC numbers between 1 and 9, and the non-working ones were 10+ (W3SVC1 -> W3SVC9 - fine, W3SVC10, and 11 non-responsive). It's really really weird.