Entender la Compilación Dinámica de ASP.NET

Entendiendo la compilación dinámica de ASP.NET

Cuando se hace un request a un sitio web, ASP.NET primero parsea y luego compila el código de la aplicación Web para convertirlo en uno o más assemblies. Cuando se compila el código, es traducido a una representación que es independiente del lenguaje y del CPU llamada Microsoft Intermediate Language (MSIL). En tiempo de ejecución, MSIL corre en el contexto del .NET Framework, el cual traduce MSIL en instrucciones específicas para ese CPU y para el procesador que corre la aplicación en dicho computador.

Compilación en el primer request

Por defecto, las páginas web de ASP.NET y el código embebido se compilan dinámicamente cuando los usuarios hacen el primer request a un recurso, como una página web ASP.NET (un .aspx). Luego que las páginas y el código embebido se compila por primera vez, se dejan estos recursos en un caché, así los subsecuentes request a esa misma página son extremadamente eficientes.
ASP.NET soporta Compilación dinámica de las páginas ASP.NET (.aspx), ASP.NET Web services (.asmx), ASP.NET HTTP handlers (.ashx) y ASP.NET application files (Global.asax), pero también otros archivos de código fuente como (*.aspx.vb) y clases (*.aspx.cs). Para más información de los tipos de archivo de ASP.NET, ver Web Site File Types. Para más información del proceso de compilación de ASP.NET, ver la sección "Compilation Life Cycle" de ASP.NET Application Life Cycle Overview.

Recompilación cuando hay cambios

Cualquier cambio de un archivo dinámicamente compilado invalida el assembly que está en caché y gatilla una recompilación de todos los recursos afectados. La próxima vez que se haga un request, ASP.NET reconoce que el código cambió y recompila los recursos afectados de la aplicación web. Este sistema permite desarrollar aplicaciones con un mínimo de sobrecarga en el proceso de compilación. (Notar que dependiendo del cambio que hay sobre un recurso, ASP.NET recompilará una sola página o todo el sitio Web.)

Dependencias de la compilación

Cuando se hace el primer request a la aplicación, ASP.NET compila los archivos en un orden específico. Los primero ítems en ser compilados son los llamados ítems de primer nivel.
Luego del primer request, los ítems de primero nivel se recompilan sólo si cambian las dependencias.
Los ítems de primer nivel incluyen las carpetas App_GlobalResources, App_WebResources, propiedades del perfil, carpeta App_Code y archivo Global.asax. Luego que los ítems de primer nivel se compilan, ASP.NET compila los ítems adicionales. Estos ítems incluyen la carpeta App_LocalResources, páginas ASP.NET (.aspx files), ASP.NET user controls (.ascx), ASP.NET HTTP Handlers (.ashx) y módulos ASP.NET HTTP (.asmx files), themes, master pages y otros archivos fuente. Para más información ver ASP.NET Web Site Layout y ASP.NET Application Life Cycle Overview.

Salida de la compilación

Cuando el código es compilado, los assemblys resultantes son "cacheados" en una carpeta en el servidor. Esta carpeta requiere los permisos apropiados para que tu código compilado se ejecute correctamente. Puedes configurar tanto la ubicación de la carpeta de compilación como los permisos con los que opera tu código compilado.

En producción, la primera vez que se accede al sitio, se compila y genera una carpeta dentro de Temporary ASP.NET Files de forma automática y se copian las DLL desde el \Bin a esta nueva carpeta dentro de Temporary ASP.NET Files.
Dejemos claro que no se genera una nueva carpeta aquí cada vez que se reinicia el IIS, a menos que esté bloqueado la carpeta \Bin y no deja copiarse a Temporary ASP.NET Files (problema conocido como "Copias Sombras/Shadow Copy". El error No se puede crear ni realizar copias sombra de 'dll' si el archivo ya existe/Cannot create/shadow copy 'dll' when that file already exists. Este error se resuelve desinstalando Windows Search del servidor, expluyendo la carpeta Temporary ASP.NET Files del escaneo del Antivirus, en el IIS moviendo la WebApp que da problemas a una AppPool propio cuando comparte el AppPool con más sitios), entonces al hacer un IIS reset verás la DLL copiada aquí.

