Windows Search indexing is stuck — the item count hasn’t moved in a day, search results are half-missing, and the indexer seems to be running forever without finishing. On a Copilot+ PC it’s worse: the AI semantic layer waits on the classic index, so a stuck indexer blocks both dumb and smart search. Everything downstream queues behind this one jammed process.

Indexing gets stuck for mundane reasons: a corrupt file choking the content parser, a damaged index catalog, the indexer fighting antivirus over file locks, or power settings pausing it indefinitely. The fix is unjamming the specific blockage — not reinstalling Windows, not waiting another week.

This guide unsticks AI indexing in technician order: confirm it’s actually stuck, remove the pausing causes, clear the file-level blockages, repair the services, rebuild the catalog, and verify the AI layer follows. The same layered logic applies across AI PCs — our DBeaver on ARM guide covers the shared platform stack, and voice typing on ARM shows the same service-layer patterns — while NPU overheating is worth checking if the indexer is cooking your machine.

Why this happens

  • Indexing paused on battery: The most common “stuck” report — Windows pauses indexing off AC power, and users on battery-heavy routines never give it a plugged-in window.
  • Corrupt file choking the parser: One damaged PDF, mailbox, or media file can hang the content indexer indefinitely — the count freezes at the same number for days.
  • Damaged index catalog: The catalog database itself can corrupt, leaving the indexer spinning without progress on a broken foundation.
  • Antivirus file-lock fights: Real-time AV scanning the same files the indexer is parsing creates lock contention that stalls both.
  • Disk errors: Bad sectors or filesystem corruption in indexed locations make the indexer retry forever on unreadable files.
  • Stuck Windows Search service: The Search service itself can wedge — running but not progressing — needing a restart, not a rebuild.
  • AI model downloads competing: On Copilot+ PCs, simultaneous AI model downloads plus indexing can starve the indexer on slow disks.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Confirm it’s stuck (not just slow) and unpause it

Half of “stuck indexing” is normal pausing misread as failure. Verify actual stuckness before taking destructive action — and give it the AC-powered idle time it needs.

  1. Open Settings > Privacy & security > Searching Windows and note the exact indexed item count and status.
  2. Plug into AC power — indexing pauses on battery by design; this alone “unsticks” most reports.
  3. Wait 30 minutes of idle plugged-in time, then recheck the count — movement means it was paused, not stuck.
  4. Check Respect power settings when indexing under Advanced indexing options — disable it temporarily to force progress.
  5. If the count is identical after hours of idle AC time, it’s genuinely stuck — continue.

Fix 2: Restart the Windows Search service

A wedged Search service runs without progressing — the classic “it’s on but doing nothing” state. A service restart clears the wedge without touching your index.

  1. Press Win+R, type services.msc, and find Windows Search.
  2. Right-click and choose Restart — wait for it to come back up.
  3. In Task Manager, confirm SearchIndexer.exe is running and showing some CPU/disk activity.
  4. Recheck the indexed count after 15 minutes of idle time — movement means the wedge is cleared.
  5. If the service won’t start or immediately stops, check Event Viewer (Windows Logs > Application) for Search errors — the specific error names the real problem.

Fix 3: Find and remove the choking file

When the count freezes at the same number repeatedly, one corrupt file is usually jamming the parser. The Event Viewer names it — then you quarantine it.

  1. Open Event Viewer > Windows Logs > Application and filter for Search or SearchIndexer errors — note any file paths mentioned.
  2. Common culprits: damaged PDFs, corrupt Outlook PST/OST files, broken media files with bad metadata.
  3. Move the suspect file out of indexed locations temporarily (don’t delete yet) and restart the Search service.
  4. Watch the count — if it starts moving, you’ve found the jammer; repair or replace that file.
  5. For Outlook data files specifically, run the Inbox Repair Tool (scanpst.exe) — corrupt PSTs are the single most common indexer jammer.

Fix 4: Fix disk errors and AV contention

The indexer can’t catalog what the disk can’t read, and it can’t parse files your antivirus has locked. Both produce the infinite-retry pattern.

  1. Run chkdsk C: /f in an elevated Command Prompt (schedule at reboot if prompted) — fix filesystem errors in indexed locations.
  2. Check your antivirus exclusions — exclude the Windows Search index folder from real-time scanning (check your AV’s documentation for the path).
  3. Temporarily pause real-time AV protection for 30 minutes as a test — if indexing surges, you’ve found contention; add permanent exclusions.
  4. Check drive health in Task Manager’s Performance tab — a failing drive with reallocated sectors will stall indexing forever; back up first.
  5. Restart the Search service after disk and AV fixes, and watch for count movement.

Fix 5: Rebuild the index catalog

When the catalog itself is corrupt, no service restart or file removal helps — the foundation is broken. Rebuilding discards the damaged catalog and starts clean. Your files are untouched.

  1. Go to Settings > Privacy & security > Searching Windows > Advanced indexing options.
  2. Click Advanced, then Rebuild under Troubleshooting — confirm the warning dialog.
  3. Plug into AC power, disable the power-throttling option from Fix 1, and leave the PC idle.
  4. Full rebuilds take 2-6 hours — the count climbs steadily when healthy; watch for a new freeze point (which would indicate another choking file — see Fix 3).
  5. Don’t use semantic search judgments until the rebuild completes — the AI layer needs the finished classic index.

Fix 6: Verify the AI layer catches up

On Copilot+ PCs, the semantic AI index builds on top of the classic index — a finished classic index doesn’t automatically mean finished AI indexing. Verify the AI layer separately.

  1. After the classic index completes, confirm the NPU is healthy in Device Manager > Neural processors.
  2. Check Settings > Windows Update for pending AI component downloads — the semantic models may still be fetching.
  3. Leave the PC plugged in and idle — semantic embedding of the fresh index takes additional time after classic indexing finishes.
  4. Test with a concept query (“budget spreadsheet from March”) — semantic hits confirm the AI layer is done.
  5. If classic search works but semantic doesn’t after all this, check the Microsoft Windows support hub for build-specific AI indexing issues.

Closing

Stuck Windows Search AI indexing is almost always one of six things: paused on battery, a wedged service, a corrupt file jamming the parser, disk errors, AV contention, or a damaged catalog needing rebuild. Confirm stuckness before acting, work from the gentle fixes (AC power, service restart) to the thorough ones (rebuild), then verify the AI semantic layer catches up on Copilot+ PCs. Indexing is a background utility — once unjammed, it should disappear back into the background where it belongs.

Frequently asked questions

How long should Windows Search indexing take?
Initial indexing takes 2-6 hours on a typical drive, longer with hundreds of thousands of files. If the count hasn’t moved in several hours on AC power, the indexer is stuck, not slow.
Why does indexing keep pausing?
Windows pauses indexing on battery power and throttles it during heavy use. Plug into AC power and leave the PC idle — pausing on battery is normal behavior, not a bug.
Will rebuilding the index delete my files?
No — rebuilding only recreates the search catalog, which is a database of pointers. Your files are completely untouched; only the index is discarded and rebuilt.
Does AI indexing use a lot of CPU?
Initial indexing uses moderate CPU and disk, then drops to near-zero for incremental updates. Sustained high CPU from the indexer for days indicates it’s stuck on a corrupt file, not normal operation.