3 ms·

While the memory leak and the polling are in the same code it is likely that they require two different fixes - unless the notification of process creation is t

While the memory leak and the polling are in the same code it is likely that they require two different fixes - unless the notification of process creation is totally unnecessary.

throwaway613834 9y ago
AFAIK there's no way to get arbitrary process creation notifications without either registering for ETW (which only allows one real-time consumer, hence crippling the system, and which has a very long delay) or using kernel mode code (which I guess could work here since the already have a driver, but might present obstacles I'm not aware of). Another way is to use AppInit_DLLs which might be appropriate since anything that needs the mouse should probably load user32.dll, but otherwise it would miss something. Polling seems like the most foolproof way to do it purely in user mode.
- 0x0 9y ago
  The bigger question is why does a trackpad driver helper need a foolproof way of tracking all process create events? If it is for per-process trackpad preferences, couldn't it just query for the current foreground process at the time of a touchstart event?
  - throwaway613834 9y ago
    I don't know, but my random guess would be that it might be to handle quirks with certain events like drag-and-drop or scrolling, which need to be handled reasonably when a process suddenly opens a window under the one you're using. Not sure what such a quirk might be though.
- brucedawson 9y ago
  I'm no WMI expert but I was told (and said in the post): A polling query is particularly tragic in the case of Win32_Process, since Win32_ProcessStartTrace does the same thing without polling. So yeah, I think you can get process creation notifications without polling. Reference: https://twitter.com/kobyk/status/901561105570570242 https://twitter.com/kobyk/status/901561105570570242
  - throwaway613834 9y ago
    This seems to have the same built-in delay as ETW. But thanks for sharing, I wasn't aware of this one.

While the memory leak and the polling are in the same code it is likely that they require two different fixes - unless the notification of process creation is totally unnecessary.

throwaway613834 9y ago

AFAIK there's no way to get arbitrary process creation notifications without either registering for ETW (which only allows one real-time consumer, hence crippling the system, and which has a very long delay) or using kernel mode code (which I guess could work here since the already have a driver, but might present obstacles I'm not aware of). Another way is to use AppInit_DLLs which might be appropriate since anything that needs the mouse should probably load user32.dll, but otherwise it would miss something. Polling seems like the most foolproof way to do it purely in user mode.

0x0 9y ago
The bigger question is why does a trackpad driver helper need a foolproof way of tracking all process create events? If it is for per-process trackpad preferences, couldn't it just query for the current foreground process at the time of a touchstart event?
- throwaway613834 9y ago
  I don't know, but my random guess would be that it might be to handle quirks with certain events like drag-and-drop or scrolling, which need to be handled reasonably when a process suddenly opens a window under the one you're using. Not sure what such a quirk might be though.
brucedawson 9y ago
I'm no WMI expert but I was told (and said in the post): A polling query is particularly tragic in the case of Win32_Process, since Win32_ProcessStartTrace does the same thing without polling. So yeah, I think you can get process creation notifications without polling. Reference: https://twitter.com/kobyk/status/901561105570570242 https://twitter.com/kobyk/status/901561105570570242
- throwaway613834 9y ago
  This seems to have the same built-in delay as ETW. But thanks for sharing, I wasn't aware of this one.