Microsoft Office applications crashing when opening Shared files from the Mac - Fusion 3 + Windows 7 Pro

[mattsmithvm]

OK, So newly installed Fusion 3 + WIndows 7 Pro with Office 2007.

All my files are stored on the Mac, and I've got VMware shared folders on your mac switched on for the folder... All used to work fine in Windows XP + Fusion 2.

But now, PowerPoint has a critical error when opening a file through the shared folder, but the same file opens fine if it's say in the actual Windows area. Checked my XP VM - and it's doing it there too!

Is this a bug with Fusion 3 - any help guys?

Thanks,

Matt

[steve_goddard]

Hi Bill.

Sorry for making you feel like you are going around in circles here, but I need to replicate your environment that failed so we can prevent other users from running into this and improve the product.

I understand you are using Win XP SP 3 VM, which is 32 bit.

You can access everything directly from Windows through your drive letter "Y:\..." with MS Word etc.

When you had your failure situation, it was trying to open the shared document from the Finder application, which would cause the application to hang in the Windows XP VM.

You moved your shared documents folder on the Mac host, to be under your Documents folder and shared this, and then everything works including opening the docs from the Finder.

I think that is a fair summary of the situation. Is that correct?

So the last reply I am not sure I quite follow you, but what I am asking is before you moved the shared documents folder on the Mac to be under Documents, where did they previously reside?

E.g. using Finder "Macinstosh HD/Users/Steve/shared documents"

So in Fusion application "Virtual Machine" menu, "Settings..." menu, under System Settings click on "Sharing" will list all of your VMware shares under two lists:

top list Share Folders on your Mac

what was this list of settings under each of the following headings:

On Name Folder Permissions

Second list Mirrored Folders:

(I think you said this was empty i.e. all unchecked.)

For the above list, I am interested in what the Folder setting was and where that is located on your Mac host (when things were failing).

Thanks.

Steve

[steve_goddard]

Hi Peter,

I was afraid of that. So I think you don't have the upgrade issue.

Although it will not harm to try the uninstall and reinstall test.

However, when you get back and get time. We will need to try and find out what else is going on in your environment.

I have tested WinXP SP3 and office and Adobe heavily and so has our QA. So we must have something different about

your environment that is not replicated here.

I just tested your share with Office 2007 Windows 7 64 VM and Word, Excel, Publisher all work going through a network drive.

Anti-virus applications are always one possibility which is why I asked initially. If you have any interesting applications installed like this it is good to know.

They affect the file IO requests dramatically.

I have tested with McAfee, Alwil's Avast Home, Quick Heal, and Trend Micro on occasion. Also been trying an install of Grisoft AVG.

Thanks.

Steve

[Vasilios]

Your summary is correct.

On my Windows VM I have a SharedDocs folder under Local network located at
APP-E123\SharedDocs

This same location is mounted within the finder as a mounted volume under shared smb://APP-E123/

So when I'm looking at the finder's sidebar I see a mounted volume under the heading shared. When I open it I see my Windows SharedDocs folder. I can access, view and manipulate all files within this SharedDocs folder using Mac Apps.

When I right click on a .xls file I see the open with option to use Microsoft Excel (VM Windows XP 3.0). I select that option and on the dock I see the Excel Icon appear, then everything crashes.

I also tried adding within VM Shared Folders the SharedDocs Folder and that also caused everything to hang, but only when accessing Office Files. If I take any file out of that folder and drag it to my MAC desktop I can then right click and open it using either pages or the MS Office app pertaining to that file.

Hope that makes a little more sense.

Bill

[steve_goddard]

Hi Bill,

Ah ha! This makes infinitely more sense to me now.

You are doing things in the reverse direction of what I was expecting.

I mean you are exporting the VM's local files to the Mac using Microsoft's network file system.

(Assuming the name of the Windows XP SP 3 VM is APP-E123.)

What the rationale here is that you are hitting a design issue in how the VM communication works which we will now document.

(At one of the next major releases this will be fixed but for now we can work around this.)

The intention of the feature you are using: Finder right click open file with Application XXX in the Windows VM, is for files located not in the Windows VM itself.

They are expected to be located on the Mac host's local disk or can be a remote share but not back to the VM, where they are accessed directly by the Mac applications or using the right click open

