Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot

Started by WildByDesign

Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   04 November 2018, 00:29

Problem occurred since: RAMDisk 4.0.4 - exFAT support added
Conflicting program: Office 2010 (all Click-to-Run versions)
Specifically: Microsoft Application Virtualization Client (4.6.x)

When an exFAT disk is loaded through RAMDisk, any Office 2010 (C2R) program fails to load and crashes early. More specifically, it does not even begin to launch because the failing point of conflict is the underlying Application Virtualization Client (4.6.x) layer. This C2R is still used quite widely by many Office 2010 users, but does not affect MSI installed versions. So that would mostly be consumer versions of Office 2010.

Microsoft Application Virtualization Client (4.6.x) has a handful of kernel-mode drivers and therefore is quite deeply rooted into the system. This may be the source of the problem but it is difficult to determine. It ended up taking me several months to diagnose this issue because the C2R errors were not very detailed or descriptive. I did not even suspect RAMDisk until a month or so into the issue.

Now, I have narrowed it down even further:
exFAT disk mounted at boot: Failure (Office 2010 C2R fails to work)
exFAT disk mounted at logon: Success (all is well)

I had always used NTFS RAM disk loading at boot for several years, then switched over to exFAT loading at boot when RAMDisk 4.0.4 was released and that is when Office 2010 stopped working entirely. Now that I have figured out that loading the exFAT disk at logon does not cause the conflicts with Office 2010, that is a temporary workaround so that I can continue to use exFAT with RAMDisk and continue to use Office 2010.

This problem is very easy to reproduce consistently. However, I don't know if RAMDisk software is able to make code changes to avoid this conflict or not. It is very deeply rooted and difficult to get appropriate details of the crashes.

Thank you for your time.

Cheers,
Dave
SoftPerfect Support forum - Andrew avatar image

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   04 November 2018, 00:52

It sounds like Office 2010 C2R somehow doesn't like exFAT, possibly in combination with a standalone volume, which is created by default.

Please try ticking Hard Disk Emulation in your RAM Disk's properties and let me know if this helps. This setting emulates a complete hard disk drive with partitions indistinguishable from a real device.

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   04 November 2018, 04:35

Thank you for your reply, Andrew.

I created another RAM disk for the purpose of this testing right now. I did another exFAT disk with the Hard Disk Emulation checked as you suggested, followed by a reboot to test against Office 2010 C2R.

Unfortunately, even with Hard Disk Emulation, Office 2010 C2R still failed to launch any Office apps due to underlying App-V failure to initialize.
SoftPerfect Support forum - Andrew avatar image

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   04 November 2018, 12:09

That's odd, I guess then Office somehow doesn't like exFAT regardless of the volume type.

I am pretty sure RAM disk creates a valid exFAT volume structure, you can check that with chkdsk against the exFAT RAM disk.

I suppose you could use NTFS as an alternative, or stick to a logon-time exFAT disk.

Unfortunately there isn't much we can do here, since it is one of the MS drivers that fails. In the absence of its source code there is just no way of knowing what it tries to do and why it fails.
Microsoft isn't really caring about exFAT too much. There is a long time unresolved issue "Bug in renaming a file on exFAT" on Microsoft website.
If upper case renaming is part of your workflow you also have to use NTFS.

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   07 November 2018, 02:41

@Andrew, Thank you for your time and for your suggestions.

I had a feeling that this deep rooted bug was more to do with Office 2010 (underlying App-V) not properly supporting exFAT and therefore having some sort of low level kernel driver conflict.

I mainly use my RAMDisk for browser profile and cache and Thunderbird profile as well. So in my case, continuing to use "disk mounted on logon" is a perfectly fine solution that has been working well since I made the change. I don't necessarily need the disk to be mounted at boot time. So all is well now since logon mount works around the issue with Office 2010 C2R.

Regarding exFAT vs. NTFS:

In all of my perf testing so far, it seems that NTFS is slightly faster file system in my use case of browser cache files. I haven't been able to do a single test yet which showed exFAT being faster than NTFS. I know that SoftPerfect's own testing has shown exFAT being faster in comparison to NTFS, but those tests were large 4GB files being tested if I remember correctly. But for browser cache files being typically much smaller, NTFS has proved faster in my testing. FWIW, I have been using a relatively newer perf testing tool (https://ccsiobench.com/) which is quite nice.

ReFS:

Speaking of file systems, do you have any upcoming support for ReFS file system? Now that all Windows 10 versions support the file system and contain the relevant kernel drivers to support them, this would be great especially for testing purposes. I know that ReFS formatting is only supported on Enterprise level versions of Windows 10, but general ReFS file system support works on all. I tried to format a RAMDisk (via Hyper-V Enterprise machine) but unfortunately the formatting failed.

I have a paid licence to SoftPerfect RAMDisk and will continue to support the great development that your team does. One of the best software that I have ever purchased.

Cheers,
Dave
SoftPerfect Support forum - Andrew avatar image

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   07 November 2018, 12:22

Thank you for the feedback.

Unfortunately ReFS isn't currently on the list due to the extreme complexity of its data structures, which we have to create manually (system formatting routines are not available at the time RAM disk driver starts). At the same time there isn't a clear benefit of ReFS since NTFS serves well for almost any purpose.

Regarding exFAT vs NTFS performance, we've seen better numbers on exFAT rather than NTFS when using DiskMark. Please feel free to test in your environment and share your findings here.

That said, NTFS is an excellent system, and it's clearly stood the test of time.

Re: Office 2010 C2R crash: possible conflict with exFAT disk mounted at boot   08 November 2018, 01:59

Thank you so much again for responding and for all of the details.

I decided to run CrystalDiskMark as suggested. You are right, indeed, exFAT proved faster in comparison to NTFS in all categories. Even running the test with a smaller test size, exFAT came out on top. Very good. Further tests have continued to show exFAT being more efficient and faster so I am definitely thankful now that I made the switch to exFAT for my browser cache and Thunderbird profile. I'm not sure why that CCSIO Benchmark program shows different but I suppose the testing/benchmarking methodology is quite different between the two programs. I will stay with exFAT.

Thank you for the details regarding ReFS file system as well. It was more of a curiosity rather than a request. I figured that it was still quite new and not very much specifications to implement anyway at this stage.

Cheers,
Dave

Reply to this topic

Sometimes you can get the answer faster if you try the forum search and/or have a look at the software user manual to see if your question has already been answered.

Our forum rules are simple:

  • Be polite.
  • Do not spam.
  • If possible, check your spelling and grammar.

Author:

Email:

Subject

A brief and informative title for your message, approximately 4–8 words:

     

Spam prevention: please enter the following code in the input field below.

 **    **  **    **   ******    ********   **    ** 
 ***   **   **  **   **    **   **     **  **   **  
 ****  **    ****    **         **     **  **  **   
 ** ** **     **     **   ****  ********   *****    
 **  ****     **     **    **   **         **  **   
 **   ***     **     **    **   **         **   **  
 **    **     **      ******    **         **    ** 

Message: