This concerns
urBackupClientBackend.exe Version 2.2.6 ( Window 8.1 Pro 64-Bit)
When checking process memory with Process Hacker (or Task Manager) in Windows I notice that the urBackupClientBackend commits about 512 MB of private memory.
That’s quit uncommon so I got into more details in the PH Memory tab of the process.
There is one big block of 512 MB is allocated for use as Stack-Space for some thread that run with very low priority (-4).
Please check confirm this behavior. Is there a real need/reason for this? Maybe that’s some silent bug or debugging artifact. (like some compiler directive to set a huge stack for certain function to avoid a stack overflow or set some stack of a recursive function…)
->Can someone who’s in charge with the source code / development have a look on this.
Checking/View its data confirms that some how since there are only about 4KB of data at the end are used - the rest is just filled with 00.
Freeing this memory block or setting it’s access to AccessNotAllowed doesn’t provoke a crash or exception as I’ve would expected. Also killing that thread(what frees 512MB) doesn’t cause any notice errors hangs or malfunction.
Freeing that memory block makes urBackupClientBackend private memory to fall back to a more nice and acceptable value of somewhat around 70MB.