Ein Sicherungsauftrag, der nach acht Sekunden mit 0 MB übertragener Daten und einer bloßen Warnung endet, sieht auf den ersten Blick harmlos aus. Genau das macht Fehler 40002 in Microsoft System Center Data Protection Manager (DPM) so tückisch: Er tarnt sich als Warnung, die Überwachung bleibt grün – und trotzdem entsteht kein gültiger Wiederherstellungspunkt. Das eigentlich Wichtige daran: Eine Datensicherung kann überwacht werden, ohne dass sie funktioniert. Die Dienste laufen, die Aufträge laufen, die Überwachung ist grün, und trotzdem entsteht kein Wiederherstellungspunkt. Wir sind dem Fehler auf zwei DPM-Sicherungsservern nachgegangen. Hier ist die Spur, vom irreführenden Symptom bis zu der Ursache, die in unserem Fall dahintersteckte.

Das Symptom

In der DPM-Konsole erscheint:

The VHD containing the replica or one of it's snapshots could not be mounted or unmounted. (ID 40002)

Die Konsistenzprüfung bricht nach sechs bis acht Sekunden mit 0 MB und Status Warning ab. Das Replikat bleibt inkonsistent, und der anschließende Versuch, einen Wiederherstellungspunkt zu erzeugen, scheitert mit dem Folgefehler 31209 – Cannot perform Recovery point creation on a replica which is inconsistent.

Der entscheidende Gedanke steht schon hier: Ein Auftrag, der in acht Sekunden mit null übertragenen Bytes endet, hat nicht gearbeitet – er ist gestolpert. Und weil DPM das nur als Warning führt und nicht als kritischen Fehler, rutscht es durch jede Überwachung, die auf Zustände schaut statt auf Aktualität. Genau das ist die Klasse Fehler, die man aktiv jagen muss, statt auf einen Alarm zu warten.

Warum die Meldung in die Irre führt

„VHD konnte nicht gemountet werden" klingt nach einem Speicher- oder Dateisystemproblem am Replikat. Tatsächlich liegt die Ursache eine Ebene tiefer. DPM mountet die Replikat-VHD nicht selbst, sondern spricht dafür über WMI mit dem Speicheranbieter des Betriebssystems. Läuft dieser Anbieterprozess in ein Speicherkontingent, liefert er einen Fehler zurück – und DPM übersetzt das in „VHD kann nicht gemountet werden". Technisch korrekt, diagnostisch wertlos.

flowchart LR
  DPM["DPM-Auftrag<br/><i>Replikat mounten</i>"] -->|"WMI-Aufruf"| P
  subgraph WMI["WMI im Betriebssystem"]
    P["Speicheranbieter<br/><i>Storage-Namensraum</i>"] -->|"Kontingent erschöpft"| E["WBEM_E_OUT_OF_MEMORY<br/>0x80041006"]
  end
  E -->|"DPM meldet"| M["Fehler 40002<br/><i>VHD nicht gemountet</i>"]
  style E stroke:#cc171a,stroke-width:2.5px

Die Spur: das WMI-Aktivitätsprotokoll

Fehler 40002 kann verschiedene Ursachen haben. In unserem Fall führte die Spur zu einem erschöpften WMI-Speicherkontingent. Hinweise darauf finden sich im Protokoll Microsoft-Windows-WMI-Activity/Operational, in dem Anbieterfehler mit der Ereignis-ID 5858 landen:

Get-WinEvent -LogName 'Microsoft-Windows-WMI-Activity/Operational' |
    Where-Object { $_.Id -eq 5858 } |
    ForEach-Object {
        if ($_.Message -match 'ResultCode\s*=\s*(0x[0-9A-Fa-f]+)') { $Matches[1] }
    } | Group-Object | Sort-Object Count -Descending

Das Ergebnis war eindeutig: eine große Zahl von Ereignissen mit dem Ergebniscode 0x80041006 – WBEM_E_OUT_OF_MEMORY –, sämtlich im Namensraum Root\Microsoft\Windows\Storage. Eines davon fiel exakt eine Sekunde, bevor der scheiternde Sicherungsauftrag endete. Entscheidend war dieser zeitliche Zusammenhang zwischen Fehler 40002 und dem WMI-Ergebniscode 0x80041006.

Die Korrektur – mit einer Stolperfalle

Der wichtigste Merksatz zu diesem Fehler zuerst: Der Engpass ist kein Mangel an physischem RAM. Beide Server hatten 128 GB Arbeitsspeicher – man hätte die Hardware beliebig aufrüsten können, ohne das Geringste zu ändern. WBEM_E_OUT_OF_MEMORY meint nicht den Speicher der Maschine, sondern ein künstliches Kontingent, das WMI jedem Anbieterprozess einzeln zuteilt (MemoryPerHost). Der richtige Hebel ist deshalb eine höhere Grenze für genau diesen Prozess – nicht mehr Hardware. Die Vorgabewerte (512 MB pro Anbieter, 1 GB gesamt) können für einen Sicherungsserver, der große Replikat-VHDs mountet, zu knapp sein.

