Hi,
I'm hoping someone with deep knowledge of Everything64.dll's internals can help, or knows if this is a known issue.
Setup
Loading Everything64.dll at runtime via LoadLibraryW (not linking against the .lib)
Calling in order: Everything_SetRequestFlags → Everything_SetSearchW → Everything_QueryW(TRUE)
This happens from inside a plugin DLL loaded into a host application's process (not a standalone .exe)
The problem
The very first Everything_QueryW(TRUE) call in a session crashes - reliably, not intermittently. Windows reports this as an access violation (0xC0000005), and in one Windows Event Log entry also as 0xC000041D with the module shown as "Everything64.dll_unloaded".
The crash address is always at the exact same offset relative to the module's own base address, every single time (only the base address itself differs run to run, due to ASLR). This looks deterministic, not like random memory corruption.
Once past that first call, later queries in the same session work fine.
What I've already ruled out through testing
Everything_IsDBLoaded() returns TRUE right before the crash, so it's not a "database not ready yet" issue
Adding a delay between loading the DLL and the first query (tested from 100ms up to 3+ seconds) does not prevent the crash
Both the host application and Everything.exe are running with the same privilege level (neither is elevated) - ruled out a UIPI/admin-mismatch issue
The exact same search query string works correctly when typed manually into Everything's own search UI
Function signatures for SetSearchW/SetRequestFlags/QueryW were double-checked against multiple independent language bindings (VB, Delphi, C#, PureBasic) and match
My current suspicion
The host application (Total Commander) has its own built-in Everything integration (accessible via its "ev:"/"ed:" search prefixes), which may open its own IPC channel to Everything from within the same process. I haven't been able to confirm or rule this out directly - is it possible for two separate Everything_QueryW-style IPC clients to conflict when running in the same process/thread?
Question
Is this a known interaction, or is there a recommended way to safely call the SDK from inside a plugin hosted by another application that might already be talking to Everything on its own? Any pointers on what might be different about this scenario versus a standalone .exe using the SDK would be hugely appreciated.
Happy to provide more diagnostic detail (exact offsets, full Event Log XML, etc.) if useful.
Thanks!
Deterministic crash inside Everything_QueryW (DLL SDK) - always on first query of a session
-
Native2904
- Posts: 120
- Joined: Mon Nov 22, 2021 8:36 pm
-
void
- Developer
- Posts: 20179
- Joined: Fri Oct 16, 2009 11:31 pm
Re: Deterministic crash inside Everything_QueryW (DLL SDK) - always on first query of a session
Please let me know the crash offset in Everything64.dll
You are using the Everything SDK2.
The Everything SDK2 has a global process state.
You may run into troubles if this state is shared.
Please use the Everything SDK3 if you want to use multiple states.
-or-
You'll have to send the IPC request yourself and process the results.
You are using the Everything SDK2.
The Everything SDK2 has a global process state.
You may run into troubles if this state is shared.
Please use the Everything SDK3 if you want to use multiple states.
-or-
You'll have to send the IPC request yourself and process the results.
-
Native2904
- Posts: 120
- Joined: Mon Nov 22, 2021 8:36 pm
Re: Deterministic crash inside Everything_QueryW (DLL SDK) - always on first query of a session
I cleared it with es.exe. I think that is enough for my purposes.
Thank you
Thank you