Dbgview与小狼毫输入法冲突

今天在调试一段代码的时候，偷懒用了OutputDebugString，于是想打开Dbgview看输出。双击了没反应，试了试dbgview64，还是没反应。有点奇怪，心说是不是旧版本不能用了，看看SysInternals有没有新版本可以下载，点开Chrome，发现Chrome启动也没反应了。心里有点慌，想开任务管理器看看到底怎么回事，结果任务管理器也打不开，这才真的有点发慌了。

一番折腾没有效果，包括找了别的电脑RDP远程桌面过来，也进不了桌面，还把主机卡在登录界面进不去了。还好右下角的重启按钮还是有反应，而且没让我等多久。
重启完以后，第一时间去开任务管理器，然后重来了一遍。之前以为是偶然现象，确实很久没重启了，但发现这次Dbgview还是卡住，还是只能重启。反复折腾了几次，都是如此。上网一搜，还真有人遇到类似问题，一看「对方」——小狼毫。

这和我的情况对上号了，我也在用这个小狼毫作为输入法。于是我把这个输入法的主进程WeaselServer.exe杀掉以后再去开Dbgview，工作得非常正常。于是案子算是破了。
接下来我好好调查了一番这个事情。除了原Github贴子反馈的事情，我还发现了一些情况：

如果先有WeaselServer.exe，再去启动Dbgview.exe，Dbgview就会卡住，界面出不来。如果事先开着任务管理器，就会看到Dbgview.exe进程出现，并未「无响应」，CPU占用率也不高。此时如果杀掉了WeaselServer.exe，系统会立刻恢复正常。杀掉Dbgview.exe也行，但系统恢复要慢上一点，似乎在等待着什么。

如果是先有Dbgview.exe，再去启动WeaselServer.exe，则会在Dbgview上看到大约100条左右的日志出现。多也没有很多，而且后续并没有更多的日志出现。
诡异而关键的一点来了：此时DbgView也能在界面上通过鼠标正常操作，只是不能碰键盘。如果一动键盘，哪怕仅仅单独碰了一下Ctrl或Shift键，都会导致DbgView无响应。

而只要Dbgview.exe开始卡住，接下来Windows里面就会无法新建进程。在别的已经启动的进程里面，也不能去碰键盘，一碰就卡。包括任务管理器，我前几次被迫重启，就是栽在这里——我实在是太喜欢用快捷键了。

在测试时，有碰到过一次Process Explorer能够「例外」，也就是说操作键盘不会被卡住。但接下来我想要再重现，发现它的「防护结界」失效了。所以目前还算是没找到规律。

这问题看上去是Dbgview.exe和WeaselServer.exe这两个进程在键盘消息的处理方面有所冲突。原Github贴主提到的「过滤掉“.cc:”相关日志」的临时解决方案，并不能解决我遇到的问题。我试过，即使让DebugView停止Capture也不行。不过，只要注意启动顺序，并能忍住不要去用键盘，就还暂时可以让它们俩一起工作，相安无事。

我不知道作者会不会去修正这个问题，以及什么时候修正。有点担心，恐怕他缺乏足够的动力和精力去做这种事情。现在真的没什么好输入法可以用了么？

最后的更新：2024年08月20日，我在Gmail上收到Github的动态。一句「无法重现」随后便把这个issue给关闭了。我其实是很愿意配合的，但是对方大概已经下定了决心，只能遗憾了。