Run Preflight Checks and Resolve Warnings

Applies to: All editions

Purpose of preflight

DriveErase evaluates the selected device, bus, media classification, approach, and method before creating the destructive job. A preflight result can block an invalid combination or warn about an assurance limitation.

Blocking conditions

A blocked configuration must be corrected before the job can continue. Common examples include:

  • Firmware sanitization selected for USB-attached or removable flash media;
  • SATA/ATA SSD Secure Erase selected for a device not identified as a directly attached SATA SSD;
  • NVMe Format NVM selected for a device not identified as directly attached NVMe storage;
  • SCSI Sanitize Block Erase selected for a device not identified as a compatible directly attached SAS SSD;
  • Firmware sanitization selected for an HDD;
  • A method not permitted by the active edition;
  • A post-erasure health assessment selected under Standard;
  • The system disk selected or included indirectly.

Warnings

Warnings identify conditions that can reduce coverage or make a method unreliable. An important example is overwrite sanitization on flash-based USB or removable media. Host writes can process the exposed logical range, but controller-managed hidden, spare, retired, or remapped storage may remain outside that range.

A warning should not be dismissed merely because the application permits continuation. Record the risk decision and choose another method or disposition route when the warning conflicts with policy.

Firmware prerequisites

Even when preflight accepts a direct-attached firmware method, execution can still fail because:

  • The device does not support the required command;
  • The device is frozen, locked, or in an incompatible security state;
  • The controller or driver does not pass the command;
  • The device changes state between Windows and the Privileged Execution Environment;
  • An enclosure or HBA presents a different protocol path.

Firmware + Fallback can provide an alternate overwrite path when the firmware operation cannot complete, but the resulting assurance and compliance statement can differ from the intended firmware outcome.

Resolve before proceeding

For every block or warning:

  1. Reconfirm the physical device and interface.
  2. Review the selected approach and method.
  3. Use direct attachment where supported and operationally safe.
  4. Update approved controller drivers where required.
  5. Choose a supported overwrite method when firmware access is unavailable.
  6. Apply the organization’s destruction procedure when logical or firmware coverage is insufficient.