Formula for Processor Affinity Mask (IIS)

It should be possible to script such a process, I would probably start with PSH as it has inbuilt XML support and access to .NET (useful for generating new keys if they are being specified).

But the first thing is to get the list of virtual directories at which to start. This is mostly easily done with appcmd:

# Use array constructor to force an array, event with only one result
# format: VDIR "name" (physicalPath:path)
$vdirs = @(C:\Windows\system32\inetsrv\appcmd.exe list vdir)
$vdirs = $vdirs | Where-Object { -not [string]::IsNullOrEmpty($_) } | Foreach-Object -Process {
  if ($_ -match "physicalPath:([^)]+)\)$") {
   $matches[1]
  }
}

At this point $vdirs is an array of folders mapped to IIS.

Within each of these search for web.config files:

$configFiles = $vdirs | Foreach-Object -Process {
  Get-ChildItem -Path $_ -Recurse -Filter "web.config" | Foreach-Object -Process { $_.FullName }
}

Which is an array of the full path names of the web.config files. At this point you can use PowerShell's XML support to examine or update any part of the file you like

First up, as a general suggestion, unless your app definitely needs 64-bit addressing, run it in a 32-bit app pool. This naturally constrains memory use to 4GB per process.

Why might this be important? Well, because 4GB to a 64-bit application is a rounding error! If the .Net framework doesn't feel it's under memory pressure, it might not bother performing garbage collection. That's not a great answer, and I don't know why this would be the case under R2 and not R1, except for the possible memory size answer.

On Recycling: Recycling should create a new worker process on the next request, and by default gives the old one up to 90 seconds to terminate - recycling does restart the worker process (or at least, tells WAS to start a new WP next time a request arrives, and politely informs the last WP that it's being recycled). Unless Overlapping Recycling is disabled, you should see a new w3wp with a new PID as soon as the next request for that site is received.

If you're still seeing the leak in a 32-bit app pool, you'll need to troubleshoot it as a memory leak - consider taking a memory dump of the process when it's in the high memory state, and then look at debugging it with sos.dll or psscor2.dll to find the primary consumer of the memory.