Hello Michal. 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 there - 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 < [email protected]> 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 > point? > > Running with --dbg just shows the VM debugger UI, it does not change the > VM's behavior. > > - Michal > > ----- Original Message ----- > From: [email protected] > To: [email protected] > 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. > Thanks > c > > Il giorno mar 30 lug 2019 alle ore 10:11 Michal Necasek < > [email protected]> 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 >> memory. >> >> - 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 >> and >> > 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 >> > [email protected] >> > https://www.virtualbox.org/mailman/listinfo/vbox-dev >> >> _______________________________________________ >> vbox-dev mailing list >> [email protected] >> https://www.virtualbox.org/mailman/listinfo/vbox-dev >> >
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
