Full system hard reset when executing a search — Everything 1.4.1.1032 x64 (also observed with 1.5.0.1417b Beta)

[bufayadexiaotudou]

# Reproducible full-system hard reset when an Everything search is executed

## Suggested title

Full system hard reset when executing a search — Everything 1.4.1.1032 x64 (also observed with 1.5.0.1417b Beta)

## Report body

Hello,

I am reporting a reproducible **full-system hard reset**, not a normal Everything application crash. The screen goes black immediately and Windows starts again. There is no BSOD, application crash dialog, dump, WHEA record, or BugCheck event. Everything can usually launch and remain idle, and its service can run normally; executing a search is the repeatable trigger on this machine.

The latest recurrence is important: `Search as you type` was already disabled. I typed a normal query and manually submitted it, but the machine still hard-reset. Therefore, incremental search is a high-probability trigger, but it is not the whole issue; the broader search/result-refresh path is involved.

### Environment

- Computer: Lenovo Legion R9000P ARX8, machine type 82WM
- CPU: AMD Ryzen 9 7945HX, 16 cores / 32 logical processors
- Memory: 2 × 8 GB Samsung DDR5-5600, configured at 5200 MT/s
- BIOS: Lenovo LPCN65WW
- OS: Windows 11 Home China, 25H2, build 26200.8973, x64
- VBS/HVCI: enabled according to Kernel-Boot events
- Everything stable build: 1.4.1.1032 x64
- `Everything.exe` SHA-256: `F191F756996A14A11E5445FA7103D302EFD510CF2FBF920E6C0C8ED51D512E36`
- Authenticode: Valid, signed by voidtools PTY LTD
- Earlier affected beta: 1.5.0.1417b x64
- Service before removal: Running / Automatic / LocalSystem, command line `"C:\Program Files\Everything\Everything.exe" -svc`
- Relevant third-party environment: Kaspersky Standard 21.26.4.406 with minifilters `KLIF.K4W-21-26` and `klbackupflt.K4W-21-26` mounted on the main volumes; Oracle VirtualBox 7.2.14 drivers; Logitech G HUB 2026.5.939708

The same hard-reset event signature has also occurred outside controlled Everything tests, so I am **not claiming that Everything alone is the root cause**. A driver, firmware, memory, power, or platform-stability interaction remains possible. However, Everything search actions repeatedly and immediately trigger the reset.

### Reproduction pattern and timeline

| Date/time (Asia/Singapore) | Build/configuration | Action | Result |
|---|---|---|---|
| 2026-08-09 | 1.5.0.1417b Beta | Launch Everything UI during an authorized reproduction attempt | Immediate hard reset; Event 41 recorded at the next boot, Record ID 13333 |
| 2026-08-09 | Clean install of 1.4.1.1032 | Initial UI and indexed-search checks | Passed at that time |
| 2026-08-10 12:51 / 12:52 / 18:38 boots | 1.4.1.1032, original result-refresh settings | Type the first character in the search box | User observed immediate black-screen resets; Event 41 records 13707, 13813, and 13974 appeared |
| 2026-08-10 21:03 | 1.4.1.1032; shell icon/context extensions off; Name ascending; `search_as_you_type=0`; normal user; service running | One explicit `-search a` query | Passed once for a 15-second observation |
| 2026-08-10 22:18–22:21 | Same configuration, changing only `search_as_you_type=0` to `1` | Normal use with incremental search | Immediate hard reset; Event 41 Record ID 14330 |
| 2026-08-11, before the 10:40 boot | Same mitigations restored, including `search_as_you_type=0` | Type a normal query and manually submit it | Immediate hard reset again; Event 41 Record ID 14665 at the next boot |

The one successful query did not prove safety. Both incremental and manually submitted searches have now been followed by the same hard-reset signature.

### Configuration at the latest recurrence

```ini
icon_shell_extensions=0
context_menu_shell_extensions=0
sort=Name
sort_ascending=1
search_as_you_type=0
search_history_enabled=0
```

The GUI ran as a standard user (`run_as_admin=0`, `InstallRunAsAdmin=0`). The Everything service was running as LocalSystem. The database was 44,800,976 bytes, last written 2026-08-10 21:16:32; I preserved it locally but will not post it publicly because it contains private filenames.

### Windows evidence

The latest Kernel-Power event was written during the next boot:

```text
Provider: Microsoft-Windows-Kernel-Power
Event ID: 41
Record ID: 14665
TimeCreated: 2026-08-11 10:40:02.238 +08:00
BugcheckCode: 0
PowerButtonTimestamp: 0
SleepInProgress: 0
WHEABootErrorCount: 0
LongPowerButtonPressDetected: false
BootAppStatus: 0
```

