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

Question

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

Gurjinder Singh Gill 0

On Windows 11 26H2 x64 (build 26300.9711), can a separate read-only process verify that a specific Windows Hypervisor Platform (WHP) partition has been deleted after the controller is lost, without relying on the stop caller receiving the WHvDeletePartition return?

The WHvDeletePartition documentation describes what success means for the caller. I am looking for a supported API, event, or wait that an independent process can bind to the exact partition before teardown. If such a mechanism exists, what documentation defines its partition identity and lifetime semantics?

0 comments

2 answers

Your answer

Answer 1

Hi @Gurjinder Singh Gill ,
After reviewing your questions and the available Microsoft documents, here are my answers:

The public WHP documentation does not define a supported mechanism for a separate read-only process to bind to an exact partition before teardown and independently verify its deletion after the controller is lost. The published Windows Hypervisor Platform API Definitions provide no partition enumeration, open-by-identity operation, or partition-deletion event/wait contract.

The relevant contracts are:

Identity and access: WHvCreatePartition returns WHV_PARTITION_HANDLE, defined as VOID*, through which all partition operations are performed. It does not define a stable external partition identity, cross-process transfer contract, or waitable lifetime semantics. The generic DuplicateHandle documentation does not establish those semantics for WHP partition handles.
Deletion: WHvDeletePartition documents that successful completion (S_OK) removes the partition object and releases its resources. It does not provide an independent observer notification or post-deletion verification API.
Properties and notifications: WHvGetPartitionProperty requires a partition handle and queries a property, not deletion completion. Notification Port Data Types define signals for guest hypercalls or matching guest-memory writes, not partition deletion. WHvDeleteNotificationPort says deletion stops further signaling, not that it signals teardown completion.

Therefore, if the deletion caller and its result are lost, these documented contracts do not give another process authoritative proof that the same partition was deleted. This is a documentation-based conclusion, not a claim about undocumented implementation behavior on build 26300.9711.

I hope this helps answering your questions. If you find my response helpful, I would greatly appreciate it if you could follow the guide here so others experiencing similar behavior or issue can benefit from it as well.

Answer 2

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:

The controller calls WHvDeletePartition.
It durably records or transmits the returned HRESULT.
Only S_OK is treated as authoritative completion.
The observer waits for that application-level acknowledgement, not for the WHP partition handle.
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