Loging in takes forever

[ONEEYEMAN]

Hi,
I'm running VirtualBox 6.1.48 on Windows 8.1

I made a Windows 10 VM and at that time everything was running fine.

Yesterday I tried to start the VM but t turns out I can't. Its either stuck on the screen after I gave the password for my user or (if I wait long enough) starts up and don't do anything.

Trying to Google I saw that there is an incompatibility between newer updates and older VB. However this is an older version that can run on Win 8.

Is there an easy way to find out what is wrong? How do I get a cause for it?

I can upload the logs from VB, just need to know where to obtain them and what to look for.

Thank you.

P.S.: If it matter - the VM disk is on the external USB hard drive.

[multiOS]

In my experience running a 'modern' VM OS such as Windows 10 from an external drive requires a minimum of a USB2/3 connection and an SSD (not HDD) to see decent performance - Current OS requirements really mean that anything less than USB3 and/or the use of an external HDD is highly likely to result in bottlenecks with the constant data throughput and prove to be far too slow for 'normal' use.

'We' can check the VM's system config by reviewing its VBox.log for the VM to see if there are any problems/reported issues: After the VM has been shut down, right-click on the VM selection in the VitualBox Manager window and select "Show in explorer - 'zip' a copy of the VBox.log file in the Logs Folder and upload the 'zipped file using the Attacments Tab on the message screen.

[ONEEYEMAN]

Hi,
Logs attached.

Thx.

[ONEEYEMAN]

Anything out of the ordinary?

Thank you.

[multiOS]

Sorry for the delay, been away from the forum for a few days.

I've checked logs provided and the root cause of the startup failure seems to be the following error message which is repeated continuously until the VM eventually flatlines:

00:07:31.229717 VDI: Out of range access (214031138816) in image E:\machines\Windows10test\Windows10test.vdi, image size 214031138816
00:07:31.356291 VD#0: Read (0 bytes left) returned rc=VERR_VD_READ_OUT_OF_RANGE
00:07:31.356423 AHCI#0P0: Read at offset 6223212544 (118784 bytes left) returned rc=VERR_VD_READ_OUT_OF_RANGE
00:07:31.357374 AHCI#0: Port 0 reset
00:07:31.358529 VD#0: Cancelling all active requests
00:07:31.358545 VD#0: Request{0x00000008a44c80}:
00:07:31.358548 Type=READ State=ACTIVE Id=0x2 SubmitTs=14203365 {129} Flags=0x2
00:07:31.358551 Offset=122892255232 Size=12288 Left=12288 BufSize=16384
00:07:31.358565 VD#0: Request{0x00000008a46740}:
00:07:31.358567 Type=READ State=ACTIVE Id=0x3 SubmitTs=14203376 {118} Flags=0x2
00:07:31.358570 Offset=110204556800 Size=512 Left=512 BufSize=4096
00:07:31.358604 VD#0: Request{0x00000008a38200}:
00:07:31.358606 Type=READ State=ACTIVE Id=0x4 SubmitTs=14203387 {107} Flags=0x2
00:07:31.358608 Offset=110125633536 Size=32768 Left=32768 BufSize=32768
00:07:31.358623 VD#0: Request{0x00000008a443c0}:
00:07:31.358625 Type=READ State=ACTIVE Id=0x5 SubmitTs=14203395 {99} Flags=0x2
00:07:31.358628 Offset=527544320 Size=4096 Left=4096 BufSize=4096
00:07:31.358641 VD#0: Request{0x00000008a44740}:
00:07:31.358643 Type=READ State=ACTIVE Id=0x6 SubmitTs=14203403 {91} Flags=0x2
00:07:31.358645 Offset=1674307584 Size=8192 Left=8192 BufSize=8192
00:07:31.373097 VD#0: Aborted read (0 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.373181 AHCI#0P0: Canceled read at offset 122892255232 (12288 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.381871 VD#0: Aborted read (0 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.381932 AHCI#0P0: Canceled read at offset 110204556800 (512 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.382768 VD#0: Aborted read (0 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.382861 AHCI#0P0: Canceled read at offset 110125633536 (32768 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.382952 VD#0: Aborted read (0 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.382978 AHCI#0P0: Canceled read at offset 527544320 (4096 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.401738 VD#0: Aborted read (0 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.401800 AHCI#0P0: Canceled read at offset 1674307584 (8192 bytes left) returned rc=VERR_PDM_MEDIAEX_IOREQ_CANCELED
00:07:31.411185 AHCI#0: Port 0 reset
00:07:31.412337 VD#0: Cancelling all active requests
00:07:31.929927 AHCI#0: Port 0 reset
00:07:31.931054 VD#0: Cancelling all active requests
00:07:32.449604 AHCI#0: Port 0 reset
00:07:32.450737 VD#0: Cancelling all active requests
00:07:32.972495 AHCI#0: Port 0 reset
00:07:32.973640 VD#0: Cancelling all active requests
00:07:33.494123 AHCI#0: Port 0 reset
00:07:33.495217 VD#0: Cancelling all active requests
00:07:34.019600 AHCI#0: Port 0 reset
00:07:34.020861 VD#0: Cancelling all active requests
00:07:34.538611 AHCI#0: Port 0 reset
00:07:34.539745 VD#0: Cancelling all active requests
00:07:35.053923 AHCI#0: Port 0 reset
00:07:35.055058 VD#0: Cancelling all active requests
00:07:35.574846 AHCI#0: Port 0 reset
00:07:35.575991 VD#0: Cancelling all active requests
00:07:36.094538 AHCI#0: Port 0 reset
00:07:36.095749 VD#0: Cancelling all active requests
00:07:36.622457 AHCI#0: Port 0 reset
00:07:36.623620 VD#0: Cancelling all active requests
00:07:37.132571 AHCI#0: Port 0 reset
00:07:37.133703 VD#0: Cancelling all active requests
00:07:37.690823 AHCI#0: Port 0 reset
00:07:37.691956 VD#0: Cancelling all active requests
00:07:38.178356 VDI: Out of range access (214031138816) in image E:\machines\Windows10test\Windows10test.vdi, image size 214031138816
00:07:38.200069 VD#0: Read (0 bytes left) returned rc=VERR_VD_READ_OUT_OF_RANGE
00:07:38.200138 AHCI#0P0: Read at offset 6223212544 (118784 bytes left) returned rc=VERR_VD_READ_OUT_OF_RANGE

I have searched the forum for previous mentions of similar problems, but it appears to be a rare issue with no known solution as, according to this thread: viewtopic.php?t=97387 (from 2020) the most likely cause is some corruption in the VDI File resulting in the startup being unable to locate required data at the specified address. If that is the case, then the only likely form of recovery I can suggest is to try restoring the last working VM Backup.

On the broader performance issues my previous assumptions appear correct, in that the host system is likely struggle to support a Windows 10 VM in running anything but the simplest tasks, especially as, apart from the factors already mentioned, Windows 10 really needs 2 CPUs to be allocated to perform efficiently (Microsoft minimum installation requirements for Windows 10). But, as the Host is only powered by a dual-core CPU that is not really feasible without introducing potential issues for the Host system.

[ONEEYEMAN]

Thank you.