Recuerdo un caso en el que un cliente tenía un OutOfMemory subiendo ficheros de más de 1GB a un FTP usando las clases de .NET. Recordemos que el límite de memoria virtual que tiene un proceso de 64 bit es de 8 TB o 128 TB en Windows 8.1/10/2012 R2 (Memory Limits for Windows and Windows Server Releases)

Técnicamente es posible tener ese OutOfMemory puesto que podríamos crear una aplicación que consuma memoria hasta llegar a ese límite de memoria. Pero, ¿cómo es posible tener ese OutOfMemory si subimos un fichero de 1.4 GB y nos quedan más de 120 TB libres en el proceso?

Usando este código (de la MSDN) , veremos cómo es posible conseguir la excepción subiendo el fichero:

            string user = "";

            string pass = "";

            string file = "";

            string ftpUri = "";

            try

            { 

                if (args.Length == 0)

                {

                    Console.WriteLine("Enter username: ");

                    user = Console.ReadLine(); 

                    Console.WriteLine("Enter password: ");

                    pass = Console.ReadLine(); 

                    Console.WriteLine("Enter file name: ");

                    file = Console.ReadLine(); 

                    Console.WriteLine("Enter FTP URi: ");

                    ftpUri = Console.ReadLine();  

                }

                else

                {

                    user = args[0];

                    pass = args[1];

                    file = args[2];

                    ftpUri = args[3];

                }

                 FtpWebRequest request = (FtpWebRequest)WebRequest.Create(ftpUri);

                request.Method = WebRequestMethods.Ftp.UploadFile;                              

                request.Credentials = newNetworkCredential(user, pass);                               

                StreamReader sourceStream = newStreamReader(file);

                Console.ReadLine(); 

                byte[] fileContents = Encoding.UTF8.GetBytes(sourceStream.ReadToEnd());

                sourceStream.Close();

                request.ContentLength = fileContents.Length; 

                Stream requestStream = request.GetRequestStream();

                requestStream.Write(fileContents, 0, fileContents.Length);

                requestStream.Close(); 

                FtpWebResponse response = (FtpWebResponse)request.GetResponse(); 

                Console.WriteLine("Upload File Complete, status {0}", response.StatusDescription);

                response.Close();

            }

            catch(Exception ex)

            {

                Console.WriteLine("An exception has occurred: {0}", ex.Message);

            }

Como decía, ejecutando este código, tendremos una OutOfMemoryException, concretamente cuando intentemos convertir el Stream del fichero que queremos subir a un array de bytes:

                byte[] fileContents = Encoding.UTF8.GetBytes(sourceStream.ReadToEnd());

Si hemos adjuntado un depurador, veremos algo como esto:

# Call Site
00 KERNELBASE!RaiseException
01 clr!DllCanUnloadNowInternal
02 clr!TranslateSecurityAttributes
03 clr!NGenCreateNGenWorker
04 mscorlib_ni!System.Text.StringBuilder.ToString()
05 FTPClient!FTPCLient.Main(System.String[])

Lo que ocurre es que estamos convirtiendo un fichero muy grande en el array de bytes directamente. Lo recomendado sería usar un buffer para evitar este comportamiento: Subir ficheros con buffer