Ubicación de la carpeta de compilación

Por defecto, cuando compilas una aplicación web, el código compilado queda en la conocida carpeta Temporary ASP.NET Files. Esta carpeta está dentro de la carpeta donde tienes instalado el Framework .Net. La ruta típica es:

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files

Por ejemplo, en una máquina de 64 bits, si está instalado el Framework 2.0 tendrías la carpeta:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files

Permisos requeridos para la carpeta de compilación

El proceso de instalación del Framework .NET crea la carpeta Temporary ASP.NET Files y le asigna permisos de acceso a la cuenta local de ASP.NET, el cual tiene los permisos necesarios para acceder al código compilado. Si modificas la configuración u opciones de la cuenta de usuario, asegúrate que la cuenta tenga suficientes permisos a la carpeta de Temporary ASP.NET Files. Para más detalles, ve How to: Run aspnet_wp.exe Under a User Account.

Configuración de la carpeta de compilación

ASP.NET crea una subcarpeta dentro de la carpeta Temporary ASP.NET File para cada aplicación. Puedes configurar la ubicación raíz usando el atributo tempDirectory de la sección compilación del archivo de configuración. Este atributo opcional permite especificar el directorio para almacenar los archivos temporales durante la compilación. Por defecto es un string vacío (""). En caso de ser un string vacío y si el proceso actual tiene los permisos de acceso necesario, los archivos son guardados en el siguiente directorio:

%FrameworkInstallLocation%\Temporary ASP.NET Files

Para más información, ver el Elemento compilación (ASP.NET Settings Schema) y la propiedad TempDirectory de la sección CompilationSection.

Soporte multilenguaje

ASP.NET 2.0 soporta múltiples lenguajes de programación en una misma aplicación web. En la carpeta App_Code, puedes especificar una subcarpeta para cada lenguaje, como C# y Visual Basic. ASP.NET creará un assembly separado para cada subcarpeta. Para más información ver Shared Code Folders in ASP.NET Web Sites y Walkthrough: Developing Web Sites Using Multiple Programming Languages.

Optimizando la compilación dinámica

A partir de un HotFix del Framework 3.5 se puede usar el atributo optimizeCompilations del web.config. Más info aquí.

Ventajas y desventajas de las compilación dinámica

La compilación dinámica de ASP.NET permite modificar el código fuente sin tener que explícitamente tener que compilar el código ni hacer un deploy en un servidor (Nota del traductor: como ejemplo práctico, permite que tengas un sitio web en un ambiente pre-productivo por ejemplo, donde tienes las dll tanto como los fuentes *.aspx.cs, y poder cambiar estos fuentes en "caliente", le das F5 al navegador y listo, el código se verá reflejado en el sitio. sirve para probar más rápidamente un cambio de un sitio en la capa web. Ahora si el proyecto web, usa un dll de otro proyecto, aunque tengas los fuentes de ese otro proyecto, si los cambias, no tomará el cambio en el proyecto web ya que ahí si requiere compilar dicha dll). Si modificas un código fuente, ASP.NET automáticamente recompila el archivo y actualiza todos los recursos que usan dicho archivo. No es necesario restetear el IIS para que tome el cambio a menos que la sección del web.config haya cambiado. Adicionalmente, puedes extender el sistema de compilación de ASP.NET al crear proveedores para que nuevos tipos de archivos sean llamados durante la compilación. La compilación dinámica beneficia al sistema de compilación de ASP.NET y es compatible con las estructuras y tipos de aplicación antiguas.