Bevor Sie etwas ändern: Lesen Sie die aktuellen Werte aus und notieren Sie sie, damit Sie zurückkehren können. Planen Sie die Änderung in einem Wartungsfenster, denn sie wird erst mit einem Neustart wirksam (siehe unten).

# aktuelle Werte sichern
$q = [wmi]"root:__ProviderHostQuotaConfiguration=@"
$q | Select-Object MemoryPerHost, MemoryAllHosts

Die Erhöhung, wie wir sie vorgenommen haben:

$q = [wmi]"root:__ProviderHostQuotaConfiguration=@"
$q.MemoryPerHost  = 1073741824     # 1 GB (Vorgabe 512 MB)
$q.MemoryAllHosts = 4294967296     # 4 GB (Vorgabe 1 GB)
$q.Put()

Und hier die Stolperfalle, die uns am meisten Zeit gekostet hat: Die Änderung greift erst nach einem Neustart des Servers. Der Wert steht sofort in der Registrierung, aber der WMI-Dienst Winmgmt liest das Kontingent nur beim Dienststart ein. Ein Test unmittelbar danach scheiterte weiter – und selbst ein Neustart allein des Anbieterprozesses reichte nicht. Erst der Neustart der gesamten Maschine machte die Erhöhung wirksam.

Ein starkes Indiz: der Vergleich zweier Server

Die Umgebung lieferte einen Vergleich gleich mit. Zwei Sicherungsserver, beide mit demselben Fehler, beide mit demselben erhöhten Kontingent – aber nur einer bekam sofort einen Neustart.

Server A wurde neu gestartet. Eine Datenquelle mit halbstündigem Prüfzyklus zeigt den Umschwung präzise:

vor dem Neustart   ~20x  Failed   (über neun Stunden)
────────────────── Neustart ──────────────────
nach dem Neustart  8x     Succeeded (in Folge)

Server B bekam dasselbe Kontingent gesetzt, zunächst aber keinen Neustart. Dort scheiterte dieselbe Art Datenquelle unbeirrt weiter – Stunde um Stunde – bis zu seinem eigenen, späteren Neustart. Ab da: sauber.

Gleicher Fehler, gleiches Kontingent, eine Maschine neu gestartet, die andere nicht, und nur die neu gestartete lief durch. Das ist ein starkes Indiz, aber kein Laborbeweis: Ein Neustart setzt auch andere Zustände zurück, und die beiden Server unterscheiden sich in Last und Zeitpunkt. Zusammen mit dem zeitlichen Zusammenhang im WMI-Protokoll ist das Kontingent für uns die plausibelste Erklärung.

Wenn das Kontingent nicht reicht: die zweite Stellschraube

Reicht mehr Speicher nicht, gibt es einen zweiten Hebel – dem Anbieter Arbeit wegnehmen, statt ihm Speicher zu geben. DPM parallelisiert das Mounten und Aushängen; dieser Grad lässt sich senken:

HKLM\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Configuration\ParallelMountDismountSettings
    ParallelMountDismountOperationLimit = 3      (Vorgabe 5)

Danach Restart-Service MSDPM. Wir haben diesen Hebel nicht gebraucht – und bewusst nicht gleichzeitig mit dem Kontingent gedreht. Zwei Änderungen auf einmal, und man weiß hinterher nicht, welche gewirkt hat.

Die eigentliche Lehre

Das eigentlich Gefährliche an diesem Fall ist nicht das Kontingent, sondern die Tarnung: ein Auftrag, der als harmlose Warnung mit 0 MB endet, sieht in einer zustandsbasierten Überwachung genauso grün aus wie ein erfolgreicher Lauf. Der Dienst läuft, der Auftrag „läuft" – nur entsteht kein Wiederherstellungspunkt.

Unsere Konsequenz ist eine Überwachung, die nicht fragt „läuft der Dienst?", sondern die einzige Frage stellt, die im Ernstfall zählt: Wie alt ist der jüngste gültige Wiederherstellungspunkt dieser Datenquelle? Das Kontingent zu vergrößern hat in unserem Fall die Ursache behoben. Ob die Sicherung seitdem wirklich wieder Wiederherstellungspunkte erzeugt, verrät aber kein grüner Dienststatus, sondern das Alter des letzten sauberen Punkts. Und ob sich aus diesem Punkt tatsächlich etwas zurückholen lässt, zeigt nur eine echte Wiederherstellungsprobe. Machen Sie die nach jeder solchen Änderung.

Als Microsoft-Partner betreuen wir genau solche Windows- und Hyper-V-Umgebungen bis in diese Tiefe. Wenn Sie sichergehen wollen, dass Ihre Sicherung nicht nur läuft, sondern auch Wiederherstellungspunkte erzeugt, unterstützen wir bei der Serverbetreuung mit überwachter Datensicherung und unseren IT-Services – oder sprechen Sie uns direkt an.

Quellen: Microsoft Learn – __ProviderHostQuotaConfiguration (WMI-Kontingent, Neustart-Hinweis) · Microsoft – Memory and Handle Quotas in the WMI Provider Service