Candidate Guest Reboot Comparisons

Candidate Guest-Reboot Comparisons

No source in this table is selected or live-proven. All comparisons require verified VM identity, protected baseline continuity, current-attempt status and encrypted authenticated readback, known boot-ID provenance, and an effective guard against snapshot or saved-state replay. The guest and host are trusted within the documented custody boundary; these observations do not attest a compromised guest or host.

Candidate	Potential contribution	Blocking uncertainties
QueryUnbiasedInterruptTime	A strictly lower current counter than a prior verified sample is a possible independent indication of a counter reset.	Reset without reboot, overflow, VM suspension/restore behavior, source access, and binding each sample to its actual boot must be excluded or proven. Equal or higher values are inconclusive, including after a real delayed reboot.
GetTickCount64	A strictly lower current uptime is another possible reset indication.	It has the same reset, replay, binding, and delayed-sampling concerns; its sleep behavior differs from the unbiased counter and needs target-guest proof.
Kernel-General event 12	A validated new OS-start event may supply an independent observation.	A strict bookmark alone does not establish complete log continuity, current-boot correlation, or protection against replay. Cleared, rotated, incomplete, or ambiguous logs are unknown.
LastBootUpTime	A restart date/time may aid diagnostics.	It is not documented as a unique or tamper-resistant boot ID; clock changes and replay prevent assuming a comparison is conclusive.

For the first counter candidate, Microsoft documents QueryUnbiasedInterruptTime as a 64-bit count in 100-nanosecond units that starts at system startup, advances on clock interrupts while working, excludes sleep and hibernation, and is unaffected by user or Windows time-service clock adjustments. Checked Windows builds have a documented approximately 49-day offset. These documented properties do not prove the target VM's reset, wrap, restore, or trust behavior.

A possible comparison stores a baseline sample only after verified current readiness. Obtain each baseline and current sample over the authenticated, encrypted channel, bracketed by reads of the same protected boot ID; both bracketing IDs must match the corresponding fresh witness boot ID. The baseline and current records must identify the same verified VM, and the current record must bind a newly armed attempt and serial boundary. The raw counter is independent of the registry UUID; the UUID only labels the boot being sampled. Counter-query errors, mismatched brackets, stale attempts, uncertain key lifetime, unproven replay exclusion, or a possible counter reset or wrap unrelated to reboot remain UNKNOWN.

Only if all those guards and the target-specific counter assumptions have been independently proven could a changed boot ID plus a strictly smaller unsigned counter support guest-only reboot corroboration. Equal or larger counts, including a real reboot followed by a sufficiently delayed sample, remain UNKNOWN; waiting longer does not establish a negative result. Store the protected samples as canonical unsigned 64-bit decimal strings to avoid lossy JSON-number conversion. A future versioned corroboration record must be validated and bound to bootEvidenceSha256; an arbitrary digest is not proof. Until that source and record are approved and validated, guest-only reboot and TEST-061 remain UNKNOWN, even when a local model's assumed guards produce a conditional match.