Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel enthält Informationen zur Problembehandlung bei Problemen, bei denen die Prozessorengine-Rolle beim Bereitstellen der Clouddienstanwendung in Azure im Beschäftigt-Zustand hängen bleibt.
Ursprüngliche Produktversion: API-Verwaltungsdienst
Ursprüngliche KB-Nummer: 4464894
Notiz
Im Artikel zur Azure Cloud Service Troubleshooting Series ist dies das vierte Szenario des Labors. Stellen Sie sicher, dass Sie die Laboreinrichtungsanweisungen für die Super Convertor-Anwendung wie folgt befolgt haben, um das Problem neu zu erstellen.
Symptome
Wenn Sie die Clouddienstanwendung in Azure bereitstellen, stellen Sie fest, dass die Prozessorengine-Rolle im Status "Beschäftigt " hängen bleibt und nie aus ihr kommt. Das Blatt Azure-Portal zeigt eine Meldung an:
Wird vorbereitet, um die Rolle zu starten... Das System initialisiert.
Problembehandlungsschritte
Wenn eine Rolle im Status "Beschäftigt " hängen bleibt, weist sie darauf hin, dass bei der Anwendung ein Fehler auftritt, der die Rolleninstanz nicht ausführt. Überprüfen Sie Ihren Anwendungscode, um festzustellen, ob das StatusCheck-Ereignis behandelt wird und gemäß dem Microsoft Azure Role ArchitectureWaHostBootstrapper-Prozess für Folgendes verantwortlich ist:
- Lesen Sie die Rollenkonfiguration, und starten Sie alle entsprechenden Aufgaben und Prozesse, um die Rolle zu konfigurieren und auszuführen.
- Überwachen Sie alle untergeordneten Prozesse.
- Auslösen des StatusCheck-Ereignisses für den Rollenhostprozess.
Der beste Ort, um die Problembehandlung zu starten, besteht darin, eine Remoteverbindung mit der Instanz mithilfe von RDP herzustellen und WaHostBootstrapper.log Datei zu prüfen, die unter dem Pfad C:\Resources
vorhanden ist. Beim Überprüfen des Ordners stellen Sie möglicherweise fest, dass nur eine Protokolldatei vorhanden ist, was bedeutet, dass WaHostBootstrapper nur einmal versucht hat, und es wird aufgrund eines Fehlers nicht wiederverwertt. Sehen Sie sich an, was in der WaHostBootstrapper.log Datei enthalten ist:
[00003604:00002604, 2018/08/13, 03:08:21.214, ERROR] <- WapXmlReadRoleModel=0x1 [00003604:00002604, 2018/08/13, 03:08:21.979, ERROR] <- WapXmlReadContainerId=0x1 [00003604:00002604, 2018/08/13, 03:08:22.026, ERROR] <- WapGetVirtualAccountName=0x1 [00003604:00002604, 2018/08/13, 03:08:22.026, ERROR] <- WapGetAppCmdPath=0x1 [00003604:00002604, 2018/08/13, 03:08:22.026, ERROR] <- WapSetDefaultEnvironment=0x1 [00003604:00002604, 2018/08/13, 03:08:22.014, ERROR] <- WapGetAppHostConfigPath=0x1 [00003604:00002604, 2018/08/13, 03:08:22.045, ERROR] <- GetDebugger=0x1 [00003604:00002604, 2018/08/13, 03:08:22.092, ERROR] <- GetStartupTaskDebugger=0x1 [00003604:00002604, 2018/08/13, 03:08:22.389, ERROR] <- WapGetEnvironmentVariable=0x800700cb **[00003604:00002604, 2018/08/13, 03:08:22.405, WARN ] Executing Startup Task type=0 rolemodule=(null) cmd="E:\approot\.\startup.cmd"[00003604:00002604, 2018/08/13, 03:08:22.405, WARN ] Executing "E:\approot\.\startup.cmd" .**
Aus dem obigen Protokoll sieht es so aus, als ob der Prozess beim Ausführen eines Startskripts mit dem Namen startup.cmd
"Present" im E:\approot
Verzeichnis hängen bleibt. Wenn Sie den Zeitstempel des letzten Eintrags (2018/08/13, 03:08:22.405) mit dem des aktuellen Systemzeitpunkts (2018/08/13, 04:16:13.132) vergleichen, wird möglicherweise angezeigt, dass der Host bootstrapper-Prozess versucht hat, das Startskript für mehr als eine Stunde auszuführen. Ein interessanter Punkt zu beachten ist, dass start task type=0, was bedeutet, dass es sich um eine einfache Startaufgabe handelt, die bewirkt, dass das System auf das Beenden der Aufgabe wartet, bevor die Ausführung fortgesetzt wird. Weitere Informationen zum Startaufgabentyp finden Sie unter diesem Link.
Das Microsoft Azure Bootstrapper-Ereignisanzeigeprotokoll zeigt die gleichen Informationen an:
Daher besteht der nächste Schritt darin, die Funktionalität dieses Startskripts zu überprüfen. das Skript führt eine ausführbare Datei "setup.exe" aus, die eine Befehlszeile "configuration.xml" verwendet. Die Ausgabe der Skriptverarbeitung wird in der Datei "StartupLog.txt" protokolliert, die unter dem RoleTemp-Verzeichnis erstellt wurde.
REM If WINWORD.EXE and EXCEL.EXE exists, then required office binaries are already installed.
IF "%ComputeEmulatorRunning%" == "true" (
GOTO Finish
)ELSE (
IF EXIST "D:\Program Files (x86)\Microsoft Office\root\Office16\WINWORD.EXE" (
ECHO Startup has already configured and installed required word processing binaries. Exiting. >> "%TEMP%\StartupLog.txt" 2>&1
GOTO Finish
)
IF EXIST "D:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE" (
ECHO Startup has already configured and installed required excel processing binaries. Exiting. >> "%TEMP%\StartupLog.txt" 2>&1
GOTO Finish
)
REM Run your real exe task
ECHO Running setup.exe >> "%TEMP%\StartupLog.txt" 2>&1
start /wait %~dp0setup.exe /configure %~dp0configuration.xml >> %TEMP%\StartupLog.txt 2>>&1
ECHO Creating Desktop directory >> "%TEMP%\StartupLog.txt" 2>&1
MKDIR "D:\Windows\System32\config\systemprofile\Desktop"
IF %ERRORLEVEL% EQU 0 (
REM The application installed without error.
ECHO The application installed without error. > "%RoleRoot%\Success.txt"
) ELSE (
REM An error occurred. Log the error and exit with the error code.
DATE /T >> "%TEMP%\StartupLog.txt" 2>&1
TIME /T >> "%TEMP%\StartupLog.txt" 2>&1
ECHO An error occurred running the setup. Errorlevel = %ERRORLEVEL%. >> "%TEMP%\StartupLog.txt" 2>&1
EXIT %ERRORLEVEL%
)
)
:Finish
REM Exit normally.
EXIT /B 0
Navigieren Sie zum Pfad C:\Resources\temp\{Deployment ID}.ProcessorEngine\RoleTemp
, und analysieren Sie die Protokolldatei "StartupLog.txt". Im Grunde sagt es - "**Running setup.exe", was bedeutet, dass das Skript die Ausführung von setup.exe noch nicht abgeschlossen hat. Beim Ausführen der ausführbaren Datei über die Eingabeaufforderung stellen Sie möglicherweise fest, dass "configuration.xml" nicht an einem E:\approot
Speicherort vorhanden ist und daher zu Einem Fehler beim Startvorgang führte. Das ist die Ursache des Problems.
In Visual Studio sollte die Eigenschaft "In Ausgabeverzeichnis kopieren" für die Startbatchdatei oder andere abhängige Dateien auf "Immer kopieren" festgelegt sein, um sicherzustellen, dass die Startbatchdatei in Azure ordnungsgemäß bereitgestellt wird (approot\bin für Webrollen und Approot für Arbeitsrollen). In diesem Fall wurde "In Ausgabeverzeichnis kopieren" jedoch auf "Nicht kopieren " für die Datei "configuration.xml" festgelegt.
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.