I apologize for the interruption, but here's the situation:
Since the release of Windows 11, Chinese users of Directory Opus (DOpus) have encountered a problem: using DOpus in conjunction with Sogou/WeChat input methods causes Chrome to crash. Here are a few posts from the Chinese internet that document this issue:
Upon investigation, the issue seems to stem from the ShellExecuteHooks registered by DOpus. Deleting this registry key prevents Chrome from crashing. Besides this method, there are a few other ways to prevent Chrome from crashing:
Delete the ShellExecuteHooks key from DOpus
Uninstall WeChat Input Method or Sogou Input Method
Revert to Windows 10
Additionally, it's worth noting that these Chrome crashes occur in the following specific situations:
Clicking "Open in Folder" in the download page
Any scenario that launches an external application (e.g., clicking "view in telegram" in Telegram)
In summary, the crashes happen when Chrome needs to call shell32.dll.
Additional Information
I also attempted to use x64dbg to attach to chrome.exe and discovered the likely cause of the problem: shell32.dll accesses memory pointed to by a null pointer. The issue arises because a function in dopuslib.dll calls TlsSetValue, causing the TLS value read by shell32.dll to be incorrect. However, switching back to the built-in Windows input method results in an additional TlsFree step in dopuslib.dll, allowing it to work correctly.
Therefore, I would like to know if DOpus can try to resolve this issue, or at least provide information about the role of the ShellExecuteHooks registered by DOpus. If its role is not critical, I would recommend that Chinese users delete this registry key themselves.
Chrome blocks third-party DLLs, including ours, from being loaded into its process, so I'm surprised the DLL is even being loaded in this situation.
What's the TLS index that's being set? Knowing that may make it easier to track down the code that's involved.
Not sure why it would act differently for different input methods, since we don't look for them or do anything different with them, as far as I know. Any idea why that would cause a change? Could the issue be in the input method's code instead?
Regarding this point, it should be because chrome calls shell32.dll when executing the shell open operation, and then shell32 calls dopuslib.dll because of ShellExecuteHooks.
zero 0
I don’t know much about this. China’s major Internet companies don’t pay much attention to user feedback, so it’s hard to get help from them. That’s why I came to ask for your help.
For that, in x64dbg, I add a breakpoint on TlsSetValue. And I found the dopuslib is the only one dll calling TlsSetValue when Chrome crashes. So maybe the input method did something that makes the slot not freed correctly.
Thanks for your effort in solving this. Appreciate it. I will try the next beta release and report here.
Hi, I have tried the latest version 13.6.2 and it still doesn't work.
However, I think I finally found the root cause of the problem. (Forgive me for researching dopuslib using disassembly tools)
The problem is that, for chrome.exe, the DllMain will return early. So the TlsAlloc will not be called.This makes the tlsindex ( global variable dword_1801C0240) being the initial value which is 0.That is to say, DOpus uses a tlsindex allocated by chrome instead of the one allocated by itself.
After I change the string "chrome.exe" in x64dbg to something else. The bug disappears.
So, why is the initialization of chrome skipped when fdwReason==1?
