The case of the volume label that doesn’t change
A customer liaison forwarded a problem from their customer: When the customer changed the volume label on a drive, the change is not reflected in Explorer. Explorer continues to show the old volume label.
A ProcMon trace revealed that
svchost.exe running as
NT AUTHORITY\SYSTEM attempted to open the root of the drive but got
STATUS_ACCESS_DENIED. The access was coming from the shell hardware service at a point where it calls
GetVolumeInformation to get the volume label.
Okay, that makes sense that the shell hardware service was trying to access the volume to read the volume label. After all, it was told that there was a change to the volume label, so it’s going to the volume to see what the new label is. The question is why the shell hardware service, running as
I asked, “How did that happen? The
SYSTEM account should have full access to the drive by default. Did the customer apply a custom ACL that revokes
SYSTEM access? You’ll find that a lot of things stop working when you revoke
The customer liaison wrote back, “Indeed, the customer did remove the
SYSTEM account from the drive’s permissions. I am not sure exactly what they were thinking when they revoked
SYSTEM access. I need to ask them.”
We didn’t hear back from the customer, so maybe the customer was too embarrassed to explain why they revoked
SYSTEM access to the drive.
Another case of a customer changing a security setting without really understanding why they did it, and then wondering why stuff stops working.