Hyper-V Event 7043: When pfSense VSS Breaks VM Save and Host Shutdown

A scheduled Hyper-V host reboot should have been routine. Instead, some virtual machines resumed normally while others came back from an unexpected shutdown. The Windows Server 2022 host logged Service Control Manager Event ID 7043, and a Windows Server 2025 RDS guest recorded Kernel-Power 41 and EventLog 6008. The surprising part: the setting that fixed the save failures belonged to a different VM — the pfSense router.

Our practical fix was to disable Backup (volume shadow copy), also shown as VSS, for that pfSense VM. We then switched it back on for a controlled comparison: the failure returned. Switching it off again restored clean save/restore behavior. A further host reboot the next day confirmed the working configuration. Here is the path from the first logs to that result, and what to check if your Hyper-V host behaves the same way.

The quick fix for the same failure pattern

On the affected Hyper-V host, open the pfSense VM’s Settings → Management → Integration Services and clear only Backup (volume shadow copy). Keep Shutdown, Heartbeat, Time Synchronization and Key-Value Pair Exchange as they were. In our case, no Windows guest setting needed changing.

The equivalent PowerShell change is shown below. Replace the example VM name with your router’s name and first list its integration services to confirm the VSS component. These commands target one VM; they do not reboot the host.

$router = "Example-pfSense"

Get-VMIntegrationService -VMName $router |
    Format-Table Name, Enabled, PrimaryStatusDescription,
                 SecondaryStatusDescription -AutoSize

Disable-VMIntegrationService -VMName $router -Name "VSS"

Get-VMIntegrationService -VMName $router -Name "VSS" |
    Format-List VMName, Name, Enabled

The last command should report Enabled : False. Microsoft documents per-VM integration-service management and the Disable-VMIntegrationService cmdlet.

Check your backup design before making this your permanent setting. Our pfSense router used its own configuration backup and was not part of a full-VM backup job. Windows VM backup integration stayed enabled. If your router relies on host-assisted online backups, validate the resulting backup and restore path as part of the change. Disabling VSS changes guest-coordinated backup behavior; it does not make every form of VM backup impossible.

Once the setting is changed, use an agreed maintenance window for a host reboot and check each VM’s actual save/restore outcome. The rest of this article explains the evidence worth collecting.

The environment where we reproduced it

The investigation and controlled tests took place on 3–4 November 2026. The following are the recorded system versions, rather than a list of minimum affected releases. Host names, customer details and network addresses have been omitted.

Windows Server 2022 was the host OS in our reproduction; Windows Server 2025 was running inside the Windows guests. That distinction matters when comparing reports. We also found operator reports involving other Hyper-V host releases, but our controlled test sequence was on this one physical host.

What made the failure easy to miss

After the host restarted, every VM could eventually show Running. That looked reassuring, but it hid two very different outcomes. Some guests had resumed their saved memory state. Others had booted their operating system again because the previous session had ended uncleanly. The saved-state setting in Hyper-V Manager had not changed.

During the original incidents, the RDS server also developed domain-logon problems. That initially pulled the investigation toward time synchronization, Kerberos, Netlogon and the domain controller. Those were real symptoms, yet the host and worker logs showed an earlier problem: the terminal server had never completed the expected save/restore cycle.

This was the useful shift in perspective: instead of asking only why one Windows guest had authentication trouble, we began asking why the host was failing to preserve that guest during shutdown — and whether another VM could interfere with the overall sequence.

The event IDs that connected the host and guest logs

We correlated host System, Hyper-V VMMS and Hyper-V Worker records with the affected guest’s System log. The VM identifier and the event message were essential: an event from a different VM, or a normal boot from another maintenance window, would have told a different story.

Event 7043 alone is a starting point. The stronger signature was 7043 on the host + a missing successful save/restore pair for a specific VM + fresh 41/6008 events in that guest. In the failing comparison, another guest also started normally without a matching successful save/restore pair, while three guests resumed correctly. A mixed result across VMs is therefore part of the pattern.

For a first pass, these read-only queries collect the relevant event families from a recent window. Run the host queries on the Hyper-V host and the guest query inside the affected Windows VM. Match messages, VM IDs and times before drawing a conclusion.

$since = (Get-Date).AddHours(-6)

# Hyper-V host: service shutdown and VM lifecycle records
Get-WinEvent -FilterHashtable @{
    LogName = "System"
    ProviderName = "Service Control Manager"
    Id = 7043
    StartTime = $since
} | Select-Object TimeCreated, RecordId, Id, Message

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-Hyper-V-VMMS-Admin"
    Id = 14100
    StartTime = $since
} | Select-Object TimeCreated, RecordId, Id, Message

Get-WinEvent -FilterHashtable @{
    LogName = "Microsoft-Windows-Hyper-V-Worker-Admin"
    Id = 18510, 18596, 18500, 18601
    StartTime = $since
} | Select-Object TimeCreated, RecordId, Id, Message

# Affected Windows guest: correlate with the host's reboot window
Get-WinEvent -FilterHashtable @{
    LogName = "System"
    Id = 41, 6008
    StartTime = $since
} | Select-Object TimeCreated, ProviderName, RecordId, Id, Message

Keep the original exports if the guest clock has jumped. In our initial incidents, an approximately one-hour correction made a simple timestamp sort misleading. Record order, provider, VM identity and the matching host timeline gave us a much better reconstruction. An old shutdown-tracker prompt on its own was much less useful than newly recorded events from the actual test window.

