0

I am working on a multi-instance UWP app that uses a win32 desktop extension. The desktop extension will be launched only once. I want to manage the lifecycle of desktop extension process so that when all UWP app instances will be closed it will exit. One way I have thought is checking periodically if the process group for the uwp app is in foreground or in background, like Task Manager does: Task Manager How do I go on doing that?? Is there any alternative way this can be done more elegantly??

Soumya Mahunt
  • 2,148
  • 12
  • 30
  • Related: [How does Task Manager categorize processes as App, Background Process, or Windows Process](https://devblogs.microsoft.com/oldnewthing/20171219-00/?p=97606). But what you are probably looking for is [Job Objects](https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects) instead. See [How do I wait until all processes in a job have exited?](https://devblogs.microsoft.com/oldnewthing/20130405-00/?p=4743). – Remy Lebeau Jan 02 '21 at 06:44
  • @RemyLebeau, thanks for the article, the thing I wanted was to know if any win32 api exist so that I can get the processes in app process group then checking those instead of checking all running processes, also I don't think Job objects are supported for uwp apps. – Soumya Mahunt Jan 02 '21 at 06:54
  • there is no such Win32 API. And while it is possible to [determine a process’s group ID](https://stackoverflow.com/questions/30249101/), what you describe sounds like an [XY Problem](https://meta.stackexchange.com/questions/66377/). – Remy Lebeau Jan 02 '21 at 07:43
  • 2
    A better solution is for the UWP processes to have a reference to something in the desktop extension. When all the references have been released, then the desktop extension exits. – Raymond Chen Jan 02 '21 at 13:42
  • @RaymondChen, that's a nice suggestion, but due to security limitation of UWP it is very difficult to have a reference to something in desktop extension. So I was thinking of creating/opening shared memory in UWP processes and wait on the memory to be disposed with `WaitOnAddress`. Is something like that possible?? – Soumya Mahunt Jan 06 '21 at 06:19
  • You could try to remain a local value in [local settings](https://learn.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data) or local folder to record the amount of instances of UWP app. Increase the local value when creating a new instance, and decrease the local value when exit a UWP instance. Check the local value to determine if the local value is zero when exit a UWP instance. – YanGu Jan 08 '21 at 07:52
  • @Yangu - MSFT your solution doesn't account the fact if an uwp app instance is force closed from task manager. – Soumya Mahunt Jan 08 '21 at 08:21
  • Could you please tell me why the uwp app will be forcibly closed from task manager? – YanGu Jan 08 '21 at 09:54
  • @YanGu - MSFT user can forcibly close the app anytime there is no reason I can think of he/she would do that but that scenario makes your solution redundant, especially if there is already a better solution suggested by Raymond Chen that covers this scenario and works perfectly. – Soumya Mahunt Jan 08 '21 at 10:04
  • WaitOnAddress does not work cross-process. To access a desktop component from UWP, you can set it up as a [brokered windows runtime component](https://learn.microsoft.com/en-us/windows/uwp/winrt-components/brokered-windows-runtime-components-for-side-loaded-windows-store-apps). Worst case, the UWP app passes its process ID to the desktop component, and the desktop component monitors the process handle and cleans up when the process exits. (How are you communicating between the UWP app and the desktop component anyway? You can piggyback on that IPC channel.) – Raymond Chen Jan 10 '21 at 17:12

0 Answers0