Hay ciertos aspectos que la compilación dinámica no ofrece. La Compilación dinámica puede hacer más lento el tiempo de respuesta de la carga inicial de un sitio por parte del usuario, ya que las páginas y archivos de código deben ser compilados la primera vez que son solicitados. Esto podría ser un problema si es un sitio muy grande y es cambiado frecuentemente.
La Compilación dinámica no identifica errores de compilación antes que los usuarios accedan al sitio.
También, la compilación dinámica no provee la funcionalidad de crear una versión compilada de un sitio que ya ha sido deployado en producción sin tener el código fuente.
Si alguno de esos problemas te afecta, lo mejor es precompilar el sitio y deployarlo a producción sólo con los elementos necesarios (sin todos los fuentes), un ejemplo clásico es la opción Publicar de Visual Studio. Para más información, ver ASP.NET Web Site Precompilation Overview.

Fuente

• https://msdn.microsoft.com/en-us/library/ms366723(v=vs.80)
• https://msdn.microsoft.com/en-us/library/ms366723(v=vs.100)

Testeando UrlScan 3.1 para IIS 7.5

Instalación

El otro día estaba viendo algo UrlScan, es una herramienta free de Microsoft para analizar requests así protegerte de ataques SQL Injection o Script Injection de forma simple, definiendo parámetros y opciones en un archivo ini.

Bajé la versión de 64 bits de https://www.microsoft.com/en-us/download/details.aspx?id=5728

Leí la documentación de: https://support.microsoft.com/es-es/kb/326444

El .ini queda instalado por defecto en: C:\Windows\System32\inetsrv\urlscan\UrlScan.ini

(Mi .ini que usé lo dejé al final)

La carpeta con los Logs: C:\Windows\System32\inetsrv\urlscan\logs\ le dí permiso de escritura al usuario IIS. En IIS 6 darle permiso de escritura al usuario IIS_WPG, y para IIS 7 u superior dale permisos a IIS_IUSRS.

En mi caso sólo usaré un filtro global, pero si quieres aplicar el filtro sólo para un sitio web, debes registrar la DLL como filtro en Web Sites -> Properties -> ISAPI Filters como dice aquí.

Al final de la instalación, reinicié el IIS con la línea de comandos iisreset.

Pruebas

NOTA: Por cada cambio en el .ini recomiendan Reciclar el Pool del sitio probado para que tome el cambio, si embargo a veces me tomaba sin necesidad de esto.

Error tilde IIS

Para corregir este conocido error de IIS 7 y 8: Microsoft IIS tilde directory enumeration, debes ir a Inicio -> Ejecutar:

%windir%\system32\inetsrv\urlscan

Agregar en UrlScan.ini (no requiere reiniciar el servidor, si aplicar un IIS reset)

[DenyUrlSequences]
~ ; para corregir error Microsoft IIS tilde directory enumeration

NOTA: Si tienes instalado Acunetix para auditar la seguridad de tus sitios, este error de tilde lo detecta de una, pero con esta corrección deja de aparecer el error.

SQL INJECTION

Al probar con la URL que tiene un "intento" de SQL Injection:

http://misitio.cl/index.asp?select=1

Resultado: Error 404 con detalles



Resultado desde fuera del sitio: Error 404 sin detalles (este error daría si el UrlScan está en producción y queremos acceder desde afuera):



Como nota, el mismo error da cuando escribimos un "intento" de Script Injection:

http://misitio.cl/index.asp?title=<meta%20http-equiv="refresh"%20content="0;">

Logging

El log, en mi caso, urlscan.111615.log, (es 16-nov-2015) va quedando con las entradas bloqueadas y el string o secuencia inválida:

#Software: Microsoft UrlScan 3.1
#Version: 1.0
#Date: 2015-11-16 20:09:41
#Fields: Date Time c-ip s-siteid cs-method cs-uri x-action x-reason x-context cs-data x-control
2015-11-16 20:09:43 172.31.17.26 9 GET /index.asp?item=%3C Rejected disallowed+query+string+sequence query+string - <

Errores comunes

El log solo logea los títulos de las columnas

-Revisa el archivo ini, que no tengas un [Options] ya que en el ejemplo del mismo .ini dice [Options].

Yo tenía:

[Options]
RuleList=SQL Injection

Y debe ser sólo:

RuleList=SQL Injection

-Revisa que le hayas dado permisos de escritura a la carpeta log al usuario de IIS.

Conclusión

UrlScan es la solución para evitar andar programando en el código (IF request ("%, <, >, etc...) == "error") ya que sólo mediante configuración filtras todo lo malo .

Referencias

• http://www.iis.net/learn/extensions/working-with-urlscan/common-urlscan-scenarios
• http://plynt.com/blog/2009/03/urlscan---first-line-of-defens/
• http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-3-reference

Anexo: Mi archivo ini

Mi .ini que usé es este. Notar que dejé ScanHeaders=Cookie para incluir que si se crea una Cookie, se validen los strings que tenga como valor:

[options]

UseAllowVerbs=1                ; If 1, use [AllowVerbs] section, else use the
                               ; [DenyVerbs] section.   The default is 1.

UseAllowExtensions=0           ; If 1, use [AllowExtensions] section, else
                               ; use the [DenyExtensions] section. The
                               ; default is 0.

NormalizeUrlBeforeScan=1       ; If 1, canonicalize URL before processing.
                               ; The default is 1.  Note that setting this
                               ; to 0 will make checks based on extensions,
                               ; and the URL unreliable and is therefore not
                               ; recommend other than for testing.

VerifyNormalization=1          ; If 1, canonicalize URL twice and reject
                               ; request if a change occurs.  The default
                               ; is 1.

AllowHighBitCharacters=0       ; If 1, allow high bit (ie. UTF8 or MBCS)
                               ; characters in URL.  The default is 0.

AllowDotInPath=0               ; If 1, allow dots that are not file
                               ; extensions. The default is 0. Note that
                               ; setting this property to 1 will make checks
                               ; based on extensions unreliable and is
                               ; therefore not recommended other than for
                               ; testing.

RemoveServerHeader=0           ; If 1, remove the 'Server' header from
                               ; response.  The default is 0.

EnableLogging=1                ; If 1, log UrlScan activity.  The
                               ; default is 1.  Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.

PerProcessLogging=0            ; This property is deprecated for UrlScan
                               ; 3.0 and later.  UrlScan 3.0 and later can
                               ; safely log output from multiple processes
                               ; to the same log file.  Changes to this
                               ; property will not take effect until
                               ; UrlScan is restarted.

AllowLateScanning=0            ; If 1, then UrlScan will load as a low
                               ; priority filter.  The default is 0.  Note
                               ; that this setting should only be used in
                               ; the case where there another installed
                               ; filter is modifying the URL and you wish
                               ; to have UrlScan apply its rules to the
                               ; rewritten URL.  Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.

PerDayLogging=1                ; If 1, UrlScan will produce a new log each
                               ; day with activity in the form
                               ; 'UrlScan.010101.log'. If 0, UrlScan will
                               ; log activity to urlscan.log.  The default
                               ; is 1.  Changes to this setting will not
                               ; take effect until UrlScan is restarted.

UseFastPathReject=0            ; If 1, then UrlScan will not use the
                               ; RejectResponseUrl.  On IIS versions less
                               ; than 6.0, this will also prevent IIS
                               ; from writing rejected requests to the
                               ; W3SVC log.  UrlScan will log rejected
                               ; requests regardless of this setting.  The
                               ; default is 0.

LogLongUrls=0                  ; This property is deprecated for UrlScan 3.0
                               ; and later. UrlScan 3.0 and later will
                               ; always include the complete URL in its log
                               ; file.

UnescapeQueryString=1          ; If 1, UrlScan will perform two passes on
                               ; each query string scan, once with the raw
                               ; query string and once after unescaping it.
                               ; If 0, UrlScan will only look at the raw
                               ; query string as sent by the client.  The
                               ; default is 1. Note that if this property is
                               ; set to 0, then checks based on the query
                               ; string will be unreliable.

;
; If UseFastPathReject is 0, then UrlScan will send
; rejected requests to the URL specified by RejectResponseUrl.
; If not specified, '/Rejected-by-UrlScan' will be used.
; Changes to this setting will not take effect until UrlScan
; is restarted.
;
; Note that setting "RejectResponseUrl=/~*" will put UrlScan into Logging
; Only Mode.  In this mode, UrlScan will process all requests per the
; config settings, but it will only log the results and not actually
; reject the requests.  This mode is useful for testing UrlScan settings
; on a production server without actually interrupting requests.
;

RejectResponseUrl=

;
; LoggingDirectory can be used to specify the directory where the
; log file will be created.  This value should be the absolute path
; (ie. c:\some\path).  If not specified, then UrlScan will create
; the log in the same directory where the UrlScan.dll file is located.
; Changes to this setting will not take effect until UrlScan is
; restarted.
;

LoggingDirectory=Logs

;
; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header
;

AlternateServerName=

;
; UrlScan supports custom rules that can be applied in addition to the other
; checks and options specified in this configuration file.  Rules should be
; listed in a comma separated string in the RuleList property.  Each rule in
; the list corresponds to two sections in this configuration file, one
; containing the options for the rule, and one containing deny strings for
; the rule.
;
; Here is an example:
;
;   [Options]
;   RuleList=Rule1
;
;   [Rule1]
;   AppliesTo=.exe,.dll        ; A comma separated list of file extensions to
;                              ; which the rule applies.  If not specified,
;                              ; the rule will be applied to all requests.
;
;   DenyDataSection=Rule1 Data ; The name of the section containing the
;                              ; rule's deny strings
;
;   ScanURL=0                  ; If 1, the URL will be scanned for deny
;                              ; strings. The default is 0.
;
;   ScanAllRaw=0               ; If 1, then the raw request header data will
;                              ; be scanned for deny strings.  The default
;                              ; is 0.
;
;   ScanQueryString=0          ; If 1, the the query string will be scanned
;                              ; for deny strings.  The default is 0.  Note
;                              ; that if UnescapeQueryString=1 is set in the
;                              ; [Options] section, then two scans will be
;                              ; made of the query string, one with the raw
;                              ; query string and one with the query string
;                              ; unescaped.
;
;   ScanHeaders=               ; A comma separated list of request headers to
;                              ; be scanned for deny strings.  The default is
;                              ; no headers.
;
;   DenyUnescapedPercent=0     ; If 1, UrlScan will scan the specified part
;                              ; of the raw request for a % character that is
;                              ; not used as an escape sequence.  If found,
;                              ; the request will be rejected.  This check
;                              ; can be used with ScanQueryString=1,
;                              ; ScanAllRaw=1, or the list of ScanHeaders.
;                              ; The default is 0.  Note that if you want to
;                              ; deny non-escaped % characters in the URL,
;                              ; you can set VerifyNormalization=0 in the
;                              ; [Options] section and then add % as a
;                              ; [DenyUrlSequences] entry.
;
;   [Rule1 data]
;   string1
;   string2
;

RuleList=SQL Injection

[SQL Injection]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=1
ScanHeaders=Cookie:


[SQL Injection Strings]
--
@ ; also catches @@
alter
cast
convert
create
declare
delete
drop
exec ; also catches execute
fetch
insert
kill
select

[RequestLimits]

;
; The entries in this section impose limits on the length
; of allowed parts of requests reaching the server.
;
; It is possible to impose a limit on the length of the
; value of a specific request header by prepending "Max-" to the
; name of the header.  For example, the following entry would
; impose a limit of 100 bytes to the value of the
; 'Content-Type' header:
;
;   Max-Content-Type=100
;
; Any headers not listed in this section will not be checked for
; length limits.
;
; There are 3 special case limits:
;
;   - MaxAllowedContentLength specifies the maximum allowed
;     numeric value of the Content-Length request header.  For
;     example, setting this to 1000 would cause any request
;     with a content length that exceeds 1000 to be rejected.
;     The default is 30000000.
;
;   - MaxUrl specifies the maximum length of the request URL,
;     not including the query string. The default is 260 (which
;     is equivalent to MAX_PATH).
;
;   - MaxQueryString specifies the maximum length of the query
;     string.  The default is 2048.
;

MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048

[AllowVerbs]

;
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
;
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
;

GET
HEAD
POST

[DenyVerbs]

;
; The verbs (aka HTTP methods) listed here are used for publishing
; content to an IIS server via WebDAV.
;
; Note that these entries are effective if "UseAllowVerbs=0"
; is set in the [Options] section above.
;

PROPFIND
PROPPATCH
MKCOL
DELETE
PUT
COPY
MOVE
LOCK
UNLOCK
OPTIONS
SEARCH

[DenyHeaders]

;
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
;

Translate:
If:
Lock-Token:
Transfer-Encoding:

[AllowExtensions]

;
; Extensions listed here are commonly used on a typical IIS server.
;
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.
;

.htm
.html
.txt
.jpg
.jpeg
.gif

[DenyExtensions]

;
; Extensions listed here either run code directly on the server,
; are processed as scripts, or are static files that are
; generally not intended to be served out.
;
; Note that these entries are effective if "UseAllowExtensions=0"
; is set in the [Options] section above.
;
; Also note that ASP scripts are denied with the below
; settings.  If you wish to enable ASP, remove the
; following extensions from this list:
;    .asp
;    .cer
;    .cdx
;    .asa
;

; Deny executables that could run on the server
.exe
.bat
.cmd
.com

; Deny infrequently used scripts
.htw     ; Maps to webhits.dll, part of Index Server
.ida     ; Maps to idq.dll, part of Index Server
.idq     ; Maps to idq.dll, part of Index Server
.htr     ; Maps to ism.dll, a legacy administrative tool
.idc     ; Maps to httpodbc.dll, a legacy database access tool
.shtm    ; Maps to ssinc.dll, for Server Side Includes
.shtml   ; Maps to ssinc.dll, for Server Side Includes
.stm     ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services

; Deny various static files
.ini     ; Configuration files
.log     ; Log files
.pol     ; Policy files
.dat     ; Configuration files
.config  ; Configuration files

[AlwaysAllowedUrls]
;
; URLs listed here will always be explicitly allowed by UrlScan
; and will bypass all UrlScan checks.  URLs must be listed
; with a leading '/' character.  For example:
;
;   /SampleURL.htm
;

[DenyUrlSequences]
;
; If any character sequences listed here appear in the URL for
; any request, that request will be rejected.
;

..  ; Don't allow directory traversals
./  ; Don't allow trailing dot on a directory name
\   ; Don't allow backslashes in URL
:   ; Don't allow alternate stream access
%   ; Don't allow escaping after normalization
&   ; Don't allow multiple CGI processes to run on a single request

[AlwaysAllowedQueryStrings]
;
; Query strings listed here will always be explicitly allowed by
; UrlScan and will bypass all query string based checks.
;


[DenyQueryStringSequences]
;
; If any character sequences listed here appear in the query
; string for any request, that request will be rejected.
;

<   ; Commonly used by script injection attacks
>   ; Commonly used by script injection attacks

NullReferenceException en método AjaxRequestProcessor.Run() con AjaxPro 5.7.22.2

Antecedentes

Alguien se le ocurrió una vez, que la mejor forma de conectarse de forma asíncronica desde Javascript (no existía jQuery como ahora) al servidor Web era usando AjaxPro (Ajax.dll). Bueno, eso funcionó, pero trajo un problema arrastrado por años, ahora que me dijeron "resuélvelo de una vea papá". Bueno, el error lo logré resolver luego de semanas cabezeandome. El mensaje en el Visor de Eventos decía en resumen:

NullReferenceException en Ajax.AjaxRequestProcessor.Run()

Antecedentes productivos:

• Se usaron dos tipos de servidores, web primero Windows Server 2003 32 bit y luego Windows Server 2008 64 bit.
• El ambiente productivo usa Framework 2.0 y Visual Basic .NET.
• La arquitectura es un balanceador con 4 servidores Web y un servidor de base de datos.
• Son 4 aplicaciones Web, las 4 usan 4 AppPool, 3 AppPool tienen 3 worker process y uno tiene 7. Todos tienen diferente tiempo de reciclaje.
• El ambiente tiene mediana carga 2000 RPM (Request por Minuto) según la fabulosa herramienta Newrelic.
• Las 4 aplicaciones usan Ajax.dll 5.7.22.2 liberada por el año 2005.

Antecedentes del error:

• El error da irregularmente, sin un horario dado.
• El problema puede dejar de dar durante días.
• El error no daba en ambiente de desarrollo (lo típico).

El error registrado en el visor de Eventos es:

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 10/18/2015 3:12:47 PM 
Event time (UTC): 10/18/2015 6:12:47 PM 
Event ID: 305bbfa9f184433986b6655786e66f72 
Event sequence: 50 
Event occurrence: 1 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/416041936/Root/SitioTest-1-130896653636875000 
    Trust level: Full 
    Application Virtual Path: /SitioTest 
    Application Path: C:\Inetpub\wwwroot\Test\Sitio\1.0\SitioTest\ 
    Machine name: Servidor-1 
 
Process information: 
    Process ID: 6948 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\NETWORK SERVICE 
 
Exception information: 
    Exception type: NullReferenceException 
    Exception message: Object reference not set to an instance of an object. 
 
Request information: 
    Request URL: http://sitio.cl/folder/ajax/SitioWebDotNet.namespace_clase,App_Web_datos.aspx.fe7917e2.ashx 
    Request path: /sitio/ajax/SitioWebDotNet.sitio_namespace_sitio,App_Web_datos.aspx.fe7917e2.ashx 
    User host address: X.X.X.X 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
 
Thread information: 
    Thread ID: 1 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersonating: True 
    Stack trace:    at Ajax.AjaxRequestProcessor.Run()
   at Ajax.AjaxHandler.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 
 
Custom event details: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Si uno miraba el contenido del ashx indicado en el error: http://sitio.cl/folder/ajax/SitioWebDotNet.namespace_clase,App_Web_datos.aspx.fe7917e2.ashx, no había nada raro.

Lo que intenté, sin que funcionara

• Cambiar la DLL 5.7.22.2 a la última versión 9.2.17.1. No fue posible por que la versión que uso no usa JSON y la nueva usa JSON, cambiar todo el código, validar las entradas y salidas era mucho trabajo, quizá de meses.
• Dejar sólo un servidor, sacándolo del balanceador de carga.
• Revisar el código fuente: JS, código VB.Net, no encontré errores.
• Dejar todos los Pool con 3 WP y el mismo tiempo de reciclaje.
• Evalué pasar de AjaxPro a Ajax 1.0 de Microsoft, pero la cantidad de código era inmensa.
• El error no da cuando se recicla un pool, era una teoría que tenía
• Revisé los LOGS de IIS de los 4 servidores y no había algún de patrón del error, que fallara en todos a una hora, o que luego de un reciclaje de los pool fallara.

Solución

La solución fue para cada uno de los 4 Pool de las aplicaciones bajar todos los Worker Process a 1. De pasada dejarles el mismo tiempo de reciclaje. Me acordé que en el blog de Google se hablaba que tenía problemas en balanceo, y quizá pensé el error se da en Web Farm y Web Garden. Y era eso, ¡toque y fama!. Luego de monitorear los errores del visor de eventos durante 2 semanas observé que el problema desapareció. Recomiendo usar para visualizar de mejor forma los Event Logs la herramienta Event Log Explorer, que tiene una licencia Free.

Referencias

• https://groups.google.com/forum/#!topic/ajaxpro/Y34i0QB0-K8
• http://ajaxpro.codeplex.com/releases/view/23363
• http://www.ajaxpro.info/quickguide.aspx
• http://go.microsoft.com/fwlink/?LinkId=75350

Bueno, espero que les sirva de ayuda, en caso que tengan este engorroso error.