EventLog 6008 (Record ID 14651) was written at 10:40:10. It reports a previous shutdown time of 10:22:39, but events from the preceding boot continue after that timestamp, so I do not treat the 6008 text as an exact crash time. The last System record before the 10:40 boot was Kernel-Power 566 at 10:37:39; the Application log continued to 10:39:14. There was no immediately preceding WHEA, BugCheck, disk, NTFS, stornvme, storport, display-driver, or Everything application-error record.

Across the relevant Event 41 records, the signature is consistently Bugcheck 0, WHEA boot error count 0, no power-button timestamp, and no long-power-button press. No `MEMORY.DMP`, Minidump, or relevant LiveKernelReport was produced.

### What I tried

- Completely removed 1.5.0.1417b and clean-installed the signed 1.4.1.1032 x64 installer whose hash matched the official SHA-256 list.
- Tested the service separately from the UI. An idle service and an idle UI did not trigger a reset.
- Disabled shell icon extensions and context-menu shell extensions, changed sorting from Run Count descending to Name ascending, and disabled Search as you type.
- Verified one standard-user explicit query successfully, then performed a single-variable A/B test for Search as you type. Re-enabling only that option reproduced the reset.
- Disabled Search as you type again. A later manually submitted normal search still reproduced the reset.
- Compared `fltmc` and `driverquery /v` snapshots before and after recurrences. The minifilter set did not materially change.
- Checked System/Application logs and standard crash-report locations. No user-mode Everything crash or kernel dump was captured.
- Preserved the executable, INI files, database, event XML/EVTX, filter/driver snapshots, registry state, hashes, and uninstall transcript, then completely uninstalled the main Everything installation. I will not reproduce again without a low-risk diagnostic plan.

### Questions for the developer

1. Which Everything 1.4 code paths are entered only when a query is executed or results are refreshed, compared with an idle UI/service?
2. Can Everything's query/result enumeration interact with filesystem minifilters, shell metadata handlers, or the Everything service in a way that could expose a kernel/firmware fault even when both Everything shell-extension options are disabled?
3. Is there a diagnostic build, ETW provider, or command-line logging mode that can be enabled **before launch**, flushes synchronously, and does not require entering a search command in the GUI? The official `-debug-log` mode may be useful, but another hard reset is a data-loss risk.
4. Are there known issues with Windows 11 25H2 build 26200, Ryzen 9 7945HX, VBS/HVCI, Kaspersky minifilters, or VirtualBox filter drivers?
5. Which sanitized files would be most useful first: Event 41 XML, the INI, a minifilter list, driver versions, or a developer-provided trace? I can send sensitive files privately after review, but I cannot publicly upload `Everything.db` because it contains filenames.

I understand that a user-mode application should not normally be able to hard-reset Windows and that an underlying platform or kernel-driver issue may be required. I am reporting Everything as a repeatable trigger and would appreciate guidance on the safest way to capture the responsible path.

Thank you.

[void]

This sounds like a hardware issue. (possibly CPU or RAM or Powersupply)

Please try limiting Everything to one thread and see if stability improves:
In Everything, copy and paste the following into the search box:

/max_threads=1

Press ENTER in the search box.
If successful, max_threads=1 is shown in the status bar for a few seconds.
-If you are unable to paste in /max_threads=1 without windows crashing, please let me know.

1. Which Everything 1.4 code paths are entered only when a query is executed or results are refreshed, compared with an idle UI/service?

The Service does nothing, it just allows Everything to index NTFS volumes and read USN Journals.
Querying will use all available logical CPUs which can be taxing on the system. (CPU not getting enough power? overheating?)

2. Can Everything's query/result enumeration interact with filesystem minifilters, shell metadata handlers, or the Everything service in a way that could expose a kernel/firmware fault even when both Everything shell-extension options are disabled?

No, you should see a normal crash not a system crash.
Everything doesn't access these drivers, minifilters directly.
Indexing is more likely to access these drives and minifilters. Not searching.
An Everything query is only accessing RAM, possibly disk (not by default) and using CPU.

3. Is there a diagnostic build, ETW provider, or command-line logging mode that can be enabled **before launch**, flushes synchronously, and does not require entering a search command in the GUI? The official `-debug-log` mode may be useful, but another hard reset is a data-loss risk.

Try launching Everything with -debug
-or-
Copy and paste the following into the Everything Search box:
/debug
Press ENTER in the search box to show the debug console.

The console is not going to help diagnose a system crash.
Try a CPU stress test and a RAM stress test.

4. Are there known issues with Windows 11 25H2 build 26200, Ryzen 9 7945HX, VBS/HVCI, Kaspersky minifilters, or VirtualBox filter drivers?

Not that I'm aware off.
You would likely see a system crash indexing, not searching.

5. Which sanitized files would be most useful first: Event 41 XML, the INI, a minifilter list, driver versions, or a developer-provided trace?

None at this stage.