Share via

VB6/COM app startup is slow on Windows Server 2019/2022/2025 vs. 2016—local COM only, trusted signing chain pending. How to reduce Code Integrity/Defender overhead and AppCompat/Fusion probing?

Deepak Kumar 0 Reputation points
2025-12-15T13:06:29.2466667+00:00

Hi All,

Environment & symptoms

  • Legacy VB6 (32‑bit) application with multiple COM/OCX components, all local (no remote DCOM).
  • Runs fast on Windows Server 2016. Noticeably 3-4x slower on Server 2019, 2022, and 2025
  • App binaries (EXE/DLL/OCX) are Authenticode‑signed; signatures are valid but initially not trusted (root/intermediate CA missing), later made trusted.
  • Procmon/WPR evidence during slow start (on 2019/2025):
    • Increased RegQueryValue/RegOpenKey against WOW6432Node\CLSID\TypeLib and related COM activation hives.
      • Extra CreateFileMapping (image section creation) and QuerySecurityFile around wintrust.dll/wldp.dll.
        • Application Compatibility (Shim) activity (apphelp.dll, %SystemRoot%\AppPatch\sysmain.sdb).
          • Fusion/PublisherPolicy probing (WPF/.NET framework assemblies) and language overlay lookups.
          • All COM servers are in‑proc, and WOW64 registration is correct (SysWOW64 regsvr32 used).

What we’ve tried

  • Ensured trusted chain (installed enterprise Root/Intermediate CAs) → reduced some WinVerifyTrust overhead.
  • Added Defender and third‑party AV process/folder exclusions (e.g., C:\AppFolder\).
  • VB6 UI optimizations: suspend redraw (WM_SETREDRAW) during bulk .Add; cache COM objects; avoid late binding on hot paths.
  • Reduced Fusion churn (binding redirects/codeBase for known managed components).
  • Verified no remote COM; firewall/RPC not involved.

Questions for Microsoft

  1. Code Integrity / WDAC / WinVerifyTrust
  • On Server 2019/2022/2025, what are the recommended practices to minimize Code Integrity (CI) latency for signed but previously untrusted (now trusted) app‑local binaries?
    • Beyond installing the CA chain, are there WDAC/AppLocker configuration patterns (e.g., allow rules scoped to C:\AppFolder\*.exe; *.dll; *.ocx) that reduce repeated policy checks without weakening security?
    • Any ETW providers or WPR profiles you recommend to isolate CI/WinVerifyTrust cost vs. loader cost for legacy VB6 apps?
    Microsoft Defender 
    - For local, signed VB6/COM apps that load many OCXs/DLLs, are **folder/process exclusions** sufficient on **Server 2019/2022/2025** to avoid meaningful I/O overhead, or are there **additional Defender settings** (e.g., MAPS, cloud‑delivered protection, network protection) known to impact app launch time?

   - Best‑practice guidance for **least‑privilege exclusions** (process vs. path) to balance performance and security?

   **Application Compatibility (Apphelp/sysmain.sdb)**

      - Is there official guidance to **reduce AppCompat matching cost** for legacy VB6 apps (e.g., PCA settings, known registry flags, or recommended defaults) on newer Windows Server versions?

         - Any documented changes in **Server 2019+** that would make AppCompat more active vs. 2016, and recommended mitigations?

         **COM activation (WOW64) & Registry probing**

            - We see more **registry probing** under `WOW6432Node\CLSID\TypeLib` in 2019/2025. Are there **loader tweaks or COM registration best practices** (beyond SysWOW64 `regsvr32`) that reduce probing, such as minimizing **TypeLib** references or setting specific **InprocServer32** values?

               - Any official guidance to pre‑warm or cache COM class info cleanly?

Fusion / PublisherPolicy / Resource probing

  • For missing, non‑required assemblies (e.g., an unused reference that triggers Fusion probes), is the recommended approach to neutralize via app.config (e.g., <publisherPolicy apply="no"/> + bindingRedirect + codeBase to a dummy path), or is there a cleaner Microsoft‑approved pattern to stop probing entirely?
    • Do newer Server builds increase PublisherPolicy checks for .NET/WPF stacks, and if so, any performance tuning guidance?

What we’re looking for

  • Official Microsoft guidance or KBs that address:
  • CI/WDAC/Defender interactions with legacy VB6/COM workloads and recommended allowlist/exclusion patterns.
  • AppCompat behavior differences between Server 2016 and 2019/2022/2025 and how to reduce startup cost.
  • Documented COM/WOW64 registration practices to minimize activation overhead on modern Windows.
    • Best practices to tame Fusion/PublisherPolicy and resource satellite probing where components are not required.Environment & symptoms
      • Legacy VB6 (32‑bit) application with multiple COM/OCX components, all local (no remote DCOM).
      • Runs fast on Windows Server 2016. Noticeably slower on Server 2019, 2022, and 2025 (cold start and first heavy form .Show).
      • App binaries (EXE/DLL/OCX) are Authenticode‑signed; signatures are valid but initially not trusted (root/intermediate CA missing), later made trusted.
      • Procmon/WPR evidence during slow start (on 2019/2025):
        • Increased RegQueryValue/RegOpenKey against WOW6432Node\CLSID\TypeLib and related COM activation hives.
        • Extra CreateFileMapping (image section creation) and QuerySecurityFile around wintrust.dll/wldp.dll.
        • Application Compatibility (Shim) activity (apphelp.dll, %SystemRoot%\AppPatch\sysmain.sdb).
        • Fusion/PublisherPolicy probing (WPF/.NET framework assemblies) and language overlay lookups.
      • All COM servers are in‑proc, and WOW64 registration is correct (SysWOW64 regsvr32 used).
Developer technologies | Visual Basic for Applications

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2025-12-15T13:06:49.0166667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    To address the slow startup of your VB6/COM application on Windows Server 2019/2022/2025 compared to 2016, consider the following recommendations:

    1. Code Integrity and WDAC: To minimize Code Integrity latency for signed but previously untrusted binaries, ensure that the root and intermediate CA chains are installed correctly. For WDAC/AppLocker, you can create allow rules scoped specifically to your application folder (e.g., C:\AppFolder\*.exe; *.dll; *.ocx) to reduce repeated policy checks. This can help maintain security while improving performance.
    2. Microsoft Defender: For local signed VB6/COM apps, folder/process exclusions should generally be sufficient to avoid I/O overhead. However, you may want to review additional Defender settings such as MAPS and cloud-delivered protection to ensure they are not impacting app launch times. Implementing least-privilege exclusions can help balance performance and security effectively.
    3. Application Compatibility: To reduce AppCompat matching costs for legacy VB6 applications, consider adjusting PCA settings or known registry flags. Investigate any documented changes in Server 2019+ that could affect AppCompat activity compared to 2016, and apply recommended mitigations.
    4. COM Activation and Registry Probing: To minimize registry probing under WOW6432Node\CLSID\TypeLib, ensure that your COM registration is optimized. This includes verifying that TypeLib references are minimized and that specific InprocServer32 values are set correctly. There may be official guidance available on pre-warming or caching COM class information to improve performance.
    5. Fusion and PublisherPolicy: For handling missing or non-required assemblies, you can use the <publisherPolicy apply="no"/> directive in your app.config, along with binding redirects and codeBase settings to neutralize unnecessary probing. Check if newer Server builds increase PublisherPolicy checks and adjust accordingly.

    For detailed guidance and best practices, consult official Microsoft documentation related to these topics, as they may provide further insights into optimizing performance for legacy VB6/COM applications on newer Windows Server versions.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.