visual studio servidor mucha error consume aplicación asp.net debugging stack-overflow
Instalador Windows WinDbg x64Instalador Windows WinDbg x86

asp.net - studio - w3wp.exe windows server 2003



Cómo depurar: el proceso de w3wp.exe finalizó debido a un desbordamiento de pila(funciona en una máquina pero no en otra) (5)

Dos cosas que probaría antes de analizar cualquier vuelco de memoria.

  1. Instale la herramienta de depuración remota en el servidor web y pruebe la depuración de esa manera. Puede encontrar esta herramienta en el DVD de instalación de Visual Studio.
  2. Instala Elmah. Elmah se puede agregar a una aplicación ASP.NET en ejecución para el registro y la depuración. Probablemente vaya con esta opción primero y es el enfoque menos doloroso. http://code.google.com/p/elmah/

El problema
Tengo una aplicación ASP.NET 4.0 que se bloquea con un desbordamiento de pila en una computadora, pero no en otra. Funciona bien en mi entorno de desarrollo. Cuando muevo el sitio al servidor de producción, arroja una excepción de desbordamiento de pila (que se ve en el registro de eventos) y el proceso de trabajo w3wp.exe muere y se reemplaza por otro.

Lo que he intentado hasta ahora
Como referencia, utilicé la herramienta de diagnóstico de depuración para tratar de determinar qué parte del código está causando el desbordamiento, pero no estoy seguro de cómo interpretar el resultado. La salida se incluye a continuación.

¿Cómo podría un sitio web ASP.NET causar un desbordamiento de pila en una máquina pero no en otra?
Los clientes experimentados son apreciados. Publicaré la solución resultante debajo de la respuesta que me lleva a ella.

Salida de depuración

Aplicación: w3wp.exe Framework Version: v4.0.30319 Descripción: El proceso finalizó debido al desbordamiento de la pila.

In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/nlssorting.dll from Microsoft Corporation has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16 Please follow up with the vendor Microsoft Corporation for C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/nlssorting.dll Information:DebugDiag determined that this dump file (w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the IISAnalysis.asp script (located in the DebugDiag/Scripts folder) and set the g_DoCombinedAnalysis constant to True. Entry point clr!ThreadpoolMgr::intermediateThreadProc Create time 2/18/2011 9:07:10 PM Function Arg 1 Arg 2 Arg 3 Source nlssorting!SortGetSortKey+25 01115a98 00000001 0651a88c clr!SortVersioning::SortDllGetSortKey+3b 01115a98 08000001 0651a88c clr!COMNlsInfo::InternalGetGlobalizedHashCode+f0 01115a98 05e90268 0651a88c mscorlib_ni+2becff 08000001 0000000f 0651a884 mscorlib_ni+255c10 00000001 09ed57bc 01d14348 mscorlib_ni+255bc4 79b29e90 01d14350 79b39ab0 mscorlib_ni+2a9eb8 01d14364 79b39a53 000dbb78 mscorlib_ni+2b9ab0 000dbb78 09ed57bc 01ff39f4 mscorlib_ni+2b9a53 01d14398 01d1439c 00000011 mscorlib_ni+2b9948 0651a884 01d143ec 7a97bf5d System_ni+15bd65 6785b114 00000000 09ed5748 System_ni+15bf5d 1c5ab292 1b3c01dc 05ebc494 System_Web_ni+6fb165 ***These lines below are repeated many times in the log, so I just posted one block of them 1c5a928c 00000000 0627e880 000192ba 1c5a9dce 00000000 0627e7c4 00000000 1c5a93ce 1b3c01dc 05ebc494 1b3c01dc 1c5a92e2 .....(repeated sequence from above) System_Web_ni+16779c 1b338528 00000003 0629b7a0 System_Web_ni+1677fb 00000000 00000017 0629ac3c System_Web_ni+167843 00000000 00000003 0629ab78 System_Web_ni+167843 00000000 00000005 0629963c System_Web_ni+167843 00000000 00000001 0627e290 System_Web_ni+167843 00000000 0627e290 1a813508 System_Web_ni+167843 01d4f21c 79141c49 79141c5c System_Web_ni+1651c0 00000001 0627e290 00000000 System_Web_ni+16478d 00000001 01ea7730 01ea76dc System_Web_ni+1646af 0627e290 01d4f4c0 672c43f2 System_Web_ni+164646 00000000 06273aa8 0627e290 System_Web_ni+1643f2 672d1b65 06273aa8 00000000 1c5a41b5 00000000 01d4f520 06273aa8 System_Web_ni+18610c 01d4f55c 0df2a42c 06273f14 System_Web_ni+19c0fe 01d4fa08 0df2a42c 06273e5c System_Web_ni+152ccd 06273aa8 05e9f214 06273aa8 System_Web_ni+19a8e2 05e973b4 062736cc 01d4f65c System_Web_ni+19a62d 06a21c6c 79145d80 01d4f7fc System_Web_ni+199c2d 00000002 672695e8 00000000 System_Web_ni+7b65cc 01d4fa28 00000002 01c52c0c clr!COMToCLRDispatchHelper+28 679165b0 672695e8 09ee2038 clr!BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>::~BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>+fa 672695e8 09ee2038 00000001 clr!COMToCLRWorkerBody+b4 000dbb78 01d4f9f8 1a78ffe0 clr!COMToCLRWorkerDebuggerWrapper+34 000dbb78 01d4f9f8 1a78ffe0 clr!COMToCLRWorker+614 000dbb78 01d4f9f8 06a21c6c 1dda1aa 00000001 01b6c7a8 00000000 webengine4!HttpCompletion::ProcessRequestInManagedCode+1cd 01b6c7a8 69f1aa72 01d4fd6c webengine4!HttpCompletion::ProcessCompletion+4a 01b6c7a8 00000000 00000000 webengine4!CorThreadPoolWorkitemCallback+1c 01b6c7a8 0636a718 0000ffff clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+195 01d4fe1f 01d4fe1e 0636a488 clr!ThreadpoolMgr::NewWorkerThreadStart+20b 00000000 0636a430 00000000 clr!ThreadpoolMgr::WorkerThreadStart+3d1 00000000 00000000 00000000 clr!ThreadpoolMgr::intermediateThreadProc+4b 000c3470 00000000 00000000 kernel32!BaseThreadStart+34 792b0b2b 000c3470 00000000 NLSSORTING!SORTGETSORTKEY+25In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/nlssorting.dll from Microsoft Corporation has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16

Esta pregunta es un poco vieja, pero acabo de encontrar una buena manera de obtener el rastro de pila de mi aplicación justo antes de desbordar y me gustaría compartirla con otros usuarios de Google:

  1. Cuando su aplicación ASP.NET falla, se descarga un conjunto de archivos de depuración en una "carpeta bloqueada" dentro de esta carpeta principal:

    C: / ProgramData / Microsoft / Windows / WER / ReportQueue

  2. Estos archivos se pueden analizar utilizando WinDbg, que puede descargar desde uno de los enlaces a continuación:

  3. Después de instalarlo en la misma máquina donde se bloqueó su aplicación, haga clic en Archivo> Abrir volcado de volcado y seleccione el archivo .tmp más grande en su "carpeta bloqueada" (el mío tenía 180 MB). Algo como:

    AppCrash_w3wp.exe_3d6ded0d29abf2144c567e08f6b23316ff3a7_cab_849897b9 / WER688D.tmp

  4. Luego, ejecute los siguientes comandos en la ventana de comandos que acaba de abrir:

    .loadby sos clr !clrstack

  5. Finalmente, la salida generada contendrá la traza de su pila de aplicaciones justo antes del desbordamiento, y puede rastrear fácilmente qué causó el desbordamiento. En mi caso, fue un método de registro erróneo:

    000000dea63aed30 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aedd0 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aee70 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aef10 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception) 000000dea63aefb0 000007fd88de9d00 Library.Logging.RepositoryLogger.Error(System.Object, System.Exception) 000000dea63af040 000007fd88de9ba0 Library.WebServices.ErrorLogger.ProvideFault(System.Exception, System.ServiceModel.Channels.MessageVersion, System.ServiceModel.Channels.Message ByRef)

