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. Wir sind dem Fehler auf zwei DPM-Sicherungsservern nachgegangen und haben die Ursache eindeutig belegt. Hier ist die komplette Spur – vom irreführenden Symptom bis zum sauberen Beweis.

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

40002 gilt als Defekt mit WMI-Speichermangel als Hauptursache. Der Nachweis steht im Protokoll Microsoft-Windows-WMI-Activity/Operational, das jeder Anbieterfehler mit Ereignis-ID 5858 hinterlässt:

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. Klarer lässt sich eine Korrelation selten belegen.

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) sind für einen Sicherungsserver, der große Replikat-VHDs mountet, oft zu knapp:

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

Der Beweis: eine Kontrollgruppe frei Haus

Das Schöne an diesem Fall: Die Umgebung lieferte die Kontrollgruppe 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. Sauberer bekommt man eine Ursache selten belegt.

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

Der Bug selbst ist ein bekannter Microsoft-Defekt mit einer klaren Korrektur. Das eigentlich Gefährliche 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 behebt die Ursache – aber ob die Sicherung seitdem wirklich wieder Wiederherstellungspunkte erzeugt, verrät kein grüner Dienststatus, sondern allein das Alter des letzten sauberen Punkts. Diese eine Frage ist die Diagnose.

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