Some disk-space alerts are easy: find the big folder, clear it, and move on. I couldn’t do that here — this was a case where the Windows temp folder keeps growing back within hours, no matter how much I deleted from it.
The Alert
It started with a Zabbix alert on C: drive usage for a Windows server tied to a production line, triggered at the 90% threshold. A user on the server had already seen it, cleared out some data by hand, and let me know. I’d seen the same alert come in on my side.
When I looked at the Temp folder, there were folders in it that I couldn’t place. They’d been created in a repeating pattern, and none of them were being released.
Space Came Back, Then Left Again
The user had already freed up space, so the usage should have been dropping. Instead it kept creeping back up.
Deleting the folders wasn’t fixing anything — they just kept coming back. I stopped looking at the disk and started looking at what Windows was actually doing in the background, and opened Event Viewer.
What the Event Viewer Showed
Two things stood out, tied to event IDs 322, 201, and 102.
First, SilentCleanup events were firing again and again, and the cleanup never seemed to finish. Second, the package state on the server still showed Uninstall Pending and Install Pending entries, left over from a Windows security patch installed in early July. The server had never been restarted after that patch.
My reading was that the pending patch state kept the cleanup from completing, and each unfinished attempt left another temp folder behind. I should be clear about which part I saw and which part I concluded. The pending entries and the repeating SilentCleanup events were in front of me. That one was causing the other is my interpretation, not something the logs proved outright. What I can say for certain is that after the restart, the disk usage stopped climbing and the same symptom didn’t come back.
Fixing It Without Stopping the Line
Finding the cause was only half the problem. The server was tied to a production line, so a reboot had to wait for a maintenance window.
In the meantime, I needed to buy space without risking anything. I didn’t know what deleting the most recently created folders might affect, and getting the service stable again was the priority, so I went after the oldest folders first instead — old enough that they were safe to clear without guessing at what was still in use. Then, once there was a window with no production scheduled, I restarted the server and watched it afterward.
The same symptom didn’t return.
The Timeline
The patch went in during early July. The disk-space problem didn’t show up until mid-September.
- Early July: the security patch was installed, and the server wasn’t restarted
- Mid-September: the C: drive alert, and the usage that wouldn’t stay down
- Two days later: the restart was done and the problem was resolved
Since this one, checking whether a server has actually been restarted after a patch — through Event Viewer or from the command line — is just something I do now, instead of assuming a scheduled patch job also means a completed one.
Related reading:
Frequently Asked Questions
Why did the temp folder keep filling up after it was cleared?
In this case, SilentCleanup events kept firing without finishing, and the server still had Uninstall Pending and Install Pending package states from a security patch that was never followed by a restart. That’s my reading of what Event Viewer showed. The strongest evidence is that the disk usage stopped climbing after the restart.
Did deleting the old folders fix it?
No, it only bought space. On this production server I deleted the oldest folders first to make room, and the actual fix was a restart during a window with no production scheduled. After that, the same symptom didn’t return.