Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

Here are the real numbers:

vmmap

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

share|improve this question
    
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 –  Tom Wijsman Sep 6 '10 at 17:09
    
Does it display correctly in Task Manager? –  Connor W Sep 6 '10 at 18:04
    
@Connor Task Manager shows the same numbers as Process Explorer. –  romkyns Sep 16 '10 at 14:01

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
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. :-) –  Tom Wijsman Sep 17 '10 at 20:07

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...

share|improve this answer
    
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... –  romkyns Sep 6 '10 at 21:32
    
Yeah, the names should be made more consistent across products... –  Tom Wijsman Sep 7 '10 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. –  romkyns Sep 7 '10 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... –  Tom Wijsman Sep 7 '10 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... –  romkyns Sep 17 '10 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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