Thanks, I updated the patch to check access.
WRT second point, whatever we are going to do optimizing this without touching dbghelp looks impossible. Our dbghelp.EnumerateLoadedModulesW64 works ~25 times slower on Windows compared to Windows dbghelp. And 800 times slower on Wine than on Windows without substituting current process; with this patch it only 20 times slower for the same process (vs 26 on Windows).
In the current design EnumerateLoadedModulesW64 calls EnumProcessModulesEx, GetModuleInformation and GetModuleFileNameExW. Checking if the process is current takes two server calls, so only that will deliver ~400 server calls in concerned case.
Then, it seems to me that on higher level (dbghelp vs kernelbase) we might use a tiny bit more freedom in choosing performance optimizations ways which look a bit tweaky rather than on lower level, isn't that the case? Also, while it looks a bit tweaky, the same process case is probably not that exceptional, at least when it is not an post-crash report and that performance may matter a lot.