Stops working after a while (process still running)

[n00bmind]

Hi. I'm using a .bat script in shell:startup to launch uncap to remap some keys on every boot, like so: > uncap 0x91:0x14 For some time now, after working just fine for a while (hours), the remapping will altogether stop working. If I open task manager I can see the uncap.exe process is still there, so it's not that the process died. If I manually relaunch this .bat script, the new process will sit right there with the old one in task manager, and everything will go back to working again for a few hours (the amount of time it'll work for doesn't feel particularly consistent).

I basically never turn off my computer completely, only putting it on standby when the day is over. Could that have anything to do with it? I've been using uncap for years now but I never noticed this until somewhat recently.. This is on my Windows 10 desktop, I also use it on a laptop and another desktop at work and I don't think I've ever seen this behaviour in any of those.

I'm a power user so I don't mind delving into the registry or even attaching my debugger to the running process to figure out what may be happening.. any ideas?

[susam]

Hi @n00bmind, Thanks for reporting this issue. Without reproducing the issue myself, I can only speculate. One such speculation that comes to my mind: Is it possible that there is another tool running on the system that is also attaching a keyboard hook and that messes with what keystrokes Uncap can see? This is just a wild guess.

Uncap can be run in debug mode with uncap -d. If you are willing to troubleshoot this issue, you could keep uncap -d running as a foreground process and keep an eye on the debug logs to get a sense of what the debug logs look like during normal operation. Once the issue occurs, you could check the debug logs again to see if Uncap is receiving any keystrokes.

[n00bmind]

I've been running as a frontend process with uncap -d (just a normal cmd window that I kept open), and lo & behold even across a few days of putting the computer to sleep at night etc. the issue didn't happen a single time.. Yesterday I fully rebooted my computer so the normal background process was started again and today it broke again as usual..

If I add the '-d' flag to my batch file, its command window remains open instead of closing immediately, so I presume this will work. However I dont love the solution tbh..

Is there any way to tell uncap to log its debug output to a file instead or something like this?

[n00bmind]

Ok, so this is interesting.. I did add the '-d' flag to my batch file, and even though the console window has remained open this entire time, it did stop working after a while too. Now when I press any keys at all no new lines appear in the debug log (even with the console window fully in focus).. seems like the process stopped receiving input for some reason?

[n00bmind]

I went ahead and created a .dmp file for the running process, in case it's of any help to you.. If you point me to a .pdb file maybe I could connect to it with the debugger myself and have a look around.

uncap.zip

[susam]

Thanks for the debug output. The observations you have shared is what I had suspected. It does look like for some reason the keyboard hook that Uncap sets to receive key strokes becomes ineffective at some point. It is unclear what causes it but I suspect it could be because some other program is setting a keyboard hook that is interfering with Uncap.

Unfortunately, I don't have a PDB file for this binary. It would have been nice to keep one, however, I haven't kept one. If you have a compiler with you, you might be able to build Uncap from source and get a PDB file for yourself. There are some instructions in the dev/ folder about it. However, I doubt whether the dump is going to be useful. Uncap only reacts to keyboard events it receives and since Uncap does not receive any events when this issue occurs, not much can be found in the dump.