| Previous | Next |
| WEP_E_NOT_PROVISIONED_ON_ALL_VOLUMES | WEP_E_HARDWARE_NOT_COMPLIANT |
WEP_E_FIXED_DATA_NOT_SUPPORTED
WEP_E_FIXED_DATA_NOT_SUPPORTED — 0x88010002
This code places the first failure in third-party provider support for fixed data volumes. Operationally, the installed encryption provider cannot protect one or more fixed data volumes that the compliance policy requires.
Where the failure sits
Windows Encryption Provider integration has separate gates for provider licensing, hardware readiness, volume support, provisioning, active protection, device-lock configuration, and EAS compliance. WEPHOSTSVC events should therefore be read alongside the third-party provider’s own inventory and logs, not as a replacement for them.
Do not collapse this result into a nearby status. This is not merely an unprovisioned supported volume; the provider reports that the volume class itself is unsupported. Compare lifecycle, identity, caller, and first API.
Facts to collect first
| Record | How it narrows the cause |
|---|---|
| Volume type, filesystem, partition style, bus, size, and provider capability report | Tests whether the first boundary moves. |
| Which volumes are OS versus fixed data and their current protection state | Pins evidence to one attempt. |
| Provider version/license and documented support matrix | Separates contract failure from environment. |
| EAS RequireEncryption evaluation and WEPHOSTSVC events | Creates a stable before/after control. |
The goal is reproducibility, not a full data dump. Prefer object IDs, configuration exports, event correlation, and redacted paths over credentials, cryptographic material, or user content.
Change one variable at a time
- Test a supported filesystem/volume type with the same provider; keep every other input fixed and record the first event that differs from the failing run.
- Compare OS-volume support with fixed-data-volume support; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Query provider capability before attempting provisioning; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
If the failure disappears after a broad restart, treat that as a clue about lifetime or state, not as proof of repair. Reproduce the original operation with targeted instrumentation before closing the incident.
What the result does not prove
Interpret the controlled tests as evidence about the returning boundary:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Verification after correction
The corrective action should be narrow: Upgrade/change the provider, change the storage layout to a supported design, or revise policy through the authorized authority. Preserve the pre-change configuration or trace.
Close the incident only when every in-scope fixed data volume is supported and encrypted, while an unsupported-volume control is reported before deployment. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
Use these sources for the formal contract, then combine them with evidence from the returning application or service for this condition:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: Exchange ActiveSync Policy Engine overview.
- Microsoft: Windows Encryption Provider Host Service.
- Microsoft: EasClientSecurityPolicy.RequireEncryption.
Looking for a different code? Search another status or error code.