Does anyone know why Process Explorer might show these weird values for memory usage of my Virtual Box instance?

Here are the real numbers:


But here's what Process Explorer is showing:

alt text

alt text

So the process has committed 1.2 GB of VM, 1.1 GB of which is private. But Process Explorer is only seeing 196 MB of VM, and only 48 MB of private memory! What's going on here?

EDIT: This memory is not just reserved. It actually gets used:

alt text

  • As the chance is high that this is a bug, and these two tools are by Sysinternals... You might want to inform them with a similar description at their forum: forum.sysinternals.com Sep 6, 2010 at 17:09
  • Does it display correctly in Task Manager?
    – Connor W
    Sep 6, 2010 at 18:04
  • @Connor Task Manager shows the same numbers as Process Explorer.
    – RomanSt
    Sep 16, 2010 at 14:01

4 Answers 4


Mark Russinovich has kindly explained that this occurs because VirtualBox locks a large amount of memory, which requests the OS to keep it in the working set.

However, if you just try VirtualLocking a bunch of RAM, you won't see this. All that RAM will be happily accounted for, like it should be. So it's something else about the way VirtualBox allocates this memory. Incidentally, it also affects ProcessHacker.

The weird thing about this is that ProcessHacker enumerates all the allocated memory ranges correctly, and simply adding them up will give the correct value, however the counter reported by the OS is wrong. By a few GB. Not good!

I'm calling this a quirk of Windows RAM reporting. I'd call this a bug, but it's probably been around for at least a decade, so by now I guess one can call this expected behaviour... one that isn't properly worked around in Process Explorer nor Process Hacker.

  • I guess locking memory is for exceptional purposes only, together with the reason stated in that article is probably the reason why it never got counted... Nice that you figured it out that far, and yeah... Mark Russinovich is the man for such answers when the Sysinternals Forum can't help you out. :-) Sep 17, 2010 at 20:07
  • Is this reported differently between Windows 7 and Windows 8.1? On my W7 machine, VBox claims to have ~120MB WS and 250MB "Virtual Size", but in W8.1 it says clearly that the VBoxHeadless process has "Virtual Size" of 5.5GB.
    – analytik
    Nov 3, 2015 at 17:01
  • Well you have to deduce from the visible side effects. You can see the RAM usage increase on task manager and process explorer, but you can't see it on the information for the individual application, but you can on VMMap. I might look at VMMap and Task manager on IDA pro and see if I can get back to you on what's going on. But obviously the counters returned by NtQueryInformationProcess in the process object aren't being updated correctly Apr 30, 2020 at 14:28

Using SysInternals RamMap I think you can see the ram is recorded as 'DriverLocked'.

However I've no idea how you actually work back from this to the driver which locked it. And importantly, the driver is not going to be the VirtualBox program, but rather a driver that VirtualBox installed and uses.

If simply shutting down virtual machines doesn't free up ram from the 'DriverLocked' pool, then you can use a tool like AutoRuns to see what drivers are loaded at startup and disable them. It's a bit of a manual process so would be really interested if anyone knows how to tell what drivers have locked memory.


VMMap might have a bug that makes Committed include discarded pages or pages in the swap file.

Thus now it looks like inactive memory... It's allocated just as a reserve (or as a bug).

The Working Set only contains active memory, VMMap and Process Explorer do show the same WS...

  • It does indeed appear that VMMap has absolutely nothing anywhere to count reserved memory. I didn't notice that before. Ironic how Mark bashes Task Manager for using inconsistent terminology and then himself counting reserved memory together with committed memory...
    – RomanSt
    Sep 6, 2010 at 21:32
  • Yeah, the names should be made more consistent across products... Sep 7, 2010 at 1:14
  • OK, it's not this. When I start the VM, ProcessExplorer shows an overall increase in Commit by 1.1 GB or so, and the Physical usage also goes up by 1.1 GB. But not a single counter on the new process has those kinds of numbers.
    – RomanSt
    Sep 7, 2010 at 8:02
  • My guess is that the memory is allocated by a driver instead of the VM process. Another reason could be due to the hardware acceleration and nested paging options that VM software has, that causes Windows to be unable to see where that memory went... Sep 7, 2010 at 11:51
  • Turns out that this memory isn't counted because it is locked into the working set. That doesn't actually explain why it's not reported in the working set counter, but that's another question. Posted my own answer...
    – RomanSt
    Sep 17, 2010 at 18:47

From RAM, Virtual Memory, Pagefile and all that stuff :

Memory, Committed Bytes: This is a measure of the demand for virtual memory. It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (or both). As Committed Bytes grows above the available RAM, paging increases, and the amount of the pagefile in use also increases. At some point, paging activity starts to significantly affect perceived performance.

So I do believe that the Committed Bytes amount has nothing to do with VirtualBox - it's just the sum-total of physical RAM pages of all running processes in the system. In that case, the data returned by Process Explorer is correct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.