locked
Inserting a UserForm causes access violation in FM20.dll RRS feed

  • Question

  • We have an application with VBA embedded in it. This application has worked for the last 16 years with many versions of Office.

    On some (but not all) systems this application now crashes with an access violation in FM20.dll when a UserForm is inserted into the VBA project. It also crashes opening a previously-built VBA project if that project contains a UserForm.

    The crash has been observed using VBA 6.4 and VBA 7.1, and on both Windows 7 and Windows 10.

    The common factor seems to be Office 365. Only on machines with this version of Office does the problem occur. But confusingly not all systems with Office 365 show the problem. Two independent sites with completely different IT setups are now seeing this problem on some but not all systems.

    Even more confusingly it is sometimes possible to get insertion of a UserForm to work just once. This can be achieved either by a fresh install, or by adding and then logging in as a new user. After the one successful insertion of a UserForm and restarting the application, the new installation, or the new user, always experience a crash when inserting a UserForm.

    There are two versions of FM20.dll on each system: In c:\windows\SysWOW64 we have V15.0.3628.1000 and in C:\Program Files (x86)\Microsoft Office\Root\VFS\SystemX86 we have V16.0.8431.2046

    On a system that does not show this problem enumerating all loaded DLL's shows that both versions of FM20 are loaded into the applications address space! Because of the crash we can't do the same on a system that does show the problem. An internet search reveals many similar reports of access violation in FM20 when inserting a UserForm in various versions of Office, but no suggested solutions in any of these reports has been successful. In particular, repairing or reinstalling Office 365 and/or the application does not fix the problem. Using WinDBG confirms the exception but without symbols or source for FM20 we've been unable to diagnose the crash further.

    Thursday, October 5, 2017 8:56 AM