with Windows VM application (such as Word etc) via VMware shares from the VM to the Mac host location.

This will also save you from having to set up SMB mounts on your Mac host to the Windows VMs.

This is so that you can keep all your personal data files on your Mac host's drive so that if you trash or add new VMs you can always get to your personal data easily.

With the setup you have you cannot share your personal data files so easily between VMs unless you have multiple VMs running concurrently.

You have hit a circular deadlock which the Mac SMB client should eventually time out and return but could be quite a long time.

I know this is a convoluted and somewhat terse explanation, but I hope it helps. I think if you move your shared files to your Mac hosts Documents folder then they will be easily shared and accessed

using the Fusion UI menu: VM Settings, System Settings: Sharing and add a share there to the Mac host or enable Mirrored Folders and check Documents entry.

Thanks.

Steve

[Vasilios]

Hi Steve

Thanks for all your help...makes perfect sense.

What you suggested is what I ended up doing last night and finally was able to share/access the files.

I"m new to the MAC world so I'm just learning my way around with VM, Stuffit etc.

Thanks again

Bill

[steve_goddard]

Hi Bill,

No problem at all, glad to get to the bottom of the issue so that going forward you will have a good experience using the product and features.

I have filed a bug, with the issue that you triggered, and if anything can be fixed in the short term to prevent the deadlock we will address it. At least this issue will be documented.

Ultimately, in the longer term the VMware communication channel will not have this limitation and as such would allow the setup you had to not deadlock or hang.

Thanks.

Steve

[PeterO2]

Hi Steve, to pick-up where we left off yesterday....

I see this as a problem with the way VMWare links to or maps files, not a problem with MS Office or any other application, or with any background processes such as virus scanners.

I have created a share to my OS X home folder called
vmware-host\Shared Folders\olesiuk. I can then open a folder called My Documents within that share, and create a shortcut to it. These links work perfectly, and I can see and browse their contents with Windows Explorer and open any of the files with any application including MSOffice and Acrobat.

