Windows 10 chkdsks Win7's(VBox Guest) partitions on each boot.

[V1rtualUser]

Not sure if this is the right place to write about this issue, so I won't have a problem is admins move it.

I do use VirtualBox on Ubuntu 14.04 host, and that is the reason I have chosen this subforum, although... The issue self probably has nothing to do with the Host OS.

My Windows 7 Guest uses physical/row disk access with small 64 GB SSD as its main, system disk ( C: ), another 320 GB physical/row partition as drive G:, and three common virtual partitions.
The problem I have is with the row disk and partition. Both are MBR/MSDOS, NTFS paritions. Each and every time I dual boot to Windows 10, which is on its separate disk, to play games, this windows installation starts 'repairing' at least one of just mentioned partitions.

Further, not only that Windows 10 always chkdsks these two partitions (at least one of them) on each boot, but Windows 7, the VirtualBox guest, will then do the same. It is like these two OSs have their favorite version of NTFS (or probably their versions of chkdsk.).
Each time Windows 10 'repairs' the partitions, Windows 7 (VirtualBox guest.) will do its best to 'unrepair' what Windows 10 has just done.

I was using the system like this for a while, thinking it is probably something trivial, what they turn on and off all the time, until I hadn't pressed the skip button, so Windows 7 skipped its file system check... This left the system (Win 7 guest) in an unusable state. Lot of files went missing, and running chkdsk afterwards didn't help at all.

I did a format and a clean Windows 7 install yesterday. Nothing changed.

Does anyone has a clue why something like this could happen?

[V1rtualUser]

Could someone please move this thread to appropriate subforum? I was obviously too tired, when I posted this under 'Linux Guests'. I thought I was using 'Linux Hosts' and I have chosen it because I am using VirualBox on top of Linux Host, although I am not sure if the issue has anything to do with the virtualisation at all... It could be that the issue has something to do with the way VirtualBox writes to disks in row/physical access mode...