RAID Volume Unintentionally Reformatted via VDS (Virtual Disk Service) – Seeking Cause & Audit Path

Recently, a operational RAID array on our system unexpectedly lost its data payload and was returned to an unformatted / freshly formatted state.

Upon inspecting the System and Application event logs, there are no user attribution logs (no user account associated with the action). The only footprint left behind in the logs indicates that the Virtual Disk Service (vds.exe) or VDS Basic Provider initiated the structural modification/reformat process.

We are trying to understand why the operating system or VDS triggered this automatically without explicit administrative interaction, and how we can trace the root caller.

Observed Behavior & Log Evidence:

The volume dropped offline / changed state and was subsequently re-initialized or formatted.

The event log shows vds / vds.exe executing the action, but under the SYSTEM security context (S-1-5-18), leaving no administrative username.

No manual execution of diskpart or diskmgmt.msc was performed by active users at the time of the event.

Questions for the Community:

What automated Windows services, background tasks, or storage features can invoke VDS to re-initialize or reformat a degraded or inconsistent RAID volume? (e.g., Storage Spaces background repair, SAN/iSCSI auto-reprovisioning scripts, third-party backup agents, or drive failure policies?)

Is there a deeper trace log or ETW (Event Tracing for Windows) provider for VDS that records the parent process ID (PPID) or caller application that commanded VDS to perform the format?

Are there known bugs or edge cases where a temporary loss of quorum/disk disconnect causes Windows to view a RAID array as "Uninitialized" and automatically clear its signature upon reconnection?

Any guidance on advanced logging flags, registry audit paths, or historical context on this VDS behavior would be greatly appreciated.