WS v804 on Win7-64 host; can't connect CDROM

[Gork]

I'm running Workstation v8.0.4 on a Win7-64 host. Every vm I have, to include one I created just to test this issue, errors when trying to connect the CDROM during the boot process before control is handed over to the guest OS. I am notified that WS is unable to open the CDROM due to insufficient permission to access the file. I get the same results whether I use the physical CDROM on the host or a virutal CD rom also installed on the host. I don't think this error shows up if I attach an ISO, but I can't remember for sure and cannot test atm.

I want to say this started being a problem when I upgraded to v8.0.4 from v8.0.2, but I am not positive that is the cause for sure. I am positive this is only a relatively recent problem.

I have found that if I right click the executable on the host and "run as administrator" this problem goes away.

I've spent several hours Googling and "foruming" and can't find anything which explains this change in operation. I've never had to use "run as administrator" before to use a CD drive in Workstation. I have tried un/reinstalling the CD drive and it didn't change anything. I have also tried uninstalling WS and reinstalling it by using "run as administrator" on the install file. Still no luck. The user I am accessing WS with is an administrative user on the host system. I've checked file/folder permissions on old vms and compared them to newly created vms (created to troubleshoot this issue) and there is no difference.

Any idea why this is happening, and more importantly how to fix it? I'm concerned this could be a "bug" VMware introduced and now that they have moved to WS v9 it'll never be addressed. And I will be unable to upgrade to v9 for several months.

The pertinent part of the log file shows the following:

2012-08-24T03:18:54.941-06:00| vcpu-0| I120: CDROM: Using autodetect backend P: for ide0:1.
2012-08-24T03:18:54.941-06:00| vcpu-0| I120: CDROM: Connecting ide0:1 to 'P:'. img=0 raw=1 remote=0
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: AIOGNRC: Failed to open '\\.\P:' : Insufficient permission to access the file (700000003) (0x1).
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: SGWIN: Could not get device number for 'P:': Insufficient permission to access the file (700000003).
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: CDROM: Failed to process 'P:' : Insufficient permission to access the file (700000003)
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: CDROM: Failed to connect CDROM device 'P:'.
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: Msg_Post: Warning
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: [msg.cdromlib.couldntProcess] Unable to process CD-ROM device 'P:': Insufficient permission to access the file
2012-08-24T03:18:54.942-06:00| vcpu-0| I120+ Please ensure that your configuration is correct.
2012-08-24T03:18:54.942-06:00| vcpu-0| I120: [msg.device.startdisconnected] Virtual device ide0:1 will start disconnected.

[Gork]

Do I get to award myself points if I answer my own question?   I figured this out and am posting what happened in case it helps anyone else.  There are a LOT of similar issues out in Google-land but few definitive results.

I have three volumes in this computer, system (C:), programs (D:) and data (E:).  I perform the "manual" install with WS so I can install it on the programs volume instead of in the default location on the system volume.

HOWEVER, during this last upgrade instead of changing the locations of BOTH the WS install and the VMware VIX install I apparently only specified an alternate locaton for WS.  VMware VIX was installed to the default location on the system volume.

Uninstalling WS then reinstalling it, making sure to adjust the install location of VMware VIX to a subdirectory in the alternate location I installed WS to fixed the problem I was having.

Hope this makes sense - it seems hard to explain, probably since I'm on my way to bed after a graveyard shift...  It was sheer luck that I ran across a fix to my problem.

[Gork]

I've learned something new about this problem.  The solution I posted above didn't actually work and I've discovered this problem occurs when I boot a vm while connected to the host Win7-64 machine via Microsoft Remote Desktop.  If I boot the vm while sitting in front of the host computer the CDROM connects fine.  If I'm at work and connect to the host machine via RDP then start up WS and try to boot into any VM I get the error as described.

This had not always been an issue and I do not know when this started happening.  I don't regularly use WS while connected remotely to the host.

I have done my best to try to submit this information to VMware as a possible bug.

[continuum]

I see you allowed WS to use Autodetect for the CDrom.

That is not reliable - always specify the driveletter for the CDrom

[Gork]

Actually, same results either way - I should have indicated.  Thank you for your input.

EDIT:

Changed the message - I initially replied to the email notification from the board and thought it was a reply to the "ticket" I opened with VMware.  Oops!  Sorry...

[Gork]

As a follow-up I'm posting that I did hear back from VMware regarding my "bug report," but I was only told they couldn't reproduce the problem and I never heard back after replying to make and ask for some clarifications. This is basically what I expected would happen with my report, if I even heard back at all.  But then it's only been 10 days since I sent the reply...

Oh well, I did what I could I guess. 

FWIW I don't have the same problem with WS v7.1.5 which I run on a WinXP-32 host.

[Gork]

I'm still here, still dealing with this...

I have upgraded to WS v9 and verified this issues persists with this vesion.  However, I found a workaround this morning which I was unable to find before:  http://communities.vmware.com/message/2001656?tstart=660.  If you start VMware with the option to "Run as administrator" this problem doesn't occur.  This is required even if the host's logged-in user account is an adminstrator.

I have also been on the phone this morning with a representative from VMware who discovered the same workaround.  My support ticket was reopened with more information the representative this morning was able to glean after connecting to my computer remotely and having me conduct some more testing.  This issue is being forwarded to the engineering team for a permanent solution as well.

I also discovered that if I boot a vm directly from the host computer (without using "Run as administrator) to ensure the virtual CD-ROM device is connected normally THEN connect to the host computer via RDP the virtual CD-ROM device continues to work as normal.

I also learned that another similar ticket was opened by a different customer where the host OS was a different Windows version.

I think I reported above that my install of WS v7 doesn't exhibit this problem.  My guess as to the rason for this is because the host for my WS v7 install is WinXP which is pre UAC...

I'll do my best to remember to post back when the issue is resolved.

[nopking1]

This post just saved me roughly 60 miles of driving. All I needed to do was set up a virtual machine remotely, and with remote desktop I got the exact error you got.

Fortunately with remote desktop (after reading this,) I installed Chrome's remote, went in via that, bam. worked like a charm.

Windows 7 ultimate 64, all patches as of two weeks ago.

Workstation 8.0 or 8.1 I believe.

Thanks, and if you're ever in Nashville my company owes you a beer

[Gork]

Glad to hear this was helpful for you!  And I'm very happy there's a beer waiting for me in Nashville... 

My support ticket with VMware is still open and they've gotten back with me concerning a response from their engineering department.  They advised me of a setting in the windows group policy editor you change which will allow Workstation (and all applications) access to removeable devices when connected remotely through RDP without having to use "run as administrator" when executing WS.  I tested this setting in the GPE and it did work.

My reply was that I thought it was a security issue to allow access to all applications and that it is a somewhat complicated workaround to an issue which every user who connects remotely via RDP will run into.  WS should change this setting ONLY for itself even if it forced a UAC authorization when executed, at least in my opinion.

I assume they're still looking for other possible options as time allows.  Since there is a viable workaround for this it's probably no longer as close to the top of their list of things to do.