The problem arises when I try to map the share to a drive letter. For example, I can cut and paste the above address (
vmware-host\Shared Folders\olesiuk\My Documents) and map it to the E: drive. The link works in the sense that I can see and browse all the files in that share (E:\Users\olesiuk\My Documents). However, if I try to open one of the files, the application (MSOffice, Acrobat, and probably others but haven't tried) always crashes. For instance, even though
vmware-host\Shared Folders\olesiuk\My Documents\example.pdf and E:\Users\olesiuk\My Documents\example.pdf point to the exact same file (I can see both and open their properties in Windows Explorer), the fomer link always works for opening the file while the latter always crashes the application when I try to open the file. Somehow, VMWare is treating these two links differently. For example, I can try opening the file with the E:\... link and it crashes. I can then open the same file with the
vmware-host... link and it works perfectly. However, if I then try to re-open the file with the E:\... link I get a message there was a serious error last time I tried to open the file. In other words, the "memory" associated with the applicaton crash is associated withe the E:\.. link but not the
vmware-host... link, even though they point to the same file.

Hope this makes some sense.

Cheers,

Peter O.

[steve_goddard]

Hi Peter,

Thanks for the detailed reply. This really repeats what I already know though, but you are correct in that the drive letter and direct UNC paths are treated differently.

However as I explained a few posts ago:

"Drive letter access should work but it does take a different path through the Windows system to the file system driver than that of UNC access ie directly using "
vmware-host\Shared Folders\..." paths.

The drive letter route uses a user mode DLL that we provide and resides in the C:\Windows\System32 directory and is called vmhgfs.dll.

For some upgrades this DLL never got upgraded correctly by our installer, thus drive letter access got broken. An uninstall of the VMware tools, reboot VM, install of the VMware Tools works around this."

So it is not VMware that makes this difference between the two paths it is the Windows system itself on how it handles the two paths. The drive letter is a symbolic link which resolves back to the vmhgfs (VMware Shared Folders) file system. However, this link is set up by the user mode DLL part of our file system (which handles all the drive letter access) which is why I asked you about the presence of the file in C:\Windows\SYSTEM32 and its file version. Both of which seem to be correct.

I use drive letters and UNC path access constantly in many Windows VMs all running different versions of Windows, so do our QA. So the scenario you have should have been well tested. I am testing right now the same set up you have (as far as the information you have given me) with drive letters mapped as per yours. I use Adobe and all the Office 2007 applications to access data files through my mapped drive letter and all works fine.

I ask about anti-virus file system filter products because they intercept many of the file system requests before the file system gets them. They will prevent some, reissue some with different parameters and let others pass through. The fact is that these products change the behavior of the file system activity significantly so that often bugs existing in our file system and their products can show up.

This is why I asked you for this information, and am doing so again now, if you have something installed please tell me. Otherwise, I have to assume that you don't.

We may have to verify a few settings of your system or even trace the file IO requests into a log if you would be willing to do that?

In fact, I think that will most likely be the simplest thing here.

I attached the filespy utility so extract this and go to the FileSpy4.1\Win32 directory and run FileSpy.exe

Under the Volumes menu select "attach to a device by name"

In the box enter "\Device\HGFS" (without quotes)

Rerun your test of opening a file through your drive letter.

Then go back to file spy (you should see stuff in the log window.

In the File menu option "save As"

and save the output into a log file and then upload it here.

After that you can exit the FileSpy utility. It is quite useful to watching all the file IO going on to a particular volume.

This will give me the file IO that is going on when you get the crash. Hopefully it will provide me some details about the issue at hand.

Thanks.

Steve

[PeterO2]

Steve, reinstalled VMWare Tools and disabled virus scanner (McAfee, but VirusScan Enterprise edition, not the one that comes with VMWare), but neither had any effect. Here are two logs, one opening the file with the direct UNC address (success), and one opening the same file with the drive letter that crashes the application (failure).

Hope this helps,

Peter O.

[steve_goddard]

Hi Peter,

Thanks for the logs I will take a look at them now.

From your updates, I didn't expect the issue to go away with the uninstall - reinstall that others had, but it at least ensures I know you are at a clean starting point.

(I.e. no upgrade involvement).

I test with the McAfee Enterprise version too in a couple of VMs as they have to have that version when added to our domains. I had not seen any issues with McAfee todate for

both versions. However, not all AV products behave as well, but thanks for that information.

I'll update you with what I find from the logs and if I need any other information or tests to run.

Thanks.

Steve

[littleonewink]

Hi Steve,

I'm not sure if further examples are helpful or not, but I seem to be experiencing the same issue as Peter. I'll try to give you the same information you requested earlier in this thread in case it's helpful. I'm very new to mac (first week!), so it's entirely possible I may have missed something really basic in getting things setup.

Software:

Mac OS 10.6.1 running Fusion 3.

Virtual machine is Win 7 x64 Professional.

I have shared folders turned on, but mirrored folders off. All my docs reside in mac, not the vm.

Anti-virus is Avira AntiVir Personal version 9.0.0.407.

Symptoms are:

1. When opening a Word 2007 (Ultimate) document from windows explorer via a mapped drive to the shared location, Word crashes. I've attached a "Failure" Filespy output (with Anti-virus on).

2. When opening the same document in windows explorer via the network location, it and Word open fine. I've attached a "Success" Filespy output for this one (with Anti-virus on).

3. When opening the same document from finder, the document and Word open fine.

Logically related to these symptoms is another one; when I open the word doc in windows explorer via the network location, then try to save it via the mapped location, Word crashes.

What I've tried:

Checked that I have version 8.0.15.0 of the vmhgfs.dll files at both C:\Windows\System32 and C:\Windows\SYSWOW64. I do (so I didn't uninstall / reinstall vmtools).

Tried the opening the files per methods above with the Anti-virus program turned off. No difference.

If this info is useful and you need anything more, I'm happy to help!

Cheers,

Nadia

Message was edited by: littleonewink

[steve_goddard]

Hi Nadia,

This is indeed extra helpful and confirms a general issue that we have not seen here.

I am going to download the logs you uploaded and take a look at the file IO requests.

I have to note, that looking at the logs from Peter, that I renamed a PDF file I had been testing with to be the same name as the one he was using and I have managed to get Adobe to crash.

So now I have at least a reproducible case to work with. Thanks Peter.

I will also try it the same scenario you used in to generate your log output too.

I will update again, as soon as I understand what the failure point is.

Thanks.

Steve

[steve_goddard]

Hi Peter,

I repeated the test with a PDF file that I renamed to be the same as yours that the logs showed and I indeed crash Adobe.

This is great so now I have a reproducible case to look at.

I will update again as soon as I understand the failure point.

Thanks.

Steve

[steve_goddard]

Hi Nadia,

I can also reproduce a Word crash with the same named file that you were using. So now I have two reproducible cases.

Thanks.

Steve

[littleonewink]

Hi Steve,

That's great news. Thanks for your help!

Nadia

[steve_goddard]

Hi Peter, Nadia,

I have been running some exploratory tests with the same paths and filenames that I gleaned from the logs you updated.

It comes down to this paths that are using drive letters have a length restriction, which for Windows should be 256 characters.

Which should be enough to accommodate your names (including full path) of files that you are both using. However, the bug is

that this length is being incorrectly handled somewhere down the chain (either in our client or server yet to be determined).

Firstly, this is a bad bug, and I will definitely fix this and thanks for reporting it.

Secondly, in the interim, a quick workaround, which works in my tests is to shorten the paths to your files in your drive mappings or just use the UNC name

format all the time. So in Peter's case, for a mapped a drive, in the Fusion UI:

1) Virtual Machine menu, Settings menu, System Settings: Sharing.

Instead of just having the "Mac HD" share, create an additional new share, Northern Fur Seals (residing on Mac HD/Users/olesiuk/My Documents/My Projects/Northern Fur Seals)

2) Then map your drive using Explorer or for example: in a Command Prompt: net use * '"
vmware-host\Shared Folders\Northern Fur Seals"

This allowed Adobe to work correctly using the drive letter access using explorer navigate to the folder under the drive mapping and double click on the "CSAS....pdf " file.

Same goes for Nadia, create an additional VMware Share in the UI in Step 1 above to one of the subfolders on the path for example: "nadia On My Mac/Learning and Development/UniSA Grad Cert in Sustainable Business/SP6 Risk and Uncertainty Analysis" folder.

In step 2 in a Command Prompt: net use * '"
vmware-host\Shared Folders\SP6 Risk and Uncertainty Analysis"

Then using Explorer navigate to the new drive and "03 Assessments\Group Project" and double click on the "Group Project -Energy .....doc" file.

Anyway, I know this sort means a little extra set up of additional VMware Sharing shares if you want to continue to use mapped drives. I apologize that this bug got through but

we will have it addressed. I hope that if you have to use mapped drives keep in mind Windows path length limitatiions (256 characters) even when we get this bug fixed.

If you really must have the longer names, then stick with the direct file name UNC format (e.g. "
vmware-host\Shared Folders\...") .

I hope this helps for now.

Thanks.

Steve

[steve_goddard]

Hi there,

So I found an issue is in our user mode DLL (the vmhgfs.dll) and one of the supported APIs that we added recently. I get a buffer overrun which I think is what

is causing the applications to crash. This makes perfect sense for these situations you are seeing.

I am going to try and get this fixed today, and if possible into the next release. I will update here what happens in this regard. That way, you may not have to wait

too long to obtain a fixed version.

Thanks.

Steve

[PeterO2]

Steve, I have pretty much already implemented the workarounds you mentioned in your earlier post, so the bug is not slowing me down.

I very much appreciate your prompt attention and help with this issue.

Cheers,

Peter O.

[steve_goddard]

Hi Peter, Nadia,

I have found the root cause and fixed it. The good news here is that it will also be included in the next Fusion point release, which won't be too far down the road.

So please upgrade the VMware tools when you see it's release and you should be able to continue as before.

Thanks.

Steve

[gotomyspace]

Hi Steve,

I am new to VM and i just installed it, and installed Win 7with no issues yet. However, i already have Office 2007 for Mac installed on this Mac before i bought VM. I do not like the office for Macs at all. I am planning on installing Office 2007 for Windows on my Mac with the collaborations of VM. Is this going to create any confusions at all? I have the Mac and Win 7 separated; not sharing files/ folders.

thanks,

B