Windows.edb file fills up disk - but is not displayed as target when cleaning up storage

Question

On an 8 year old industrial PC the 118GB SSD was filled up by a 85GB Windows.edb file.

Why is there no Windows-warning for this...?

Am I missing something?

It took some effort to finally locate this file - using the following command in an Administrator CMD:

dir C:\ /A /C /S /OGN /TW > C:\temp\Cdrive.txt

then import all files in an Access table and sort by size...

The tool SpaceSniffer - also run as Administrator and "show unaccessible space" - first indicated the issue.

Answer 1

Hi VP.

Thanks again for explaining where to find "known issues" - and for taking time to share your knowledge.

This is what makes communities so powerful - MS Moderator or not...

Jake

Answer 2

Hi VP,

thank you for being so specific.

Are you a Microsoft moderator - or do you just know the stuff - and where to find issues with specific Windows versions...?

Thanks anyway.

Jake

Answer 3

Hi VP.

The windows in question is:

Edition: Windows 10 Enterprise 2016 LTSB

Version: 1607

OS Build: 14393.5

I deleted the Windows.edb - but it is now growing...

The replacement PC has

Edition: Windows 10 Pro

Version: 22H2

OS Build: 19045.3930

Exp.: 1000.19053.1000.0

I was not aware of the issue, so I have not monitored the size of Windows.edb - but will do that soon. And probably disable the WSearch.

If I do

Sc config wsearch start=disabled

Net stop wsearch

and delete the windows.edb - is it then disabled for good? Or will a restart start it up again?

Does that require me to do the "registry editor"?

Answer 4

Hi Jake104E,

To accurately diagnose the root cause of the runaway database growth, I need you to reply with the exact Windows OS edition and build number running on that machine, as massive Windows.edb bloat is a documented bug in several older offline environments, particularly around the Windows 8 and early Windows 10 lifecycles, which require specific manual patch installations.

Regarding your architectural assumption, you are completely correct that explicit file calls by qualified addressing rely strictly on the NTFS Master File Table, not the Windows Search database. Because no human users are executing wildcard or metadata searches on this terminal, the definitive best practice is to permanently disable the indexing engine rather than modifying its scope. You should execute sc config WSearch start= disabled followed by net stop WSearch in an elevated command prompt. Alternatively, you can open the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSearch, and change the Start DWORD value to 4. Once the service is disabled and the file lock is released, you can safely delete the C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb file entirely. This action will permanently reclaim your storage and completely eliminate the unnecessary disk I/O operations previously caused by the background indexing service.

VP