Answers

  • A complete fix for this particular problem suggested by Fernando Menegel (see page 2 of https://answers.microsoft.com/en-us/msoffice/forum/msoffice_other-mso_win10/office-2016-crashed-when-userform-added-to-vba/f2f16ffa-9a1f-4bfd-babb-1e93a78d5c65?auth=1) is to delete <filename>.BOX where <filename> is the program experiencing the problem. This fix has been verified on several systems at two different sites and deleting the file seems completely benign.

    The .BOX files are found variously in C:\Users\<user>\AppData\Roaming\Microsoft\Forms and C:\Users\<user>\ Application Data\Microsoft\Forms. A VBA enabled application (e.g. Excel) will recreate Excel.BOX each time it is run, so it needs deleting before every invocation.

    This explains why the exception did not occur when the application is executed for the very first time, because the BOX file didn't exist.

    So the details of the access violation in FM20.dll above are a bit of a red herring. In particular it seems that by design both versions of FM20 should be registered and both are loaded into the programs address space - this for a 32 bit VBA-enabled application running on 64 bit Windows 7 or 10 with Office 365 installed.

    Anyone got any idea what these .BOX files are for?

    • Marked as answer by pde14 Monday, October 9, 2017 9:30 AM
    Monday, October 9, 2017 9:30 AM

All replies

  • I can't answer your question, just some thoughts as -

    It looks like you've either got multiple Office versions installed, or at some stage have had an older verson not fully uninstalled. Also it seems different 32/64 bit versions. That's based on the V15 & V16 versions of FM20.dll you apparently have installed on the same systems. If one merely exists 'uninstalled' it's harmless, but you say you have both running at the same time, not sure how that can occur but it doesn't sound right!

    Apart from that not a good idea to have multiple Office versions with 365, and probably not even possible with mixed MSI and C2R installs.

    One thing you might do first, not because it's the most likely to work but the simplest and least likely to cause new problems, is find and delete all *.exd files, particularly any MSForms

    Next, entirely at your own risk and on a system you can afford to be without, uninstall the older if not both FM20 versions, then 'Repair' Office.

    https://support.microsoft.com/en-us/help/249873/how-to-use-the-regsvr32-tool-and-troubleshoot-regsvr32-error-messages

    Note different versions of Regsvr32 exist in the respective system folders in Win-64. Run from an elevated command prompt, and include the /u switch to uninstall. This is only a guess!

    Thursday, October 5, 2017 8:50 PM
  • Thanks for suggestions, they are much appreciated.

    I can't vouch for all systems but some definitely have never had Office installed prior to Office 365.

    Deleting all *.exd files does not fix the problem. Neither does repairing Office.

    I agree having 2 x FM20 loaded by one application doesn't sound right - but that's on a system that doesn't show the problem! The two versions of FM20.dll are (a) installed by the OS in Windows\SysWOW64 and (b) part of the Office 365 installation in C:\Program Files (x86)\Microsoft Office\Root\VFS\SystemX86. Both type libraries are registered:

    HKEY_CLASSES_ROOT\TypeLib\{0D452EE1-E08F-101A-852E-02608C4D0BB4}
    C:\Program Files (x86)\Microsoft Office\Root\VFS\SystemX86\FM20.DLL

    HKEY_CLASSES_ROOT\TypeLib\{AC2DE821-36A2-11CF-8053-00AA006009FA}
    C:\Windows\SysWOW64\FM20.DLL\2

    Unregistering the latter (older) version and inserting a UserForm leads to the error "Class not registered. Looking for object with CLSID AC9F2F90-E877-11CE-9F68-00AA00574A4F".

    Unregistering the former (newer) version and inserting a UserForm leads to the error "Class not registered. Looking for object with CLSID C62A69F0-16DC-11CE-9E98-00AA00574A4F".

    With both registered we see an access violation. So also do other people using Excel 365 as recently as last month - see page 2 of https://answers.microsoft.com/en-us/msoffice/forum/msoffice_other-mso_win10/office-2016-crashed-when-userform-added-to-vba/f2f16ffa-9a1f-4bfd-babb-1e93a78d5c65?auth=1

    If possible could you or anyone reading this who has access to a Windows 7 or 10 64 bit system with Office 365 installed check (a) are there two versions of FM20.dll in the above locations (b) using REGEDIT check whether both type libraries are registered. Thanks.

    Friday, October 6, 2017 9:45 AM
  • I wasn't optimistic about the exd but worth ruling out.

    I don't have 365 to hand so can't be sure, but concerning the first two CLSIDs you cited -

    {0D452EE1-E08F-101A-852E-02608C4D0BB4} is the GUID for the MSForms reference in both 32 and 64 bit files.

    {AC2DE821-36A2-11CF-8053-00AA006009FA} is for the Wow6432Node in 64bit windows to direct to the 32bit version

    I have these in systems with different versions of MSI installed 64bit Office, so I assume all correct. 

    Without searching I don't know what your other two CLSIDs relate to.

    After un-registering the FM20 did you Repair Office to get it re-registered, if not you'd certainly get those error messages when trying to insert a form.

    Something else to try but not sure what it'd prove-
    In a problem system with FM20 registered, in a new Workbook try adding the reference programatically

    Const cGuid As String = "{0D452EE1-E08F-101A-852E-02608C4D0BB4}"
    
    Set wb = ActiveWorkbook ' ThisWorkbook ie the new workbook
    Set ref = wb.VBProject.References.AddFromGuid(cGuid, 0, 0)

    Will need to 'trust access to VBA Project' if not already in Trust Center / Macro Settings

    If that works try save / close /re-open(?) and then adding a userform

    Friday, October 6, 2017 2:29 PM
  • A complete fix for this particular problem suggested by Fernando Menegel (see page 2 of https://answers.microsoft.com/en-us/msoffice/forum/msoffice_other-mso_win10/office-2016-crashed-when-userform-added-to-vba/f2f16ffa-9a1f-4bfd-babb-1e93a78d5c65?auth=1) is to delete <filename>.BOX where <filename> is the program experiencing the problem. This fix has been verified on several systems at two different sites and deleting the file seems completely benign.

    The .BOX files are found variously in C:\Users\<user>\AppData\Roaming\Microsoft\Forms and C:\Users\<user>\ Application Data\Microsoft\Forms. A VBA enabled application (e.g. Excel) will recreate Excel.BOX each time it is run, so it needs deleting before every invocation.

    This explains why the exception did not occur when the application is executed for the very first time, because the BOX file didn't exist.

    So the details of the access violation in FM20.dll above are a bit of a red herring. In particular it seems that by design both versions of FM20 should be registered and both are loaded into the programs address space - this for a 32 bit VBA-enabled application running on 64 bit Windows 7 or 10 with Office 365 installed.

    Anyone got any idea what these .BOX files are for?

    • Marked as answer by pde14 Monday, October 9, 2017 9:30 AM
    Monday, October 9, 2017 9:30 AM
  • Anyone got any idea what these .BOX files are for?

    I'd never have guessed that was the culprit but it's *.box for 'toolbox'. If you add any non standard controls to the toolbox details get added in this file. If you delete the file it resets the toolbox to default.
    Monday, October 9, 2017 3:06 PM