Visual Studio Slow Only on VPN? Check CRL and OCSP

Visual Studio starts normally at home, then the same laptop joins the corporate tunnel and every launch sits on the splash screen for half a minute. Take the policy away and the stall goes with it; take the tunnel away and the same thing happens. Both observations are accurate, which is why the two components keep getting blamed for each other. The deciding question is whether a certificate revocation lookup is waiting on a path that only the tunnel provides, or failing to find one at all.

Time the Fetch, Not the Launch

A WDAC policy, deployed as a signed SiPolicy.p7b, decides which images may run on the machine. Code integrity validates an image's signature chain before execution, and that validation can include a revocation question. The answer depends on the CRL distribution point or the OCSP responder that the certificate names inside it.

Those are ordinary network requests, so their cost depends on where the responder lives. When it is reachable only through the tunnel, or its name resolves only through a DNS server behind the tunnel, validation waits for the tunnel to be ready. Visual Studio loads a large number of signed assemblies and extensions at startup, and a small per-image delay becomes a visible stall. Nothing is malformed and the policy is behaving exactly as configured, which is why removing the policy appears to fix it.

Every Signed Image Can Trigger a Network Call

Start with a signed binary already on disk and ask the platform to verify it with the same fetch behaviour a launch uses. Run the command once on the tunnel and once off it, then compare the fetch lines instead of the final verdict.

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

The output lists the chain, the CRL and OCSP addresses, and whether each fetch succeeded. A responder that times out on the tunnel and answers off it is the evidence you need, and it carries far more weight than an impression of slowness. If the fetch succeeds slowly, note the address so the next step can test that host directly.

Resolve the responder host and test reachability outside the application, because a name that fails to resolve will never be repaired by a client setting. The CodeIntegrity operational log supplies the other half of the evidence, tying a validation event to the timestamp of the slow launch.

Shrink the Delay Without Removing the Control

Disabling the policy or switching it to audit mode makes the delay vanish and removes the control the organisation deployed, so treat that as the wrong repair. The narrower options are a routing change so the responder is reachable through the tunnel, a split-tunnel exclusion for the responder hosts, a DNS correction when the name resolves to an unreachable address, or a supported caching proxy for revocation data. Each has a different owner: the PKI team owns responder reachability, the network team owns the tunnel split, and the endpoint team owns the policy.

Excluding every revocation host from the tunnel is not automatically safe, since an internal responder may be internal on purpose. Confirm the exclusion with the team that runs the PKI before writing a rule that quietly sends certificate checks to the public internet. A change made without that confirmation is the kind that gets reverted at the next policy refresh.

Verify a Cold Start After the Change

Measure a cold start in both states and keep the numbers, because a warm start proves almost nothing once the assemblies are cached. Repeat the launch from a fresh session so the extension loading path is exercised again.

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

A repaired configuration still contacts the responder, or uses a caching path your PKI team approved, and the log shows validation completing rather than timing out. Confirm that a newly signed application still launches, since a policy that permits everything is not a successful repair. Check the Active policy folder and the enforcement state too, so the policy you are debugging is known to be the one running. Keep the certificate chain, the responder address and the launch timestamps in the same ticket, because a renewal usually moves the responder and leaves the exclusion or DNS rule stale.