there is a huge 9{3808876b-c176-4e48-b7ae-04046e6c...

That file is almost certainly System Restore / Volume Shadow Copy storage inside C:\System Volume Information. Do not try to delete it by taking ownership and removing it manually. That folder is protected for a reason, and manual deletion can corrupt restore points or other Windows metadata.

Use Windows/VSS tools instead.

1. Check how much shadow-copy space is used

Open Command Prompt as Administrator and run:

cmd
vssadmin list shadowstorage

Also check existing restore points/shadow copies:

cmd
vssadmin list shadows /for=C:

If the large file belongs to VSS/System Restore, it should correspond to shadow-copy storage on C:.

2. Delete existing restore points safely

GUI method

Press Win + R, run:

cmd
SystemPropertiesProtection.exe

Then:

1. Select C:
2. Click Configure
3. Click Delete under “Delete all restore points”
4. Apply

This should remove the large file if it is restore-point storage.

3. Prevent it from becoming huge again

In the same System Protection window:

Option A — keep System Restore but limit size

Set Max Usage to something smaller, for example:

text
3–10 GB

This is the recommended option.

Option B — disable System Restore completely

Select:

text
Disable system protection

This prevents restore-point VSS files from being created for that drive, but you lose Windows restore-point rollback capability.

4. Command-line alternative

To delete all shadow copies for C::

cmd
vssadmin delete shadows /for=C: /all

To limit maximum VSS storage, for example to 5 GB:

cmd
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5GB

To remove the limit entirely is not recommended:

cmd
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=UNBOUNDED

5. Important note

You cannot fully prevent C:\System Volume Information from existing. Windows uses it for system metadata. What you can prevent is the huge VSS/System Restore file from reappearing by either:

text
limiting System Protection storage

or

text
disabling System Protection for C:

Recommended fix:

cmd
vssadmin delete shadows /for=C: /all
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5GB

Then verify with:

cmd
vssadmin list shadowstorage

Run these from Command Prompt as Administrator.

1. Delete all existing shadow copies

cmd
vssadmin delete shadows /all /quiet

Verify:

cmd
vssadmin list shadows
vssadmin list shadowstorage

You should see no shadow copies, or shadow storage usage near zero.

2. Disable System Restore for C:

Use PowerShell as Administrator:

powershell
Disable-ComputerRestore -Drive "C:\"

For multiple drives:

powershell
Disable-ComputerRestore -Drive "C:\","D:\"

You can also do it through GUI:

cmd
SystemPropertiesProtection.exe

Then:

1. Select C:
2. Click Configure
3. Choose Disable system protection
4. Click Delete
5. Apply

3. Disable the VSS services

In Command Prompt as Administrator:

cmd
sc stop VSS
sc config VSS start= disabled

Also disable the Microsoft software shadow-copy provider:

cmd
sc stop swprv
sc config swprv start= disabled

Important: there must be a space after start=.

4. Disable the scheduled System Restore task

cmd
schtasks /Change /TN "\Microsoft\Windows\SystemRestore\SR" /Disable

5. Reboot

After reboot, verify:

cmd
vssadmin list shadows
sc query VSS
sc query swprv

Expected service state:

text
START_TYPE         : DISABLED

Effects of disabling VSS

This may break or limit:

• System Restore
• Previous Versions
• Windows Backup / image backup
• Some third-party backup tools
• Backup of locked files
• Some database-aware backup tools

If you only want to prevent huge files, a safer option is to limit VSS storage instead of disabling it:

cmd
vssadmin resize shadowstorage /for=C: /on=C: /maxsize=5GB

If vssadmin delete shadows /all says no shadow copies, then that 9{3808876b-c176-4e48-b7ae-04046e6cc752} file is probably an orphaned System Restore/VSS file, not an active shadow copy. That GUID is commonly seen in System Restore / Volume Shadow Copy files under System Volume Information; Microsoft’s own vssadmin delete shadows only deletes registered shadow copies, so an orphan may remain. (Microsoft Learn)

Do this carefully.

1. Confirm the file path and size

Open Command Prompt as Administrator:

cmd
dir /a /s "C:\System Volume Information\*3808876b-c176-4e48-b7ae-04046e6cc752*"

Also check VSS state:

cmd
vssadmin list shadows
vssadmin list shadowstorage

Microsoft documents vssadmin list shadows as the command that lists existing shadow copies; if it returns none, Windows no longer has a registered VSS snapshot to delete. (Microsoft Learn)

2. Try deleting the orphaned file directly

Use the exact file name shown by dir. Example:

cmd
takeown /f "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /a
icacls "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /grant Administrators:F
del /f /q "\\?\C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

takeown is the Microsoft-supported tool for taking ownership of a file when access is denied, and icacls modifies file ACLs. (Microsoft Learn)

Do not run recursive ownership commands on the whole C:\System Volume Information folder. Only target the specific orphan file.

3. If access is still denied, delete it from WinRE

This is often the cleanest way because Windows is not running from C:.

1. Hold Shift and click Restart
2. Go to:

text
Troubleshoot > Advanced options > Command Prompt

3. Find the Windows drive letter. In WinRE, it may not be C::

cmd
diskpart
list vol
exit

Assume Windows is C: below; change it if WinRE shows another letter.

4. Delete the file:

cmd
del /f /q "\\?\C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

If needed:

cmd
takeown /f "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /a
icacls "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /grant Administrators:F
del /f /q "\\?\C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

4. Prevent it from coming back

You already disabled System Restore and VSS, but verify both.

PowerShell as Administrator:

powershell
Disable-ComputerRestore -Drive "C:\"

Microsoft documents Disable-ComputerRestore as the cmdlet that turns off System Restore on one or more drives. (Microsoft Learn)

Then disable scheduled restore-point creation:

cmd
schtasks /Change /TN "\Microsoft\Windows\SystemRestore\SR" /Disable

Check services:

cmd
sc query VSS
sc query swprv

If you want them disabled:

cmd
sc config VSS start= disabled
sc config swprv start= disabled

5. If it still reappears

Then something else is creating restore/shadow-like snapshots, usually:

• Windows Backup / system image backup
• third-party backup software
• disk imaging tools
• antivirus rollback/protection features
• backup agents from vendors such as Acronis, Macrium, Veeam, etc.

Check installed backup tools and Task Scheduler. VSS itself can be disabled, but a backup program may re-enable it or create metadata before failing.

The practical fix is:

cmd
vssadmin list shadows
vssadmin list shadowstorage

If both show nothing and the file remains, treat it as an orphan and delete the specific file from WinRE.

Yes, there may be an indirect relation, but probably not in the simple sense that “TRIM created a VSS snapshot.”

More likely chain:

text
TRIM / retrim on portable NTFS drive
        ↓
drive/enclosure/firmware mishandled TRIM, or NTFS already had corruption
        ↓
Windows detected NTFS errors and marked/processed the volume
        ↓
NTFS repair / volume metadata / System Volume Information activity occurred
        ↓
a VSS/System Restore metadata file under System Volume Information became orphaned or enlarged

Optimize-Volume / retrim can issue TRIM/retrim operations depending on volume type; Microsoft describes it as performing defrag, trim, slab consolidation, or storage-tier operations depending on the drive. (Microsoft Learn) NTFS also has self-healing behavior that can detect and repair minor file-system corruption online. (Microsoft Learn)

However, if the huge file is specifically in:

cmd
C:\System Volume Information\

and the NTFS errors were on a portable drive, then the connection is less direct. NTFS errors on E: or F: normally should not create a huge file on C: unless Windows, backup software, System Restore, indexing, or a storage-management operation touched C: at the same time.

The file name {3808876b-c176-4e48-b7ae-04046e6cc752} is strongly associated with VSS/System Restore storage, and there are documented cases where a large file with that GUID remains as a VSS orphan even when normal VSS tools do not list a shadow copy. (Microsoft Learn)

What I would check next

First, confirm which volume actually has the large file:

cmd
dir /a "C:\System Volume Information"
dir /a "E:\System Volume Information"
dir /a "F:\System Volume Information"

Replace E: / F: with the portable drive letter.

Then check whether the portable drive is dirty:

cmd
fsutil dirty query E:

If dirty:

cmd
chkdsk E: /scan

If errors are found and it asks for offline repair:

cmd
chkdsk E: /f

For the system drive:

cmd
fsutil dirty query C:
chkdsk C: /scan

Important conclusion

If:

cmd
vssadmin list shadows
vssadmin list shadowstorage

show no shadows and little/no storage usage, but the file remains, then it is probably an orphaned VSS/System Restore file, not an active snapshot.

In that case, the safest cleanup path is still:

1. Run chkdsk on both C: and the portable drive.
2. Reboot.
3. If the file remains and VSS still lists no shadows, delete that specific file from WinRE, not from normal Windows.

Why the TRIM event matters

TRIM should not cause NTFS corruption by itself. If the portable drive generated NTFS errors immediately after retrim, suspect one of these:

text
USB-SATA bridge does not properly support TRIM/UNMAP
drive firmware bug
unsafe removal / write-cache issue
pre-existing NTFS corruption exposed by retrim
failing SSD/flash media
wrong operation issued to the wrong drive

For that portable drive, I would stop using retrim on it unless you confirm the enclosure supports TRIM/UNMAP correctly. Run:

cmd
fsutil behavior query DisableDeleteNotify

and check the drive health with the vendor SSD tool or CrystalDiskInfo.

Yes. That makes the relation much stronger.

TxBench “secure erase” / whole-drive erase is not the same as Windows deleting files and then issuing normal TRIM for free clusters. It can send erase/deallocate commands across the target SSD. TxBench guides commonly recommend deleting the volume first and then running Secure Erase; the operation warns that all data will be permanently erased. (大山龍巳 | Tatsumi Oyama)

What likely happened:

text
TxBench whole-drive TRIM / secure erase on portable SSD
        ↓
drive or USB bridge translated the command poorly, or the drive was still mounted
        ↓
NTFS metadata / $MFT / bitmap / journal areas became inconsistent
        ↓
Windows detected NTFS corruption
        ↓
Windows wrote repair/log/system metadata under System Volume Information
        ↓
a large orphan file remained

For USB SSDs, TRIM depends on the host controller, enclosure, protocol, SSD firmware, and filesystem. Windows supports TRIM on USB SSDs only when the device path supports it, typically UASP with NTFS/ReFS; some controllers do not support it correctly. (Plugable)

So the important point is:

text
The large file probably was not created by VSS as a normal restore point.
It was likely collateral damage from filesystem corruption/repair after the whole-drive TRIM/erase attempt.

TRIM/DEALLOCATE tells the SSD that specified logical block ranges are no longer used; the controller may later erase those physical NAND blocks during garbage collection. (Rossmann Repair Group) If TxBench targeted ranges that still contained NTFS metadata because the partitions were left intact, Windows would see the filesystem as damaged afterward.

What you should do now

First, do not keep writing to that portable drive. Run repair checks.

For the portable drive, replace E: with the correct letter:

cmd
chkdsk E: /scan

If errors are found:

cmd
chkdsk E: /f

For the system drive:

cmd
chkdsk C: /scan

Then check whether Windows still sees dirty volumes:

cmd
fsutil dirty query C:
fsutil dirty query E:

If the huge file is on C:\System Volume Information and C: is clean, VSS lists no shadows, and System Restore is disabled, then it is probably safe to treat it as an orphaned file and delete only that specific file, preferably from WinRE.

For future whole-drive clearing

Do not clear an SSD by running TRIM while keeping the NTFS partitions mounted/intact.

Use one of these instead:

Best method

Use the SSD manufacturer’s Secure Erase / Sanitize tool.

Acceptable method with TxBench

Delete the target disk’s volumes first, then run secure erase. The TxBench guide does this with DiskPart clean before retrying Secure Erase. (大山龍巳 | Tatsumi Oyama)

Example, only after confirming the correct disk number:

cmd
diskpart
list disk
select disk N
clean
exit

Then run TxBench Secure Erase on the now-unallocated SSD.

More complete reset

For SSDs that support it, use NVMe Sanitize / ATA Secure Erase from vendor tools or bootable utilities. That is cleaner than trying to “TRIM the entire drive” through a USB bridge.

Bottom line

Yes: your TxBench whole-drive TRIM attempt can plausibly explain the NTFS errors and the leftover giant file. The likely cause is not active VSS, but an inconsistent filesystem/metadata state after issuing deallocate/erase commands to a still-partitioned portable drive.

Because System Volume Information is per-volume. A file in:

cmd
C:\System Volume Information\

means Windows created or left metadata on C:. The portable drive’s System Volume Information would be under its own drive letter, for example:

cmd
E:\System Volume Information\

So the TxBench operation on the portable drive did not literally “put” the file on C:. One of these happened.

Most likely explanations

1. C: was used as VSS shadow-storage backing space

VSS shadow storage can be configured with separate source and storage volumes: /for=<volume> and /on=<volume>. That means shadow-copy data for one volume can be stored on another volume, including C:. Microsoft’s vssadmin resize shadowstorage syntax explicitly separates the protected volume from the storage volume. (Microsoft Learn)

Check this:

cmd
vssadmin list shadowstorage

Look for entries like:

text
For volume: (E:)...
Shadow Copy Storage volume: (C:)...

If you see that, then C: was used as the storage area for shadow-copy/diff data.

2. Some component snapshotted C: at the same time

VSS is not only System Restore. Backup tools, disk tools, antivirus rollback features, imaging tools, and some storage-management components can request VSS snapshots. VSS coordinates point-in-time snapshots of volumes for backup/restore operations, and each shadow copy is identified by a GUID. (Microsoft Learn)

So the sequence could have been:

text
TxBench operation on portable SSD
        ↓
NTFS/storage errors reported
        ↓
backup/filter/storage component reacted
        ↓
C: shadow/system metadata was created
        ↓
VSS later shows no active shadows, but orphan file remains

That would explain why vssadmin delete shadows /all finds nothing now.

3. The Event Log errors may not have been for the portable drive

Windows Event Viewer often reports NTFS errors as \Device\HarddiskVolumeX, not always as E: or F:. It is easy to assume the event referred to the portable drive when it may have referred to C:.

Check both volumes:

cmd
fsutil dirty query C:
fsutil dirty query E:

Microsoft documents fsutil dirty query as the command for checking whether a volume’s dirty bit is set. (Microsoft Learn)

Also run:

cmd
chkdsk C: /scan
chkdsk E: /scan

Replace E: with the portable drive letter.

4. TxBench may have interacted with the wrong physical disk or all mounted disks

This is less likely if C: still boots normally, but still worth ruling out. In disk tools, “drive” can mean physical disk, logical volume, or selected device. If the wrong device was targeted even briefly, C: could have been affected.

Check the timestamps:

cmd
dir /a /t:w "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

Then compare that timestamp with:

text
Event Viewer > Windows Logs > System > Source: Ntfs, volmgr, disk, VSS, Chkdsk

What I would conclude

If the file is truly:

cmd
C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}

