Prevent an access violation. The reproduction step for the access violation in Access is as follows:

* With an existing Access file containing a VBA project, decompile, compile, and compact & repair the Access file.
* Open Access, load the Access file, open VBIDE
* As soon as Rubberduck finishes loading and the parse button is available, hit it

This usually will yield an access violation when executing IVBEProject.CompileProject().

To avoid this from happening, we need to call IVBEProject.Placeholder3(). That seems to prevent the access violation. Using a known method such as GetCompilationArgs() does not seem to work in preventing the access violation. Nor does pumping the message pump using UiDispatcher.FlushMessageQueue() nor ComMessagePumper.PumpMessage(). Placeholder3() seems to have no permanent side effect.

Author: bclothier

Rubberduck.VBEEditor/ComManagement/TypeLibs/TypeLibVBEExtensions.cs

@@ -4,6 +4,7 @@
 using System.Linq;
 using System.Runtime.InteropServices;
 using System.Runtime.InteropServices.ComTypes;
+using NLog;
 using Rubberduck.VBEditor.ComManagement.TypeLibs.Abstract;
 using Rubberduck.VBEditor.ComManagement.TypeLibs.Unmanaged;
 
@@ -66,6 +67,7 @@ internal class TypeLibVBEExtensions : ITypeLibVBEExtensions
     {
         private readonly string _name;
         private readonly IVBEProject _target_IVBEProject;
+        private static readonly Logger Logger = LogManager.GetCurrentClassLogger();
 
         public ITypeLibReferenceCollection VBEReferences { get; }
 
@@ -87,6 +89,24 @@ public bool CompileProject()
         {
             try
             {
+                // Prevent a potential access violation by first calling the Placeholder3(). 
+                // Under certain conditions where the VBA project is fully compiled, clicking parse
+                // as soon as Rubberduck has loaded into VBIDE can cause an access violation when 
+                // accessing CompileProject(). We've tried using ComMessagePumper and 
+                // UiDispatcher.FlushMessageQueue but neither helped in preventing the 
+                // access violation. We at least know that Placeholder3() does not save the unsaved
+                // change so hopefully there should be no permanent side effects from invoking the
+                // Placeholder3(). 
+                try
+                {
+                    _target_IVBEProject.Placeholder3();
+                }
+                catch(Exception ex)
+                {
+                    Logger.Info(ex, $"Cannot compile the VBA project '{_name}' because there may be a potential access violation.");
+                    return false;
+                }
+
                 _target_IVBEProject.CompileProject();
                 return true;
             }