This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(54.400000000000006, 26%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECD%3C/text%3E%3C/svg%3E)
By invoking an analysis of a storage disk with 'defrag /A', it is discovered that the largest free block is highly disproportionate to the actual free size. This is discovered after the Event ID 154 has made its appearance in Event Viewer with relevant symptoms of disk errors, need for chkdsk.exe, corrupting files, failures.
The largest free block is restored to its expected nominal value by shrinking disk size as closely to the data boundary and extending it back again. Most or all symptoms subside, noises, problematic scans from chkdsk.exe, bad clusters; two Surface Tests on the disk indicate no issue.
Possible causes for the offsided largest block count in the 'reclaiming of space' by updating applications, the protected folders access or the protected memory access.
But how is Event ID 154 involved to this?
https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/disk-event-id-154
The reference there is an adapter, a switch, or a storage array. Are those integrated parts of a baseboard?
(At one point the intensity of the Event ID 154 had time enough to stretch the disk into two fatal failures with WHEA-Logger ID 1)
For example at this point a source of corruption was detected and an index entry was deleted if to report in events that 'the drive is healthy and no further action is required'; now to my estimation, there has been a decrease in the largest free block by a 15% in contrast to the initial one detected at about 85% with the 'defrag /A' tool. This made for an isolated incident with one index entry, like making a start for. (fsutil dirty query & wmic diskdrive status are cleared through for now)
The origin of the latest corruption is designated as 'unknown' and the only option available appears to be a reformatting of a grand storage drive that cannot be backed up;
According to this document the cluster size can be changed for a new format, and that's more like a post-reaction to an unknown origin which may have its continuation nonetheless?
By the way, the change of seconds in Registry for disk TimeOutValue has been attempted; there is also an IoTimeOutValue there and possibly the change affects all disks online?
But the error has occured again by way of some known applications' activity (e.g. running a scan for antimalware or launching an 'exe').
The latest info may concern how much Secure Boot made any difference in relation to the Event ID 1796 which would not complete because there was a target to maintain Secure Boot disabled.
Can Event ID 154 result from a combined effect as also by way of not having assigned any page file to a storage disk? Like in a reproduction scenario?
The change of seconds in the TimeOutValue entry can be seen in the different type the WHEA-Logger ID 1 occured in Event Viewer; its description of the event had rearranged the sentences to express about the same meaning. Not likely so?
Presently I could see that the change in seconds only altered the tendency of the WHEA-Logger to occur more promptly? But nothing else to save from the Event 154.
If it carries a hint, the disk could pass easily the Long Generic Test and a Quick Test, but it would abort readily a Long Self Test by generating on the process an Event 154; however when it was more likely at a fresh boot to escape generating of its own an Event 154, it passed the Long Self Test and generating at the start of the process a NTFS corruption Event which was rectified by chkdsk.exe
On a final retrospect, it is estimated that Windows security cannot become aware of a hub agent that applications run through it and are visible in Programs&Features but the actual hub agent is not listed there nor in Programs/controlPanel. The hub agent can 'start' in cmd, it is listed in shell:AppsFolder but it's nowhere else. The event 154 is generated gradually and can be intensified to loggers making the storage disk unstable to the point of generating error even with defrag.exe- (had Windows in the past been connected to previous storage disks when the system disk had to be replaced with another? not all applications became fully Windows-aware?)
Is it a problem with inheritances?
It may a be a good clue to explain this nofication in Windows bar?
This message appeared at about the same time with running a SG tool's test for spinnning the disk down; the disk comes back afterwards on any activity.