También podemos usar los objetos muy grandes de .NET (como menciono en este otro artículo: OutOfMemoryException al manejar StringBuilder en un proceso de 64 bitshttps://blogs.msdn.com/b/desarrolloweb/archive/2016/02/17/stringbuilder-outofmemory.aspx) 

Espero que os sirva.

-- José Ortega Gutiérrez

¿Es posible tener un OutOfMemory con un proceso que tenga menos de 5GB de memoria virtual, sin fragmentación aparente y que se (obviamente) se ejecute en 64 bits?

Gracias a determinados usos de StringBuilder sí podemos tenerlo. Con este pequeño código conseguiremos tener nuestro deseado OutOfMemory y el proceso tendrá un consumo de 4,5 GB

  string void main(string[] args)

   {

            const string lala = "lalalalalalalalalalalalalalalalalalalalala";

            StringBuilder sb = new StringBuilder();

            for (int i = 0; i < int.MaxValue/2; i++)

            { 

                sb.Append(lala);     

                Console.WriteLine(string.Format("Longitud de la cadenaEnter username: {0} ", sb.ToString().Length));                   

            }

   }

¿Cuál es el motivo si tenemos más de 127 TB libres?. Para descubrirlo, tenemos que ahondar en lo que ocurre cuando salta la excepción. Vemos el método que causa la excepción ExpandByABlock, que se usa cuando el objeto StringBuilder piensa que se ha llenado el último chunk de información y tenemos que pasar a uno nuevo:

0:000> kc
# Call Site
00 clr!IL_Throw
01 mscorlib_ni!System.Text.StringBuilder.ExpandByABlock(Int32)
02 mscorlib_ni!System.Text.StringBuilder.Append(Char*, Int32)
03 mscorlib_ni!System.Text.StringBuilder.AppendHelper(System.String)
04 mscorlib_ni!System.Text.StringBuilder.Append(System.String)
05 consoleapplication2!ConsoleApplication2.Program.Main(System.String[])
06 clr!CallDescrWorkerInternal
07 clr!CallDescrWorkerWithHandler
08 clr!MethodDescCallSite::CallTargetWorker
09 clr!MethodDescCallSite::Call
0a clr!RunMain
0b clr!Assembly::ExecuteMainMethod
0c clr!SystemDomain::ExecuteMainMethod
0d clr!ExecuteEXE
0e clr!_CorExeMainInternal
0f clr!_CorExeMain
10 mscoreei!_CorExeMain
11 mscoree!ShellShim__CorExeMain
12 mscoree!_CorExeMain_Exported
13 kernel32!BaseThreadInitThunk
14 ntdll!RtlUserThreadStart

 

Estupendo, pero esto no explica el motivo por el que falla. Así que tenemos que ver qué hace este método. La información pública la tenemos aquí: https://referencesource.microsoft.com/#mscorlib/system/text/stringbuilder.cs,bb3473794f7408f5 

             ///<summary>
        /// Assumes that 'this' is the last chunk in the list and that it is full. Upon return the 'this'
        /// block is updated so that it is a new block that has at least 'minBlockCharCount' characters.
        /// that can be used to copy characters into it.
        ///</summary>
        private void ExpandByABlock(int minBlockCharCount)
        {
            Contract.Requires(Capacity == Length, "Expand expect to be called only when there is no space left");        // We are currently full
            Contract.Requires(minBlockCharCount > 0, "Expansion request must be positive");

            VerifyClassInvariant();

            if ((minBlockCharCount + Length) > m_MaxCapacity)
                throw new ArgumentOutOfRangeException("requiredLength", Environment.GetResourceString("ArgumentOutOfRange_SmallCapacity"));

            // Compute the length of the new block we need
            // We make the new chunk at least big enough for the current need (minBlockCharCount)
            // But also as big as the current length (thus doubling capacity), up to a maximum
            // (so we stay in the small object heap, and never allocate really big chunks even if
            // the string gets really big.
            int newBlockLength = Math.Max(minBlockCharCount, Math.Min(Length, MaxChunkSize));

            // Copy the current block to the new block, and initialize this to point at the new buffer.
            m_ChunkPrevious = new StringBuilder(this);
            m_ChunkOffset += m_ChunkLength;
            m_ChunkLength = 0;

            // Check for integer overflow (logical buffer size > int.MaxInt)
           if (m_ChunkOffset + newBlockLength < newBlockLength)
            {
                m_ChunkChars = null;
                throw new OutOfMemoryException();
            }
            m_ChunkChars = new char[newBlockLength];

            VerifyClassInvariant();
        }

Si vamos paso a paso en nuestro proceso, veremos que cuando falla, los valores del StringBuilder son estos. Nos vamos a fijar especialmente en m_ChuckLength:

Name:        System.Text.StringBuilder
…
Fields:
                 Type VT     Attr            Value Name
        System.Char[]  0 instance 0000000000000000 m_ChunkChars
...ext.StringBuilder  0 instance 00000234eae27fc8 m_ChunkPrevious
         System.Int32  1 instance                0 m_ChunkLength
         System.Int32  1 instance       2147481216 m_ChunkOffset
         System.Int32  1 instance       2147483647 m_MaxCapacity

Tenemos un apartado en el que nos dice que la suma de m_ChunkOffset + newBlockLenght sea menor que newBlockLength. Estamos frente a otra incongruencia, ¿cómo es posible que la suma de un valor positivo más otro valor positivo sea menor que el primer valor?. No es tan incongruente, pensemos que hemos sobrepasado el límite máximo de un valor entero, por lo que el valor resultante, cogiendo sólo los dígitos de int64, es inferior.

Vemos los valores que vamos a ir teniendo m_ChunkOffset tiene un valor de 2147481216 y trans comprobar la operación de Math.Max tenemos que el valor de newBlockLength es 8000. Esto implica que la suma de ambos es 2147489216, pero como el valor es mayor que int.MaxValue, nos hemos pasado y nos vamos a quedar con un valor real de 5569, que es menor que los 8000 de newBlockLength, así que acabamos lanzando un OutOfMemoryException porque hemos llegado al límite de StringBuilder.

Tened en cuenta que estamos tratando con un valor máximo de un objeto de 2GB, por lo que nuestro String debería ser más pequeño. Para objetos más grandes, tenemos esta propiedad gcAllowVeryLargeObjects que nos permite que los arrays superen el límite de 2GB.

Espero que os sirva de ayuda

- José Ortega Gutiérrez

Esto puede deberse a que estamos empleando cuadros de diálogo en un proceso de Session 0. Cuando un usuario se autentica en una máquina Windows, se crea un Session ID, empezando por el 1, quedando reservado el 0 para los servicios y procesos que ejecuta el sistema operativo.

Por lo que estos procesos no se ejecutan en un escritorio, no teniendo interacción directa con el usuario con ventanas. ¿Qué ocurre si añadimos una ventana a uno de estos procesos?, pues que no tendremos a un usuario que pueda interaccionar con ella, por lo que si la ventana está en espera a que el usuario haga click en algún botón, pero no tenemos usuario, el hilo que tiene esa petición quedará bloqueado esperando una respuesta que nunca llegará.

Ese es el motivo por el que no podemos tener cuadros de diálogo en una aplicación que está en la sesión 0, porque afecta al rendimiento de la aplicación pudiendo hacer que se llegue a bloquear el proceso.

Espero que os sirva de ayuda.

- José Ortega Gutiérrez

· 2 Controllers: Windows 2008 R2

· 1 Primario: Windows 2008 R2

· Varios Secundarios: Windows 2008 R2

Poco a poco, el consumo de memoria en el WebFarmservice.exe está aumentando en los controllers y en algunos secundarios llegando hasta el punto de tener que reiniciar los servidores para solventarlo.

Para ver que ocurre, lo más fácil es revisar el comportamiento que estamos teniendo tal y como os conté en este post: https://blogs.msdn.com/b/desarrolloweb/archive/2012/05/06/asp-net-problemas-rendimiento.aspx

Pero en este caso veremos cómo el leak de memoria está en memoria nativa, por lo que necesitaríamos otro plan de acción

Día 1

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal

Free                                    193      7ff`c6796000 (   7.999 Tb)           99.99%

.NET                                     144        0`1ac7a000 ( 428.477 Mb)  46.56%    0.01%

Heap                                      97        0`16921000 ( 361.129 Mb)  39.24%    0.00%

Image                                   763        0`069da000 ( 105.852 Mb)  11.50%    0.00%

Stack                                    80        0`01700000 (  23.000 Mb)   2.50%    0.00%

Other                                    13        0`001b6000 (   1.711 Mb)   0.19%    0.00%

TEB                                      23        0`0002e000 ( 184.000 kb)   0.02%    0.00%

PEB                                       1        0`00001000 (   4.000 kb)   0.00%    0.00%

Día 5

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal

Free                                    200      7ff`91d80000 (   7.998 Tb)           99.98%

Heap                                    189        0`4b031000 (   1.172 Gb)  68.10%    0.01%

.NET                                     144        0`1ac7a000 ( 428.477 Mb)  24.31%    0.01%

Image                                   755        0`069da000 ( 105.852 Mb)   6.01%    0.00%

Stack                                    91        0`01a00000 (  26.000 Mb)   1.48%    0.00%

Other                                    13        0`001b6000 (   1.711 Mb)   0.10%    0.00%

TEB                                      26        0`00034000 ( 208.000 kb)   0.01%    0.00%

PEB                                       1        0`00001000 (   4.000 kb)   0.00%    0.00%

Por lo que en este caso podemos usar LeakTrace para saber quién está haciendo las alocaciones de memoria por ejemplo usando DebugDiag

Examinando los volcados podremos ver quién no está liberando la memoria que usa. Si vemos un escenario parecido a este:

msvcrt!malloc+70  

nativerd!operator new+23  

nativerd!SCHEMA_ELEMENT::Clone+3f

nativerd!SCHEMA_ELEMENT::CreateElementObject+8d3

nativerd!SCHEMA_ELEMENT::CreateElementObject+973

nativerd!SCHEMA_ENTRY::CreateConfigElement+c9

nativerd!CONFIG_SECTION::ParseConfigSetting+29e

nativerd!SECTION_GROUP_TABLE::ParseConfigSetting+2fa

nativerd!CONFIG_FILE::ParseLocation+2ba

nativerd!CONFIG_FILE::ParseTopLevelElements+493

nativerd!CONFIG_FILE::ParseDom+d9

nativerd!CONFIG_FILE::ParseConfigFile+247

nativerd!CONFIG_CACHE::ParseConfigFile+3e

nativerd!CONFIG_CACHE::CacheMiss+a699      

nativerd!CONFIG_CACHE::ProcessConfigPath+4b25      

nativerd!CONFIG_CACHE::GetConfigFileList+40

nativerd!CONFIG_SYSTEM::GetConfigSectionInternal+1f2

nativerd!CONFIG_SYSTEM::GetAdminSection+b5 

mscorwks!DoCLRToCOMCall+177

En este artículo podemos ver como versiones anteriores de nativerd puede provocar un memory leak al no liberar memoria. Aunque describe otro escenario, el comportamiento que describe es el mismo: https://support.microsoft.com/kb/2618982

Instalando el hotfix debería solucionarse el problema.

Espero que os sirva de ayuda.

- José Ortega Gutiérrez

En estos artículos https://support.microsoft.com/kb/2580348 y  https://blogs.msdn.com/b/tess/archive/2006/04/13/575364.aspx tenemos información sobre las acciones que realizan cuando se activa el modo debug:

1. Code will execute slower due to additional debug paths being enabled.
2. Compilation will take longer because additional debug information is being generated, such as symbol (.pdb) files.
3. Execution timeout is extended to 30,000,000 seconds.
4. Scripts and images downloaded from the WebResource.axd and ScriptResource.axd handlers are not cached.
5. Code optimization is disabled.

¿Cuáles son los efectos prácticos de tener habilitado el modo debug en nuestras aplicaciones? Al final el resultado es que nuestra aplicación se va a tardar más en realizar las mismas acciones que si no estuviese el debug habilitado.

En este sencillo ejemplo podemos ver una operación que tiene varias iteraciones. El código captura el tiempo antes de realizar unas iteraciones y justo después de que terminen. Podemos ver que si el modo debug está habilitado y las librerías están compiladas en como debug, el tiempo de ejecución de la secuencia es de 29 segundos.

Sin embargo, ese mismo código, ejecutado sin el modo debug y con las librerías compiladas como release, tarda 11 segundos. Estamos hablando de que tarda tres veces menos cambiando un parámetro en el fichero de configuración y un parámetro en el Visual Studio.

No quiero decir que haciendo eso se va a mejorar tres veces más el tiempo de ejecución, puesto que dependerá de la codificación de la aplicación y de otros factores, pero sí que hará que el rendimiento sea mucho mejor.

Espero que os sirva.

- José Ortega Gutiérrez

El problema reside en las claves de encriptación de la máquina, al realizar un sysprep sobre la máquina, estas claves cambian por lo que el IIS no es capaz de desencriptar las claves de las credenciales por lo que no puede auntenticar al usuario por lo que o bien no puede iniciar los Application Pools porque no es capaz de leer la clave o bien no podrá autenticar a un usuario con credenciales fijas  en una aplicación.

Lo primero que debemos saber es que no está soportado el aplicar sysprep en una máquina que tenga un IIS en el que su configuración. Entre otras cosas porque cambia todas las claves de encriptación y por eso no puede funcionar. En este artículo se detalle el soporte de sysprep en una máquina con IIS: https://technet.microsoft.com/en-us/library/dd744581(WS.10).aspx 

La mejor opción es la de clonar la máquina sin esas claves de encriptación, porque esto nos evitaría todos estos conflictos. Otras alternativa puede ser el emplear una configuración compartida o usar MSDeploy para exportar la configuración sin los valores encriptados.

Espero que os sirva de ayuda

- José Ortega Gutiérrez

Ahora vamos a imaginar que no se actualiza, sin embargo, si realizamos los mismos cambios pero vemos la página directamente, sin usar el iFrame, los cambios aparecen nada más dar a refrescar la página en el navegador.

Lo que parece que ocurre es que estando dentro del iFrame, el navegador están enviando una fecha de modificación que no es la más actual, por lo que cuando el IIS recibe el entiende que el navegador tiene la última versión así que envía un 304 sin enviar contenido. En este artículo tienes más información sobre el estado: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.HTML

Una forma de evitarlo es quitar el cacheo en la ruta dónde esté esa página.

IIS 6

En este artículo se indica cómo se deshabilita: https://support.microsoft.com/kb/247404

CSCRIPT ADSUTIL.VBS SET W3SVC/1/ROOT/NombreDirectorioVirtual/CacheControlCustom "no-cache"

IIS 7

En este artículo se indica cómo se deshabilita: https://www.iis.net/configreference/system.webserver/caching

Espero que os sirva de ayuda

- José Ortega Gutiérrez

El problema no está realmente en Office, sino en que esté abierto el fichero en modo exclusivo.

Uno de los cambios de FTP, es que accede a un fichero en modo de acceso de lectura exclusivo, por lo que necesita que el fichero que intenta abrir no esté siendo utilizado.

Si el fichero está siendo bloqueado por Excel, el FTP devolverá el error que te está mostrando. Sí que permite abrir ficheros que estén siendo usados por aplicaciones que no bloquean el fichero. Nos habéis comentado que habéis probado a abrir ese mismo fichero con el bloc de notas y no habéis tenido errores.

Dado que el comportamiento que está teniendo el IIS es por diseño, no podemos modificarlo, pero sí podemos daros algunas alternativas, como el uso de WebDAV o el directory Browsing.

WebDAV

Esta opción te permitirá acceder a los recursos usando el explorador de Windows pero internamente usando HTTP, permitiendo que puedas mapear unidades de red a una URL del IIS. Así pues podrás asignar una localización remota en un directorio virtual y acceder a través del explorador de Windows usando la URL de ses directorio virtual.

Para instalar y configurar WebDAV te dejo este artículo: https://www.iis.net/learn/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis

Así como estos artículos que comentan cómo solventar algunos problemas que puedan surgir: https://blogs.msdn.com/b/desarrolloweb/archive/tags/webdav/

Directory Browsing

Esta opción permite que desde el navegador puedas listar el contenido del directorio Virtual.

En este artículo te dejo las instrucciones para configurarlo: https://www.iis.net/configreference/system.webserver/directorybrowse

Espero que os sirva de ayuda

- Jose Ortega Gutiérrez

¿Por qué funciona cuando va a través de un proxy o a través de SSL pero no cuando juntamos los dos?

La respuesta es que cuando se realiza una petición HTTPS a un proxy se usan dos manejadores, uno para la petición exterior y otro para manejar el CONNECT del túnel del proxy. Por lo que se marca el flag INTERNET_NO_CALLBACK para evitar que el que invoca pueda recibir notificaciones duplicadas.

¿Eso implica que no podemos hacer nada para cambiarlo?. La verdad es que tenemos dos opciones, una de ellas es cambiar un parámetro del registro de Windows (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings) siguiendo las instrucciones que se detallan en este artículo: https://support.microsoft.com/kb/181050/es

Otra opción es la de crear un subproceso para que realice ese cambio usando la función InternetCloseHandle https://msdn.microsoft.com/en-us/library/windows/desktop/aa384350(v=vs.85).aspx . En este artículo se detalla cómo realizar ese cambio: https://support.microsoft.com/kb/224318

Espero que os sirva de ayuda

- José Ortega Gutiérrez