Von Avkash oben:

Ja. Das bedeutet, dass ein Problem in Ihrem Worker Role-Code zum Absturz Ihres Worker-Role-Host-Prozesses führt. Wenn Sie sich Ihren Fehler-Stack ansehen, müssen Sie die Funktion oder den Link aus Ihrem Code sehen, der diesen Fehler erzeugt. Wenn Sie Hilfe benötigen, öffnen Sie einen kostenlosen Azure Support-Vorfall für das Windows Azure-Supportteam, und diese werden Ihnen helfen.

Bei fehlender Referenz können Sie dieses Problem beheben durch:

Entpacken Sie Ihre CSPKG-Datei und entpacken Sie dann erneut die .CSSX-Datei (benennen Sie einfach CSSX in zip um) und passen Sie darauf, dass alle Referenzen und statischen Inhalte vorhanden sind. Auf diese Weise können Sie die VM-Inhalte abgleichen. Versuchen Sie auch in 2-Minuten-Fenstern, wenn Sie RDP suchen, nach Anwendungsereignisprotokoll für Ausnahme zu suchen und es zu erhalten, da das der Schlüssel zum Suchen der Ursache sein würde.

Wenn Sie die Ausnahme im Ereignisprotokoll sehen und nach der Ausnahme suchen, können Sie sicher herausfinden, wo sie generiert wurde. Sie können auch Intellitrace verwenden, für das Sie die App möglicherweise erneut bereitstellen müssen.

Es gibt auch Möglichkeiten, WinDBG zu kopieren und an den spezifischen Prozess zu binden, den Sie debuggen können. Ich bin mir nicht sicher, wie viel Sie versuchen möchten, aber kopieren Sie einfach die WinDBG auf VM und verwenden Sie es wäre genug (nicht sicher, wie viel Erfahrung Sie mit WinDBG haben und wie viel Zeit Sie verbringen möchten.)

Auch durch diese Rolle wurde Recyclingproblem mehrfach belästigt. Hier ist die Reihenfolge der Schritte zum Debuggen der persistenten Rolle recycelt :

Debuggen von Azure Role Recycles

1. Aktivieren Sie den Remotezugriff auf Ihre Rolle - RDP-Anmeldung
2. Überprüfen Sie eventvwr.msc (Windows-Protokolle - & gt; -Anwendung, App & amp; Service Logs - & gt; Windows Azure)
3. Überprüfen Sie die Azure-Textdateiprotokolle sowohl in C:\logs als auch in c:\resources .
4. Überprüfen Sie die benutzerdefinierten Protokolle im Volume E: oder F: für jede benutzerdefinierte Rollenstartprotokollierung

5. Führen Sie AzureTools und an Startprozesse anhängen (Download WinDBG , verwenden Sie Utils- & gt; Attach Debugger, wählen Sie Prozess - WaWorkerHost / WaIISHost usw.), verwenden Sie G , um fortzufahren und die Debugger-Ausgabe für Baugruppen zu beobachten, die nicht geladen werden können.

   Installieren von Azure-Debugging-Tools über Powershell

     

   PS & gt; md c: \ Werkzeuge; Import-Modul-Bitübertragung; Start-BitsTransfer Ссылка c: \ tools \ AzureTools.exe; c: \ tools \ AzureTools.exe

Wenn alle oben genannten Elemente fehlschlagen - versuchen Sie, andere Tools in der Schatzkammer AzureTools zu verwenden - z. B. Fusionsprotokollierung usw., funktioniert dieser obige Ansatz!

WinDBG-Beispielausgabe - Fehler beim Auffinden der Assembly (WaIISHost)

Die wahrscheinlichste Ursache ist, dass Sie eine fehlende Baugruppe haben. Eine Taktik, um dies zu erfassen, besteht darin, jede Startverarbeitung in einen Master-try / catch zu packen, der den Fehler im Azure-Speicher protokolliert.

Wenn Sie Referenzen hinzugefügt haben, stellen Sie sicher, dass sie auf copylocal = true festgelegt sind und dass alle externen Assets, die in Ihrem Servicepaket enthalten waren, ebenfalls enthalten sind.

Nur ein Vorschlag: Überprüfen Sie auch die installierbare (wenn vorhanden) und andere Referenzen, die Sie verwenden, sind 64bit.Azure VMs haben 64-Bit-Betriebssystem. Sobald ich mit dieser Art von Problem aufgrund von 32/64 Bit-Problemen festgefahren war.

Verlassen Ihre Worker-Rollen ihre Arbeitsschleife? Ein lokales Recycling ist sehr schnell und Sie werden es vielleicht nicht bemerken, aber die Spin-up-Zeit in der Cloud kann lang sein.