TL;DR:

იუზერის მანქანაზე camsvc სერვისის SQLite ბაზამ ვეღარ შეძლო WAL ფაილის მთავარ ბაზასთან სინქრონიზაცია (Checkpoint), რამაც გამოიწვია CapabilityAccessManager.db-wal ფაილის კატასტროფული, 85.5 GB-მდე ზრდა და Storage-ის ამოწურვა.

გამოსავალი: psexec-ის მეშვეობით NT AUTHORITY\SYSTEM პრივილეგიების მოპოვება ლოკალურად, ლოგის წაშლა და სერვისის ხელახალი startup-ი —  ACL -ის “უაზრო” ცვლილებების გარეშე.

ინციდენტის აღწერა (Symptom)

C: დისკზე ადგილი ამოიწურა.

Treesize-ს მეშვეობით დადგინდა რომ დირექტორიაში C:\ProgramData\Microsoft\Windows\CapabilityAccessManager დევს ფაილი CapabilityAccessManager.db-wal, რომელიც იკავებდა კოლოსალურ 85.5 GB-ს.

მიზეზის ანალიზი (Root Cause)

რა არის ეს ფაილი? Capability Access Manager (camsvc) არის Windows-ის native სერვისი, რომელიც აკონტროლებს UWP და desktop აპლიკაციების წვდომას აპარატურაზე (კამერა, მიკროფონი). ამ უფლებების სამართავად ის იყენებს SQLite ბაზას.

მარტივად რომ ვთქვათ, .db-wal არის Write-Ahead Log. მექანიკა ასეთია: სისტემური ტრანზაქციები ჯერ იწერება WAL ფაილში და მხოლოდ ამის შემდეგ ხდება მათი მთავარ ბაზაში სინქრონიზაცია (Checkpoint). თუ რაიმე მიზეზით — იქნება ეს I/O throttling, lock timeout, დისკის დეგრადაცია თუ უბრალოდ სერვისის ბაგი — camsvc გაიჭედება და Checkpoint-ს ვეღარ შეასრულებს, მაშინ WAL ფაილი მთავარ ბაზაში ვეღარ იცლება და იწყებს უსასრულო ზრდას მანამ, სანამ storage სრულად არ შეივსება.

ფაილის წაშლის მცდელობა

პირველი აზრი რაც ამ დროს თავში მოგვდის: გავაჩეროთ სერვისი და წავშალოთ ფაილი.

Stop-Service -Name camsvc -Force

შემდეგ

Remove-Item -Path “C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal” -Force

შედეგი: ვღებულობთ IOException — The process cannot access the file because it is being used by another process.

სერვისი კი გაჩერდა, მაგრამ ფაილს რაღაცა ისევ აკავებს. რა? ამის გასარკვევად დაგვჭირდება უტილიტა handle64.exe Sysinternals-იდან

Invoke-WebRequest -Uri “https://live.sysinternals.com/handle64.exe” -OutFile “$env:TEMP\handle64.exe”

გაუშვით handle64.exe პრობლემურ ფაილზე:

& “$env:TEMP\handle64.exe” -accepteula CapabilityAccessManager.db-wal

დიაგნოსტიკამ აჩვენა, რომ ფაილის Handle მყარად ჰქონდა დაკავებული svchost.exe პროცესს.

PS C:\Windows\system32> & “$env:TEMP\handle64.exe” -accepteula CapabilityAccessManager.db-wal

Nthandle v5.0 – Handle viewer

Copyright (C) 1997-2022 Mark Russinovich

Sysinternals – www.sysinternals.com

svchost.exe        pid: 20072  type: File           2C4: C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal

მიუხედევად იმისა, რომ ტერმინალი ადმინისტრატორის უფლებებით გავუშვით ბრძანება

Stop-Process -Id 20072 -Force

ვიღებთ Access Denied-ს

პრობლემის გადაჭრა (Resolution)

გაითვალისწინეთ და ეს ძალიან მნიშვნელოვანია: მსგავს სიტუაციებში ინტერნეტ-ფორუმებზე ხშირად გირჩევენ Safe Mode-ში შესვლას ან, რაც ყველაზე უარესია, takeown / icacls ბრძანებებით ფაილის Owner-ის შეცვლას. Enterprise გარემოში ეს კატეგორიულად მიუღებელია! სისტემური დირექტორიების Security Descriptors-ის ხელით “ჩალიჩი” მომავალში Update-ების ჩავარდნას და სხვა გაუთვალისწინებელი პრობლემების საწინდარი შეიძლება გახდეს

ჩვენ არ ვეხებით NTFS უფლებებს. ჩვენ ვიყენებთ ლეგიტიმურ Privilege Escalation-ს ლოკალურად. system-protected ბლოკირების მოსახსნელად გვჭირდება არა უბრალოდ Administrator, არამედ NT AUTHORITY\SYSTEM დონე.

გამოიძახეთ psexec ლოკალურად (მოითხოვს admin prompt-ს):

ვიწეთ pstools, ამოვააარქივებთ, გადავდივართ ამოარქივებულ ფოლდერში და  ვუშვებთ ბრძანებას

.\psexec.exe  -S -I powershell.exe

ასეთი უფლებებით ჩვენ უპრობლემოდ გავაჩერებთ პროცესს

Stop-Process -Id 20072 -Force

და შემდეგ წავშლით ფაილს

Remove-Item -Path "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal" -Force


.

 

ხელახლა დაასტარტეთ სერვისი

Start-Service -Name camsvc

დასკვნა

იქ, სადაც სტანდარტული ადმინისტრატორი იჭედება “Access Denied” შეტყობინებებით, მარტივი psexec -s სუფთად და პროფესიონალურად ჭრის პრობლემას. სისტემური ფაილების წაშლამდე კი ჯობია გავერკვიოთ მათ წარმომავლობაში და მხოლოდ შესაბამისი პროცეუდირებით მოვახდინოთ მათი წაშლა.