[vbox-dev] Memory initialization
b38911 at gmail.com
Wed Jul 31 16:29:56 UTC 2019
yes, good point. I did some tests and I obtained some mixed results, but at
the end, the behavior looks like:
- if I stop the boot at firmware and I dump the memory, no artefacts are
- if I continue the boot, sometimes artefacts appears in memory. So it
looks like it's a kind of caching of the operating system at this point.
It is not the "fast boot" option, which I already checked, so it's probably
something else. I need to dig on this.
Anyway, thanks for your help.
Il giorno mer 31 lug 2019 alle ore 16:01 Michal Necasek <
michal.necasek at oracle.com> ha scritto:
> What does "shutdown the guest system/start again the guest system" mean?
> Shut down the VM and start it again? Or reboot the guest OS without
> terminating the VM?
> In either case, I'd recommend dumping the VM's memory right after the VM
> is reset (when it's executing firmware). Are the artifacts there at that
> Running with --dbg just shows the VM debugger UI, it does not change the
> VM's behavior.
> - Michal
> ----- Original Message -----
> From: b38911 at gmail.com
> To: michal.necasek at oracle.com
> Sent: Tuesday, July 30, 2019 11:13:05 AM GMT +01:00 Amsterdam / Berlin /
> Bern / Rome / Stockholm / Vienna
> Subject: Re: [vbox-dev] Memory initialization
> Hi Michal.
> Sure, I'll try to explain better what I mean:
> - start virtualbox and start a Windows 10 guest system (allocating let's
> say 4GB of RAM)
> - start a specific software in the guest, which, after its exits, leave
> some artefacts in RAM (like a specific portion of code in unallocated
> memory). So far, so good, nothing strange.
> - shutdown the guest system
> - start again the guest system
> - looking into the RAM (dumping it), I still see the same artefacts, even
> if I didn't ran the same software as before. Like if the allocated RAM
> (still 4GB) was not re-initialized to 0
> This make sense if the initial allocation does not set memory to 0 (or
> something else), since I'm not rebooting the host, so for sure these
> artefacts are still in the host memory.
> If you say that this is reset should be done, I'll try to re-run a set of
> tests, may be I'm missing something. Consider that I'm running the VM with
> --dbg option, not sure if this change something.
> Thanks and let me know if you need more details on this.
> Il giorno mar 30 lug 2019 alle ore 10:11 Michal Necasek <
> michal.necasek at oracle.com> ha scritto:
>> Can you provide a simple reproduction scenario? What does one have to
>> do to see this?
>> A VM reset should clear memory. A caveat is that a given guest OS may
>> not perform a full reset but only a soft reboot, which does not clear
>> - Michal
>> On 7/28/2019 10:15 PM, b38911 wrote:
>> > Hello all.
>> > I was suggested to post my question here.
>> > Here my doubt:
>> > I noticed this behavior, which is probably expected: dumping the RAM of
>> > a guest (with ".pgmphystofile" command) I saw that the memory is not
>> > initialized between virtual powercycle, like if there was a real
>> > powerdown. Sometimes, between restarts of the guest (with a shutdown
>> > then a restart), I find some memory artifacts belonging to processes
>> > that shouldn't be there.
>> > I assume this happens because I'm not restarting the host system, so
>> > probably the RAM is just remapped, but not initialized. This is a bit
>> > annoying in some case, especially if you are using the system for
>> > testing purposes.
>> > Is there a way to force the guest to initialize the allocated RAM to
>> > zero (or something else), in order to emulate a real powerdown-powerup?
>> > Thanks for your help.
>> > cips
>> > _______________________________________________
>> > vbox-dev mailing list
>> > vbox-dev at virtualbox.org
>> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vbox-dev