How FreeBSD VSS became the leading hypothesis

The router was configured to shut down cleanly, while the other five VMs were configured to save. Its Backup/VSS integration was enabled. Hyper-V reported primary status OK alongside a secondary protocol-version warning; KVP showed a warning too. We found similar warnings on other routers, so the warning alone did not explain why this host failed.

The more useful lead came from existing operator reports. In a Microsoft Community Hub discussion, an administrator described pfSense interfering with the automatic stop actions of Windows VMs and restoring normal behavior by disabling its backup integration. An OPNsense report from February 2025 described the same cross-VM shutdown pattern and suggested either stopping the router first or disabling its Backup integration. These were useful firsthand reports to test against our own logs.

We then examined the FreeBSD upstream VSS daemon source. Its capability check skips device mounts and read-only mounts, then rejects writable filesystems whose type is not UFS. The freeze implementation uses UFS suspension. Our router used ZFS and a writable tmpfs mount, which gave us a concrete compatibility reason to question its live-backup integration. A running hv_vss_daemon process was clearly not enough to establish that the required filesystem operations would work.

That source inspection explained why VSS deserved a controlled test. It did not trace the exact Windows shutdown path or identify the precise code in pfSense’s shipped binary. Our working model was that a failing or stalled router-VSS interaction disrupted the host’s coordinated stop/save sequence. The next step was to change that one integration component and see whether the Windows VM failures followed it.

Saved state, checkpoints and backup consistency

Three Hyper-V mechanisms are worth separating here. AutomaticStopAction = Save preserves a VM’s running state when the host stops. A standard checkpoint captures VM state including memory. A production checkpoint coordinates guest data consistency through VSS or filesystem-freeze support and does not capture running memory in the same way. Microsoft’s checkpoint documentation describes the checkpoint types.

Our reproduction was a host-reboot/save-state test. We did not need to create a checkpoint to trigger the failure. The connection was the router’s enabled Backup/VSS integration during the overall shutdown sequence. If you arrived here while investigating failed production checkpoints, the guest’s VSS/filesystem capability is also relevant — but checkpoint creation needs its own verification.

The off / on / off test that settled the practical question

We kept the host, time configuration, VM stop actions, monitoring and other integration services unchanged. The single test variable was Backup/VSS on the pfSense VM. All times below are CET (UTC+1). The letters describe the tested configuration: A = VSS off, B = VSS on.

That was the decisive result for us. Disabling router VSS made the expected save/restore behavior return; re-enabling it brought the failure back; disabling it again restored the working state. The confirmation reboot supported leaving that setting in place. We did not change service-kill timeouts, disable time synchronization, force-stop VMs or delete saved-state files to make the test pass.

One part of the original incident deserves a separate sentence: the bad comparison reproduced the save/shutdown failure, but a fresh RDS login still worked afterwards. The earlier persistent Kerberos/NLA trouble and one-hour clock jump did not reappear in that run. We therefore treat the router-VSS fix as the reproduced solution to the save/preshutdown problem, while keeping the earlier authentication aftermath distinct.

What we now check after a host reboot

• Confirm the router’s Backup/VSS setting and the other integration services independently.
• For every VM configured to Save, find its successful save and restore records in the same maintenance window.
• Check the affected guests for new OS boots and fresh Kernel-Power 41 / EventLog 6008 records.
• Verify services and a real user login. A reachable RDP port or a green availability sensor cannot demonstrate a working domain session.
• Allow delayed-start VMs and the normal time-service retry to complete, then repeat the checks. Record timestamps and the observation interval.

In our successful runs, time corrections of roughly 96–102 seconds matched the pause while the guests were saved. The host initially could not resolve its external NTP source before the delayed router startup; the normal retry synchronized it about 15 minutes later without a manual resync. Those details helped us avoid confusing a startup dependency with a newly introduced authentication failure.

Our conclusion after the test series

For this Windows Server 2022 host with a pfSense 2.8.1 / FreeBSD guest, disabling only the router’s Backup/VSS integration was the effective fix for the reproduced VM-save and host-preshutdown failure. It is now one of the first settings we inspect when a mixed Hyper-V environment shows Event 7043 and Windows guests return from a host reboot with unexpected-shutdown events.

The controlled test series covers one physical host. Together with the earlier operator reports, it gives us a practical, repeatable diagnostic route: identify the mixed save/boot pattern, inspect the FreeBSD router’s backup integration, verify backup requirements, change one setting and prove the result per VM. The exact internal defect and its full version range remain a question for a deeper trace; the useful operational result is already clear enough to share.

If this matches your environment, start with the event correlation and the one-VM VSS setting above. You may save yourself a long detour through the configuration of the Windows guest that merely happened to show the consequences.

Sources and further reading

• Microsoft Learn: Manage Hyper-V Integration Services
• Microsoft Learn: Disable-VMIntegrationService
• Microsoft Learn: Hyper-V checkpoint types
• FreeBSD upstream: hv_vss_daemon.c — capability check and UFS freeze implementation
• Microsoft Community Hub: guest state not saved on host reboot — firsthand pfSense/OPNsense reports
• OPNsense Forum: Volume Shadow Copy causing VM issues

The environment, event correlations and test table above come from our own investigation. The linked upstream code and documentation explain the technologies; the community reports show what originally pointed us toward the test. Customer identifiers and raw operational logs are intentionally left out.