Page 1 of 1

[WorksForMe] Unable to Control Drive Assignments

Posted: 19. Jan 2019, 04:32
by Markm
The issue is solving the shifting drive letter assignments my XPVM is using/assigning.

Let me say here what I put in a separate post (mentioned near the end of this one): I think VBox is a wonderful application. Thank you to high heaven!! The downside is that I'm rather dependent on it. I've been thankful for socratis's past help & as I've researched recent presenting issues it appears you guys are perhaps taken for granted a bit. Kudos to you for your work (it's even voluntary, as I recall!).

Version of VirtualBox and installed the Guest Additions: 5.2.22 r126460 (Qt5.6.2) with installed Guest Addition matching version number.
Host & Guest make, version including 32 or 64 bit, and the amount of memory available to both.:
Host: ASUS i7-8750H @ 2.20GHz 2.21 GHz; 16.0(15.9 usable) GB; 64 bit x64-based processor, Win 10 Home; Workgroup: WORKGROUP
Guest: XP Home Service Pack 3, 32 bit, Base Memory 2048 MB, Video Memory 60 MB Screens: 2 [currently & usually run only 1 screen]

VM log, including Hardening logs:
2019 0118 174924 - Logs.zip
(72.21 KiB) Downloaded 7 times
My XPVM has two drive maps to the Host: E: drive & F: Drive;
  • E: is for the ASUS C: drive (a 256G SSD) &
    F: is for the Host ASUS D: drive; (most data is on the Host D: drive, a 1TB HD;)
    both the Host C & Host D drives are OEM with the Host ASUS laptop
Unfortunately the above-described mapping hasn't panned out. I'm still getting problems w/ access to the host D: (aka XPVM guest F: drive).

After many hours and 100+ tests, the best state I've gotten the XPVM machine in is this:

I can get the map of the Host D: to the Guest F: to work perfectly IF
  • I startup the XPVM from cold (rebooting the Host & then starting the guest) once,
    disable the guest USB CP1518ni printer connection,
    open the Guest F: drive with Windows Explorer, &
    then shut down the XPVM & restart it (I do not have to restart VBox, nor do I have to restart the Host system).
If I do all that, the XPVM will restart right into executing my StartUp.bat file (located on the guest F: drive) & all works swimmingly. Basically, whether my StartUp.bat runs automatically is usually an indication of whether or not the map from Host D: to Guest F: has worked.

So, how do I avoid having to start the XPVM twice? Or, put another way, how can I get it to work the FIRST time I start it up?

I do have a Clone of the best state I've been able to get the XPVM in, so I can upgrade if you think that's the solution, I'm just betting other problems will come in when I do that. I can upload logs for the Clone too, but it behaves like the VM for which I've uploaded the instant logs already. In the above uploads, I have disabled or removed the CD & may have disabled or nullified the Guest Additions & optical menu & or floppy menus, with no observable effect. The ASUS Host does not have any optical drive, just USB ports & other ports.

2019 0119 160506 UPDATE:
I just went ahead & installed ver 6.0.2 & also installed the guest additions to see what effect it would have. No positive effect, one negative, as follows:
  • 1. Following Host reboot, XPVM startup still results in no appropriate mapping of host D: to Guest F:.
    2. XPVM restart does result in appropriate mapping of host D: to Guest F: (as it did w/ ver. 5.2.22).
    3. XPVM restart results in the Windows XP closing tones being full of static and with skipping sound, similar to the jittery sound of a person speaking into a running fan (if you've ever hear that, it's a very odd sound).
    4. XPVM upon coming back up with the above-noted restart, produces all sounds in the same defective way - static sounding with the skipping wierd sound delivery as described, not only during the startup process, but when any application produces a sound.
With this new problem, I now have two problems instead of just one. Since the old problem (of drive assignments/drive mapping) was the pressing concern, it would seem that my best option would appear to be going back to ver 5.2.22. So far, I don't have a reason to expect that 6.0.2 will be able to better resolve the drive assignment/mapping issue, but it has added a new problem with sound.

So, while an XPVM restart allows the drive assignments/mapping to work properly, now the sound is constantly odd & possibly incomprehensible when playing back audio copies of human speech.

Any suggestions would be appreciated.

These are the most recent logs with the ver 6.0.2 with 6.0.2 guest additions:
Logs (log & hardening) - Mark'sWindowsXPOS-2019-01-19-15-59-54.zip
ver 6.0.2 & 6.0.2 guest addition VM Logs
(53.01 KiB) Downloaded 6 times
I'm going to move the sound problem to a New Topic, as it appears to be a distinct issue & I find no one else talking about it. Also, if I can successfully return to ver 5.2.22, I'll consider the sound problem low-priority & won't need to address it until/unless I re-upgrade to 6.0.2.

Re: Unable to Control Drive Assignments

Posted: 20. Jan 2019, 08:30
by Markm
SOLVED or WORK AROUND:

2019 0119 220644 Solution to Drive Assignment/Drive Mapping problem in XPVM:

I noticed in Windows Explorer that in My Computer the "d_drive on 'Vboxsvr' (F:)" was shown as "Disconnected Network Drive" unless the HPCP1518ni color printer's usb port was disconnected; Though it was nowhere explicit, the implication was that the guest OS was assigning the F: drive to the color printer, making it unavailable to other devices.

Therefore I ran Windows XP's disk management utility to assign the V drive letter to the color printer.

Thereafter, the "d_drive on 'Vboxsvr'" was assigned the F drive letter, and appeared in XP's Windows Explorer as "d_drive on 'Vboxsvr' (F:)" and, in the "Type" column, Windows Explorer showed it as a "Network Drive" instead of as "Disconnected Network Drive".

It now works as it should from a cold startup of the Host through the initial execution of the XPVM machine in VBox.

I'm not sure if the control of the drive assigments could have been managed by VBox or not. I suspect so, but for now I seem to have it solved because the XPVM appears to retain the drive letter assignment provided by the XP disk management utility for the color printer. By the way, the color printer has 4 memory slots & a USB stick port (although all are empty), so that may be why XP treats it as a drive; it may also have internal memory (though I don't know that to be the case).

Hallelujah!!

P.S. I never had this problem with VBox 5.2.22 on my previous system, but my previous Host system only had one internal hard drive, a 1TB C: disk drive, so there wasn't a doubling up of drive letter assignments like this new host, which has an internal OEM SSD C: drive and an internal OEM 1TB hard disk D: drive.

Re: Unable to Control Drive Assignments

Posted: 21. Jan 2019, 01:56
by socratis
Glad you got it going. I have to mark it as [WorksForMe] due to the nature of the problem and the solution...