then C: was involved at the metadata/VSS level. The portable-drive TRIM likely triggered the situation, but the file being on C: means either:

text
C: was used as shadow-copy storage,
C: was snapshotted by another component,
the NTFS errors also involved C:,
or the disk tool interacted with C: unexpectedly.

Minimal safe cleanup path

Run these first:

cmd
fsutil dirty query C:
chkdsk C: /scan
vssadmin list shadows
vssadmin list shadowstorage

If C: is clean, VSS lists no shadows, and shadow storage shows no active association, then the file is probably an orphan. At that point, delete only that exact file from WinRE, not the whole System Volume Information folder.

That is good news: C: is not currently marked dirty and chkdsk /scan sees no live NTFS problem.

So the large file in:

cmd
C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}

is most likely an orphaned VSS/System Restore/diff-area file, not evidence of current corruption on C:.

What this means

Your portable-drive TRIM operation may still be related, but indirectly:

text
TxBench TRIM/erase on portable drive
        ↓
NTFS/VSS/storage error event
        ↓
Windows or a storage/filter component touched VSS metadata
        ↓
temporary VSS/diff-area file appeared on C:
        ↓
operation failed or was aborted
        ↓
file remained orphaned

Since C: now checks clean, the file is probably just leftover metadata.

Confirm VSS has no active reference

Run these as Administrator:

cmd
vssadmin list shadows
vssadmin list shadowstorage

Also check with PowerShell:

powershell
Get-CimInstance Win32_ShadowCopy

If all of those show no shadow copies, then Windows is not tracking that file as an active snapshot.

Check the file timestamp

cmd
dir /a /t:c "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"
dir /a /t:w "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

If the creation/write time matches the TxBench incident, that supports the orphan-file explanation.

Safe deletion path

Since C: is clean and VSS reports no shadows, delete only that exact file.

From normal Windows, Administrator Command Prompt:

cmd
takeown /f "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /a
icacls "C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}" /grant Administrators:F
del /f /q "\\?\C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

If access is denied, delete it from WinRE Command Prompt:

cmd
del /f /q "\\?\C:\System Volume Information\9{3808876b-c176-4e48-b7ae-04046e6cc752}"

If WinRE uses a different drive letter, find it first:

cmd
diskpart
list vol
exit

Final check after deletion

After reboot:

cmd
vssadmin list shadows
vssadmin list shadowstorage
fsutil dirty query C:

If the file does not return, the issue was just an orphan. If it returns, something on the system is still creating VSS/diff-area data, such as backup software, antivirus rollback protection, disk imaging software, or a scheduled storage task.