System.Diagnostics.Process.GetProcesses and System.Diagnostics.ProcessModule

[diamondes3]

I'm creating a program that needs to get a list of currently executing processes in memory and take action to kill a given process, if it's a different instance of the same (currently executing program) that has become hung for some reason; where I have a criteria based on start time to declare a given process as being hung. This logic is being developed on a windows machine using "dotnet" core, then packaged and run on a Ubuntu machine.

If I get a list of processes via "Process.GetProcesses", I can see my currently executing logic in the list as "dotnet". This isn't real helpful, as what if there are X different "dotnet" programs running on this machine, they all look like they are the same logic due to the "dotnet" name. Some of them MIGHT be hung instances of the logic I'm after, some of them MIGHT be totally other "dotnet" assemblies.

I figured out, that if I examine the list of modules for a given process (ProcessModule), the ProcessModule.ModuleName is the name of the underlying .dll that the "dotnet" core environment is running.

This works fine on the Windows machine running Visual Studio. When I compile and package the logic and run it on the Linux machine, I get can get the list of Processes, examine their corresponding modules; however, the underlying .dll that the "dotnet" core is executing is missing from the list of modules that should be in that given process. In other words, the .dll name shows up as a module in the Windows process, but does NOT show up as a module in the Linux process; even though numerous other modules DO show up in the Linux environment for the given process.

There are no exceptions or any other errors that I'm seeing, just not seeing the underlying .dll listed as a module for a given process on the Linux machine.

Any constructive thoughts on this?

[benaadams]

Maybe add to: https://github.com/dotnet/core-setup/issues/2007

[diamondes3]

That'd be fine. It's a bit of an add on to dotnet/runtime#4662 if you try to solve the module issue. If you solve the issue in dotnet/runtime#4662, I think that would suffice for what I'm describing, unless you find there is some logic issue within the code that is exposing the attributes of the modules.

…

On Fri, Aug 11, 2017 at 16:40 Ben Adams ***@***.***> wrote: Maybe add to: dotnet/core-setup#2007 <https://github.com/dotnet/core-setup/issues/2007> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/coreclr/issues/13340#issuecomment-321925308>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUPb-ZAcDOD_5aHBhEIggBgAhS_HSBz8ks5sXMpRgaJpZM4O1ATN> .

[jkotas]

This issue was moved to dotnet/corefx#25652