Can a separate process verify WHP partition deletion on Windows 11?

No supported WHP API lets a separate read-only process bind to the exact partition and later verify its deletion independently of the process that calls WHvDeletePartition.

WHvCreatePartition returns WHV_PARTITION_HANDLE, defined as VOID*, and specifies that all operations on the partition use that handle. It does not document a partition ID, name, reopen operation, cross-process transfer contract, or wait semantics for the handle.^1^

The supported deletion guarantee is therefore limited to the call contract: when WHvDeletePartition returns S_OK, the partition object has been removed and its resources released.^2^ If the caller and its result are lost, the public WHP surface does not provide another process with an authoritative post-deletion test for that same partition.

Why the apparent alternatives do not provide this

• Partition properties: WHvGetPartitionProperty requires an existing WHV_PARTITION_HANDLE and queries configuration values. It does not return a stable identity or document absence as a deletion probe.^3^
• Enumeration: The published WHP API surface documents creation, setup, property access, and deletion, but no operation that enumerates WHP partitions or opens one by identity.^4^
• Notification ports: Their Windows event objects are signaled by partition-generated guest events—either a matching guest physical-address write or HvCallSignalEvent. No partition-deletion notification is defined.^5^ Deleting a notification port merely stops that port from signaling its associated event; this is not a partition-lifetime event.^6^
• DuplicateHandle: Although that function can duplicate supported Win32 object handles, WHP defines WHV_PARTITION_HANDLE only as an opaque VOID* and does not document it as a duplicable or waitable Win32 handle. Generic handle-duplication semantics therefore cannot establish a supported cross-process WHP contract.^7^
• Migration: WHP explicitly identifies the migration handle as a standard Win32 handle that may be transferred to another process. That statement applies to MigrationHandle, not WHV_PARTITION_HANDLE, and migration creates/accepts a destination partition rather than providing a read-only deletion observer.^8^

Supported design

Make deletion acknowledgement part of the controller protocol:

1. The controller calls WHvDeletePartition.
2. It durably records or transmits the returned HRESULT.
3. Only S_OK is treated as authoritative completion.
4. The observer waits for that application-level acknowledgement, not for the WHP partition handle.
5. If the controller disappears before publishing the result, report the state as unknown, rather than “deleted.”

A supervisor may separately wait for the controller process to exit, but that proves only process termination. The available documentation does not define that observation as proof that a particular WHP partition completed teardown.

Consequently, there is no documentation defining the requested exact-partition identity and independent lifetime semantics on Windows 11 26H2 x64. Establishing such semantics would require an application-owned identifier and acknowledgement protocol; it cannot be reconstructed authoritatively from WHP after the controller and its deletion result are lost.

References

1. WHvCreatePartition | Microsoft Learn
2. WHvDeletePartition
3. WHvGetPartitionProperty
4. Windows Hypervisor Platform API Definitions
5. Notification Port Data Types
6. WHvDeleteNotificationPort
7. DuplicateHandle function (handleapi.h)
8. WHvStartPartitionMigration