Skip to content

add vmmem process lookup functionality + windows API abstraction#2613

Open
rawahars wants to merge 1 commit intomicrosoft:mainfrom
rawahars:LookupVMMEM
Open

add vmmem process lookup functionality + windows API abstraction#2613
rawahars wants to merge 1 commit intomicrosoft:mainfrom
rawahars:LookupVMMEM

Conversation

@rawahars
Copy link
Contributor

Summary

The original implementation used a brute-force approach to locate the Hyper-V memory management process (vmmem). It relied on enumerating every single Process ID (PID) on the system and attempting to open each one to query its image path. This meant the system was executing expensive OS-level calls and generating ignored access-denied errors hundreds of times for unrelated processes, just to check if the name matched "vmmem".

Reference-

func lookupVMMEM(ctx context.Context, vmID guid.GUID) (proc windows.Handle, err error) {

The new enhancement significantly optimizes this discovery process by using windows API CreateToolhelp32Snapshot, which captures process names upfront without opening the processes. Now, the code iterates through the snapshot and pre-filters by the executable name. It only executes the expensive OpenProcess and security token checks (LookupAccount) if the process is already confirmed to be named vmmem or vmmem.exe.

Furthermore, the updated code introduces an interface to wrap the Windows OS calls. This dependency injection allows the system calls to be easily mocked, making the function fully unit-testable without requiring a live Hyper-V virtual machine.

Testing

  • Manual testing - Created UVMs and then ran the new as well as old code to find the correct vmmem process and list process stats. Both matched.
Parsed VM GUID: 829acaaa-f1d0-54c1-9b3d-fb806386e4b9

Process memory counters from old code: &{Cb:80 PageFaultCount:26264 PeakWorkingSetSize:105283584 WorkingSetSize:105283584 QuotaPeakPagedPoolUsage:158240 QuotaPagedPoolUsage:158240 QuotaPeakNonPagedPoolUsage:408 QuotaNonPagedPoolUsage:408 PagefileUsage:1076068352 PeakPagefileUsage:1076068352 PrivateUsage:1076068352}

Process memory counters from new code: &{Cb:80 PageFaultCount:26264 PeakWorkingSetSize:105283584 WorkingSetSize:105283584 QuotaPeakPagedPoolUsage:158240 QuotaPagedPoolUsage:158240 QuotaPeakNonPagedPoolUsage:408 QuotaNonPagedPoolUsage:408 PagefileUsage:1076068352 PeakPagefileUsage:1076068352 PrivateUsage:1076068352}
  • Added unit tests which use the windows mocks and runs the scenarios.

Notes

  • Additional tests and scenarios will be added in future PRs.
  • We are presently keeping old code untouched. This code will only be used for new shims. When they are stable, we can switch legacy shim to this code path.

The original implementation used a brute-force approach to locate the Hyper-V memory management process. It relied on enumerating every single Process ID (PID) on the system and attempting to open each one to query its image path. This meant the system was executing expensive OS-level calls and generating ignored access-denied errors hundreds of times for unrelated processes, just to check if the name matched "vmmem".

Ref- https://github.com/microsoft/hcsshim/blob/178d662f94b76b24fda758dfc41a7d9e6a2ee614/internal/uvm/stats.go#L76

The new enhancement significantly optimizes this discovery process by using windows API `CreateToolhelp32Snapshot`, which captures process names upfront without opening the processes. Now, the code iterates through the snapshot and pre-filters by the executable name. It only executes the expensive `OpenProcess` and security token checks (`LookupAccount`) if the process is already confirmed to be named `vmmem` or `vmmem.exe`.

Furthermore, the updated code introduces an interface to wrap the Windows OS calls. This dependency injection allows the system calls to be easily mocked, making the function fully unit-testable without requiring a live Hyper-V virtual machine.

Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
@rawahars rawahars requested a review from a team as a code owner February 28, 2026 20:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant