Could you please rephrase your comment to make it more understable to mainstream tech users? I am having trouble understanding your point, why you appear to have voted to close it, or why I "should" have "PS script logging" or "EDR app tracking".

Where did R-TAS.exe come from? Is it a program you pay for with support, something developed in-house which you have developers and the source code, or is it something you allow users that access the server to download and run as they see fit? Sounds like you tracked it down to the app, but why it is doing this and what's causing it may depend on its code. Otherwise, pick a time and schedule a daily kill of the task during the best time the system is not in use to prevent it since not killing it over several days hoses the system for everyone all together.

Does it matter? (Where it came from?) The question is specific enough. (Seems you're trying to get to the root cause - which is nice - but that's not the question I am asking. The root cause is being addressed separately, via internal KB articles, SOPs, scheduled or triggered process "kill" automations - and vendor escalations. Let's focus on the question. :) Thanks!)

Yes but does the title of the question not imply you are looking for what is responsible though specifically which is focused on the question per the wording of the title of your question. The root cause is the app is not working with memory well or causing fragmentation of the memory on the operating system which you are running it on and I assume they have confirmed it is compatible with that OS. Also the hardware platform (or VM hypervisor) you are running it on and the vendor's compatibility may be applicable here too. Sounds like you're doing everything as I would too though, good luck!!

no it does not and in fact the question spells it out: "The context below isn't all that necessary to answer the question, and is provided just as that: as context, in case one is curious."

Oh buried question different than context of the title also in a question format, I see.... Do all the multiple zero kb instances of R-TAS.exe show up in Task Manager when they show up in RAMMAP UI? Curious if Get-Process and Task Manager only show one instance (or none) whereas the rammap app shows multiple?

Thanks for the kind words - appreciate that. To answer your previous question: the process (and the associated service) is a part of a framework of LoB services and applications (Truno Encor) in retail industry. Seems some parts of the framework are behaving fairly well, while some - not so much. My team is doing what it can to keep the lights on and avoid service interruptions, while also trying to get help from the vendor(s), and automate what's possible. As always, it's a multi-prong effort.

only one instance of R-TAS.exe in task manager. "Processes" in RamMap I think show dead process instances (not even R-TAS.exe - but R-TAS_process_) that R-TAS likely spins out but fails to gracefully "spin down" and release its memory. When I watch R-TAS in Tasm Manager, the "Handles" counter grows at about 4-6 per second.

Great call on "\Memory\Pool Paged Bytes").CounterSamples.CookedValue. While it's a system-wide metric, I started looking at it yesterday. Still want to get the amount of memory dead instances take in "page table" and get stats on them.

Maybe it is the free and zero list bytes?

@kindzmarauli ^^

I'd have to look each of those up to confirm but based on intuitive name, if applicable perhaps that one or the resident bytes one

The output is in bytes I believe though so format your output with math accordingly or use calculated value in select statement to format accordingly.

These may answer the part of the question about the overall memory map, and "page table" in RamMap specifically - but unlikely to give me the details, what (which processes - dead or alive) is taking substantial chunks of the page table.

@kindzmarauli Does Get-Process | Where-Object { $_.HasExited } give you anything relevant output wise when you see those dead processes

Does not. (No output, even when "run as administrator".) I think RamMap is not using process metrics (via Get-Process or any system calls of the like) - but rather is analyzing the memory map somehow.

What about playing with Get-CIMInstance -ClassName win32_process | Select-Object * and filtering it down with some Where-Object filters, does it give you anything rammap sees that Task Manager and Get-Process do not?

@kindzmarauli ^

there are some metrics there that I didn't see in Get-Process - but otherwise, the only things indicating abnormal memory usage are already in Get-Process output, e.g. Handles, PagedSystemMemorySize - which are far larger for R-TAS.exe than for any other process in the system.

...but let's remember that we are unlikely to find the needed "page table" stats in R-TAS.exe process metrics. The (dead) processes with runaway "page table" (and overall system memory) consumption were likely spun out by R-TAS.exe - but weren't part of its own memory space.

Unless Windows can give us names of dead processes spun out by another specific process, and their remaining memory utilization, we may have better luck looking at the memory map directly - which is I think what RamMap does, and listing process instances still taking any memory there.

Ending the (R-TAS.exe) process however does free up all that memory - so Windows knows the dead instances were spun out by that process, and is able to release the memory when the process is stopped. So maybe somewhere deep in the process metadata there's the needed information... Don't know!

@kindzmarauli What about getting the PID of the process that is visible with get-process by it's name, and then plugging that pid as the number variable here: Get-WmiObject Win32_Process -Filter "ParentProcessId = 10872" so rather than 10872, make that be whatever the pid is of the alive and visible T-RAS.exe?

This seems to spit out a whole lot of detail too (Get-CIMInstance -ClassName win32_process | Select-Object *).CimInstanceProperties @kindzmarauli

good thought - I'll check on it later today or on Monday - gotta switch to something else - thanks @TroubleMakerChatBroom!

You're welcome, I guess my handle name changes in chat session eventually per some site global default thing I changed once to keep it the same handle!

@kindzmarauli ^