Azure VPN Client intermittently fails after update because Credential Manager (VaultSvc) does not start

Question

Azure VPN Client intermittently fails after update because Credential Manager (VaultSvc) does not start

Caden Hurst 0

We have experienced a recurring issue with the Azure VPN Client for Windows across multiple devices.

The issue appears to occur shortly after an Azure VPN Client update. When affected, users are unable to connect to the VPN because the Windows Credential Manager service (VaultSvc) is stopped and does not start successfully when the VPN connection is attempted.

In one documented case, the Azure VPN Client logs showed:

Prerequisite checks completed, but some tests did not pass.
Details: Windows service 'vaultSvc' is in state: Stopped (expected: Running).
Error Code: 0xA0042191

and:

GetWindowsServiceStatus result for service vaultSvc is: Stopped

We have observed the following behavior:

The issue has occurred on multiple Windows devices.

It has occurred following more than one Azure VPN Client update.

Manually starting Credential Manager immediately allows the VPN connection to succeed.

In one reproduced case, repeatedly clicking Connect in Azure VPN Client eventually caused VaultSvc to start and the VPN connected successfully.

Rebooting affected devices has consistently cleared the condition in the cases we have observed.

VaultSvc is configured with its normal Manual startup type.

We also tested the service outside of the affected post-update state. If we manually stop VaultSvc and then initiate an Azure VPN connection, the service starts automatically and the VPN connects successfully.

This suggests the issue is not simply caused by Credential Manager being configured for Manual startup. Instead, there appears to be a temporary condition after some Azure VPN Client updates where the service does not start correctly when Azure VPN Client attempts to use it.

We were also able to reproduce the issue on a second PC while Microsoft Store and Office updates were being installed. At the time, Microsoft Store showed an update for Azure VPN Client. After the device was rebooted, the issue could no longer be reproduced.

Has anyone else experienced this behavior?

In particular, we are trying to determine:

Whether there is a known Azure VPN Client issue that can leave VaultSvc unable to start correctly after an update.

What component is expected to trigger VaultSvc when an Azure VPN connection is initiated.

What additional logs or traces would be useful to collect while a machine is in the affected state.

Whether there is a supported mitigation that can prevent this from recurring after Azure VPN Client updates.

Any guidance from Microsoft or others who have seen the same behavior would be appreciated.

Shree Hima Bindu Maganti 7,590 Reputation points Microsoft External Staff Moderator

2026-08-19T02:03:48.0566667+00:00

Hi @Caden Hurst
Based on the information provided, this behavior does not currently appear to be caused by an Azure VPN Gateway or underlying network connectivity issue. The Azure VPN Client logs specifically indicate that the Windows VaultSvc (Credential Manager) service is stopped, and the VPN connection succeeds immediately after the service is started manually. In addition, the fact that VaultSvc starts successfully when it is manually stopped during a normal state suggests that its Manual startup configuration is expected and is not, by itself, the root cause. Microsoft documentation confirms that the Azure VPN Client performs prerequisite checks that include the state of Windows services, and the client provides options to run diagnostics and collect client logs. Therefore, we recommend reproducing the issue while VaultSvc is in the stopped state and collecting the Azure VPN Client status logs, diagnostic results, and client log files, together with Windows Event Viewer/System and Service Control Manager events related to VaultSvc. It would also be useful to record the exact Azure VPN Client version, Windows build, and any Microsoft Store/Windows updates installed immediately before the issue. At this time, we are not aware of a Microsoft-documented known issue specifically describing Azure VPN Client updates leaving VaultSvc unable to start automatically, so we would avoid attributing the behavior to a confirmed client regression without additional evidence. If the same behavior can be consistently reproduced across multiple devices following a specific Azure VPN Client version, the collected logs would be appropriate for further investigation .
https://learn.microsoft.com/en-us/azure/vpn-gateway/about-vpn-profile-download
https://learn.microsoft.com/en-us/troubleshoot/azure/vpn-gateway/vpn-gateway-troubleshoot-vpn-point-to-site-connection-problems
https://learn.microsoft.com/en-ie/troubleshoot/azure/vpn-gateway/troubleshoot-azure-vpn-client
Let me know if you have any further assistances needed.

1 answer

Your answer

Answer 1

Hello @Caden Hurst

Your testing does narrow this down quite well. The key observation is that VaultSvc is stopped when Azure VPN Client performs its prerequisite check, and manually starting VaultSvc immediately restores VPN connectivity.

VaultSvc is the Windows Credential Manager service. Its normal startup configuration is Manual/on-demand, so seeing it stopped on its own isn't necessarily abnormal. I wouldn't change it permanently to Automatic as the first fix, especially since you've shown it normally starts when the VPN client requests credential access.

The unusual part is the post-update condition where Azure VPN Client apparently requests Credential Manager functionality, but the service doesn't start successfully. The fact that rebooting clears the condition and that you reproduced it around an Azure VPN Client update makes the update/install transition worth investigating.

Microsoft's current Azure VPN Client documentation also recommends running the latest client and verifying the installed version under … > ? Help.

For the next occurrence, before rebooting or manually starting the service, I would capture:

Get-Service VaultSvc | Format-List *
sc.exe qc VaultSvc
sc.exe qtriggerinfo VaultSvc
sc.exe queryex VaultSvc

Then check Event Viewer > Windows Logs > System for Service Control Manager events around the exact VPN connection attempt. Also check the Azure VPN Client logs for the 0xA0042191 prerequisite failure.

If possible, record the Azure VPN Client version before and after the Store update. That will be particularly useful if this can be tied consistently to a specific client build.

Microsoft currently publishes Azure VPN Client separately as well; the current Download Center release is 4.0.5.0, published March 26, 2026.

As a temporary mitigation, starting Credential Manager manually is reasonable:

Start-Service VaultSvc

I wouldn't recommend permanently changing VaultSvc to Automatic unless Microsoft specifically identifies that as the supported workaround. Your test showing the service starts automatically during a subsequent VPN connection suggests Manual/on-demand operation itself isn't necessarily the problem.

At this stage, I haven't found a Microsoft document confirming a known Azure VPN Client defect specifically matching post-update VaultSvc failing to start with 0xA0042191. Since you've reproduced it on multiple machines and across multiple client updates, I'd keep the logs, exact timestamps, Windows build, VPN Client versions, and Service Control Manager events from the next occurrence. That would give Microsoft enough information to determine whether the failure is in the Azure VPN Client's credential-service invocation, the Store/MSIX update lifecycle, or Windows service activation.

Sharing these references with you:

Configure Azure VPN Client – Microsoft Entra ID authentication

Azure VPN Client – Microsoft Download Center

Configure Azure VPN Client for P2S connections

Please "Accept the Answer" if this information helped you. This will help us and others in the community.