Gracias a Paul White y su publicación en el blog: Aplicación de fallas de depuración w3wp.exe se bloquea

Un límite de pila predeterminado para w3wp.exe es una broma. Siempre lo editbin /stack:9000000 w3wp.exe con editbin /stack:9000000 w3wp.exe , debería ser suficiente. Primero deshazte de tu desbordamiento de pila y luego depura lo que quieras.

Una posibilidad para que su aplicación se comporte de forma diferente en producción vs desarrollo podría ser directivas de preprocesador como #if DEBUG en el código. Cuando implemente en producción, la versión de lanzamiento tendrá diferentes segmentos de código que su compilación de depuración.

Otra opción sería que su aplicación arroje una excepción no relacionada en producción. Y el código de manejo de errores de alguna manera termina en un ciclo infinito de llamadas a funciones. Es posible que desee buscar un bucle infinito que tenga una llamada de función a sí mismo u otra función que invoque esta función. Esto termina en un ciclo callig de función infinita debido al ciclo infinito for o while. Me disculpo por exagerar con la palabra "infinito".

También me sucedió antes cuando accidentalmente creé una propiedad y devolví la propiedad dentro de mi propiedad. Me gusta:

public string SomeProperty { get { return SomeProperty; } }

Además, si es posible, podría hacer cosas especiales con la excepción en la función Application_error de su global.asax. Use server.getlasterror() para obtener la excepción y registrar / mostrar el seguimiento de la pila. Es posible que desee hacer lo mismo para cualquier innerexception o innerexception de innerexception etc.

Es posible que ya esté haciendo las cosas mencionadas anteriormente, pero quería mencionarlas por si acaso.

Además, desde su seguimiento, parece que el error está ocurriendo en GetSortKey . ¿Es eso una función en tu código? Si es así, entonces su auto llamada infinita puede comenzar allí.

Espero que esto ayude.