Wie zu debuggen: w3wp.exe Prozess wurde aufgrund eines Stack-Überlaufs beendet (funktioniert auf einem Computer, aber nicht auf einem anderen)

Das problem
Ich habe eine ASP.NET 4.0 Anwendung, stürzt mit einem stack-überlauf auf einem Rechner, aber nicht die andere. Es läuft wunderbar auf meiner Entwicklungsumgebung. Bei mir bewegen sich die Website auf den Produktions-server, es wirft einen stack-überlauf-Ausnahme (gesehen im Ereignis-log) und die w3wp.exe worker-Prozess stirbt und wird ersetzt mit einem anderen.

, Was ich bisher ausprobiert habe
Für den Verweis, habe ich das debug-Diagnose-tool, um zu versuchen, um zu bestimmen, was Stück code, das die Ursache für das überlaufen, aber ich bin nicht sicher, wie interpretieren Sie die Ausgabe. Die Ausgabe ist unten enthalten.

Wie könnte ein ASP.NET website verursachen einen stack-überlauf auf einem Rechner-aber nicht auf einem anderen?
Erfahrene führt geschätzt werden. Ich poste die Lösung unterhalb der Antwort, die mich führt.

Debug-Ausgabe

Anwendung: w3wp.exe Framework Version: v4.0.30319 Beschreibung: Der Prozess wurde abgebrochen wegen stack-überlauf.

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
Kommentar zu dem Problem
wohooo, hier sind wir wieder. 0xC00000FD, dude, dein problem ist genau hier: System_Web_ni+152ccd 06273aa8 05e9f214 06273aa8 Kommentarautor: Luke
Mögliche Duplikate von: stackoverflow.com/questions/5053440/... Und auch eine mögliche doppelte eines Benutzerkontos: stackoverflow.com/users/624716/kevin 🙂 Kommentarautor: Darin Dimitrov
Geschlossen als exaktes Duplikat einer Frage, die nicht mehr existiert?! Wtf! Kommentarautor: Egor Pavlikhin
Ich fragte für diese Frage geöffnet werden weil das original ist jetzt verschwunden. Dies ist nicht länger ein dupe. Ich habe einen sehr ähnlichen Fehler selbst auf .NET 4 mit der stack-overflow-exception aufgetreten, die auf einem web-server, aber nicht einem anderen, gleichen Baugruppen. Kommentarautor: John K
Anmerkung: die Existenz dieser Website macht die Suche nach Informationen über echte stack-overflows ziemlich lästig. Es dauerte eine Weile, um diese zu finden. Kommentarautor: Plynx

InformationsquelleAutor der Frage Kevin | 2011-02-19

  1. 35

    Diese Frage ist ein bisschen alt, aber ich fand gerade einen schönen Weg, den stack-trace, der meine Bewerbung kurz vor überlaufen und ich möchte es teilen mit anderen Google-Mitarbeiter, die es gibt:

    1. Wenn Ihr ASP.NET app stürzt ab, eine Reihe von debugging-Dateien ausgegeben werden, die in einem "crash-Ordner" in diesem Haupt-Ordner:

      C:\ProgramData\Microsoft\Windows\WER\ReportQueue

    2. Diese Dateien können analysiert werden, mit WinDbg, die Sie herunterladen können von den links unten:

    3. Nach der Installation in der gleichen Maschine, wo Sie Ihre app abgestürzt ist, klicken Sie File - > Open Crash Dump und wählen Sie die größte .tmp - Datei in Ihrem "crash-Ordner" (meine hatte 180 MB). So etwas wie:

      AppCrash_w3wp.exe_3d6ded0d29abf2144c567e08f6b23316ff3a7_cab_849897b9\WER688D.tmp

    4. Führen Sie dann die folgenden Befehle in den Befehl Fenster, das gerade geöffnet:

      .loadby sos clr
!clrstack

    5. Schließlich die erzeugte Ausgabe enthält Ihre app-stack-trace-kurz vor überlaufen, und man kann leicht die Spur, was die Ursache der überlauf. In meinem Fall war es eine buggy-Protokollierung Methode:

      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)

    Dank Paul White und seinem blog-post: Fehlgeschlagene Anwendung Debuggen w3wp.exe Stürzt ab

    InformationsquelleAutor der Antwort Thomas C. G. de Vilhena

  2. 5

    Einen Standard-stack-limit für w3wp.exe ist ein Witz. Ich immer erhöhen Sie mit editbin /stack:9000000 w3wp.exe sollte es ausreichen. Befreien Sie sich von Ihrem stack-überlauf zuerst, und dann Debuggen, was Sie wollen.

    InformationsquelleAutor der Antwort SK-logic

  3. 3

    Bekommen einen crash-dump, führen Sie es gegen Microsoft Debug Diagnostic Tool und zeige uns das Ergebnis.

    Werfen Sie auch einen Blick auf http://support.microsoft.com/kb/919789/en-us, die erklärt alle notwendigen Schritte im detail.

    InformationsquelleAutor der Antwort VVS

  4. 1

    Zwei Dinge, die ich versuchen würde, bevor die Analyse von Speicher-dumps.

    1. Installieren Sie die remote-debugging-tool auf dem web-server und versuchen das Debuggen so. Sie finden dieses tool auf der Visual Studio Installations-DVD.
    2. Installieren Elmah. Elmah können Hinzugefügt werden, um eine laufende ASP.NET Anwendung für die Protokollierung und debugging. Ich würde wahrscheinlich gehen mit dieser option ersten und es ist die am wenigsten schmerzhafte Ansatz. http://code.google.com/p/elmah/

    InformationsquelleAutor der Antwort Vince Panuccio

  5. 1

    Eine Möglichkeit für Ihre Anwendung Verhalten sich anders in der Produktion vs Entwicklung könnte Präprozessor-Direktiven wie #if DEBUG im code. Wenn Sie in der Produktionsumgebung bereitstellen der release-Version, verschiedene code-Segmente als Ihre debug-build.

    Andere Möglichkeit wäre, dass Ihre Anwendung wirft ein unbedeutender Ausnahme in der Produktion. Und die error-handling-code irgendwie endet das in einer unendlichen Funktion aufrufen Schleife. Möchten Sie vielleicht zu suchen für eine unendliche Schleife, die eine Funktion aufrufen, um sich selbst oder eine andere Funktion aufruft, diese Funktion zurück. Dies endet in einer endlos-Funktion callig-Schleife, da der unendlichen for-oder while-Schleife. Ich entschuldige mich für über Bord gehen mit dem Wort 'unendlich'.

    Ist es auch mir passiert ist, bevor, wenn ich versehentlich erstellt eine Eigenschaft und gab das Eigentum in meinem Eigentum. Wie:

    public string SomeProperty { get { return SomeProperty; } }

    Auch, wenn möglich, die Sie tun könnten spezielle Sachen, mit Ausnahme in der Application_error Funktion Ihres global.asax. Verwenden server.getlasterror() um die Ausnahme und log/- Anzeige der stack-trace. Möchten Sie vielleicht das gleiche tun für jeden innerexceptions oder innerexceptions innerexceptions und so weiter.

    Vielleicht sind Sie bereits dabei die oben genannten Dinge, aber ich wollte zu erwähnen, nur für den Fall.

    Auch, von Ihrer Spur wie es aussieht ist der Fehler passiert in GetSortKey. Ist, dass eine Funktion in deinem code? Wenn dem so ist, dann deinem unendlichen selbst aufrufen kann dort beginnen.

    Hoffe, das hilft.

    InformationsquelleAutor der Antwort Nabheet

Schreibe einen Kommentar