69 lines
2.8 KiB
Markdown
69 lines
2.8 KiB
Markdown
# Analyse: Update-Abbruch mit `Exitcode=0, Zeilen=8`
|
||
|
||
## Beobachtung
|
||
|
||
Der Installer meldete nach erfolgreicher Paketprüfung, Anmeldung und
|
||
Staging-Validierung:
|
||
|
||
```text
|
||
Installation/Update fehlgeschlagen. Rollback erfolgreich.
|
||
Ursache: Self-Test fehlgeschlagen. Exitcode=0, Zeilen=8.
|
||
```
|
||
|
||
Die Reihenfolge im Statusfenster zeigt, dass das neue Paket und das Staging
|
||
bereits erfolgreich neun Services geliefert hatten. Der danach ausgeführte
|
||
Self-Test gehörte zur noch installierten Ausgangsversion.
|
||
|
||
## Ursache
|
||
|
||
Version 2.2.4 verwendete dieselbe starre Erwartung von exakt neun Zeilen für
|
||
beide Seiten des Updatevergleichs. Eine ältere, intakte Installation vor
|
||
Einführung von `BizTalk Endpoint Reachability` liefert jedoch acht gültige
|
||
Checkmk-Zeilen und Exitcode 0. Der Updater deutete diese erwartete
|
||
Versionsdifferenz fälschlich als defekten Self-Test. Der Abbruch erfolgte vor
|
||
dem Stoppen des Tasks und vor dem Austausch von Dateien. Die Meldung
|
||
`Rollback erfolgreich` war deshalb technisch irreführend; es war keine
|
||
Systemänderung zurückzusetzen.
|
||
|
||
## Korrektur in Version 2.2.5
|
||
|
||
- Paket, Staging und aktivierte Zielversion müssen weiterhin exakt neun
|
||
eindeutige `OK`-Zeilen liefern.
|
||
- Die installierte Ausgangsversion darf eine andere positive Anzahl
|
||
eindeutiger `OK`-Zeilen liefern. Damit wird ihr tatsächlicher
|
||
versionsspezifischer Servicevertrag gelesen.
|
||
- Rein neu hinzukommende Services sind updatekompatibel. Sie werden als
|
||
Discovery-Hinweis gemeldet, blockieren aber die Umschaltung nicht.
|
||
- Entfernte Namen – und damit auch Renames – bleiben ohne aktivierte
|
||
Discovery-Bestätigung ein Sicherheitsstopp.
|
||
- Tritt ein Fehler vor der ersten Systemänderung auf, lautet der Status jetzt
|
||
`kein Rollback erforderlich`.
|
||
|
||
## Erweiterte Diagnose
|
||
|
||
Jeder Lauf erzeugt
|
||
`%ProgramData%\BizTalkCheckmkPulse\logs\setup-<UTC>-<PID>.log`. Das Log enthält:
|
||
|
||
- aktuelle Installationsphase und Setup-Version,
|
||
- Pfad, Dateiversion und Größe jeder geprüften EXE,
|
||
- erwartete und tatsächliche Zeilenzahl, Exitcode sowie vollständiges stdout
|
||
und stderr jedes Self-Tests,
|
||
- Task-Scheduler-State und `LastTaskResult` dezimal und hexadezimal,
|
||
- vollständige Exception-Kette mit HRESULT und Stacktrace,
|
||
- bei Runtime-Abnahmefehlern bis zu 40 letzte Provider-Logzeilen,
|
||
- Ergebnis jedes Rollback-Schritts.
|
||
|
||
Das Kennwort wird ausschließlich an `LogonUser` und die
|
||
Task-Scheduler-COM-Schnittstelle übergeben. Die Logging-Komponente erhält es
|
||
nicht.
|
||
|
||
## Regressionstests
|
||
|
||
Automatisiert geprüft werden insbesondere:
|
||
|
||
- acht gültige Zeilen einer Legacy-Ausgangsversion werden akzeptiert,
|
||
- acht Zeilen eines neuen Stagings werden weiterhin abgewiesen,
|
||
- eine reine Service-Erweiterung wird ohne Rename-Bestätigung akzeptiert,
|
||
- ein frisch beendeter Task mit Fehlercode wird sofort erkannt und der Code
|
||
enthält zusätzlich die hexadezimale Darstellung.
|