[My Robotic Friend wrote this summary for me in case you can't tell...]
Title: WHV_UINT128 / [WHV_REGISTER_VALUE](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html) missing 16-byte alignment (DECLSPEC_ALIGN(16) dropped) → WHP register calls fault
Crate: [windows-sys](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html) 0.61.2 (also present in [windows](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html)), Win32::System::Hypervisor
Summary
WHV_UINT128 is declared DECLSPEC_ALIGN(16) in the SDK, and WHV_REGISTER_VALUE (a union whose largest member is WHV_UINT128 Reg128) is therefore 16-byte aligned with sizeof == 16. The generated Rust type has size_of == 16 but align_of == 8 — the alignment is lost. This is the same class of bug as #2641 / #1744 / #4404 and win32metadata#1044.
SDK evidence (10.0.26100.0\um\WinHvPlatformDefs.h):
Minimal repro (no hypervisor needed):
Real-world impact
WHvGet/SetVirtualProcessorRegisters marshal register values with aligned 128-bit moves. Passing an 8-aligned WHV_REGISTER_VALUE array (e.g. a stack local used to inject an exception via WHvRegisterPendingEvent) faults inside WHP with STATUS_ACCESS_VIOLATION at winhvplatform!WHvApi::Hypercall::SetVpRegisters whenever the buffer lands on an 8-but-not-16 address. It's layout-dependent, so it reproduces intermittently and is easy to misdiagnose. Callers must currently force alignment with a #[repr(C, align(16))] newtype as a workaround.
Fix: emit #[repr(align(16))] for WHV_UINT128 (root cause per win32metadata#1044); WHV_REGISTER_VALUE inherits it.
[My Robotic Friend wrote this summary for me in case you can't tell...]
Title:
WHV_UINT128 / [WHV_REGISTER_VALUE](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html)missing 16-byte alignment (DECLSPEC_ALIGN(16) dropped) → WHP register calls faultCrate:
[windows-sys](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html)0.61.2 (also present in[windows](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/125df4672b/resources/app/out/vs/code/electron-browser/workbench/workbench.html)), Win32::System::HypervisorSummary
WHV_UINT128 is declared DECLSPEC_ALIGN(16) in the SDK, and WHV_REGISTER_VALUE (a union whose largest member is WHV_UINT128 Reg128) is therefore 16-byte aligned with sizeof == 16. The generated Rust type has size_of == 16 but align_of == 8 — the alignment is lost. This is the same class of bug as #2641 / #1744 / #4404 and win32metadata#1044.
SDK evidence (10.0.26100.0\um\WinHvPlatformDefs.h):
Minimal repro (no hypervisor needed):
Real-world impact
WHvGet/SetVirtualProcessorRegisters marshal register values with aligned 128-bit moves. Passing an 8-aligned WHV_REGISTER_VALUE array (e.g. a stack local used to inject an exception via WHvRegisterPendingEvent) faults inside WHP with STATUS_ACCESS_VIOLATION at winhvplatform!WHvApi::Hypercall::SetVpRegisters whenever the buffer lands on an 8-but-not-16 address. It's layout-dependent, so it reproduces intermittently and is easy to misdiagnose. Callers must currently force alignment with a #[repr(C, align(16))] newtype as a workaround.
Fix: emit #[repr(align(16))] for WHV_UINT128 (root cause per win32metadata#1044); WHV_REGISTER_VALUE inherits it.