# 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.