svchost and nsi in particular have persistently been associated with memory leaks over the years with Google searches turning up many hits (but few solutions). Related questions with related answers have been asked multiple times on superuser in the past, but all that I've seen have been by people asking how to determine which process contains the leak which is not much help if I already know that.
I'm opening this question because the problem seems to persist despite claims that this or that solution fixed it and also to report the results of my own investigation in case it's helpful and to see how else I might be able to dig into the problem.
The one thing suggested that might have addressed the problem was application of KB 2950358 (sorry, can't link for lack of rep), but the installer simply says that this update is not applicable to this system.
Machine, OS and software: Win7 Pro x64, 8 GB memory with nVidia GTX 580 video (drivers from nVidia, 372.54 dated August 15, which is 15 days ago at this writing). Processes that are nearly always running include Spotify, Chrome (currently v52.0.2743.116), Skype (currently 7.26.0.101) plus a few Cygwin mintty, bash and ssh processes. Internet Explorer is not installed (beyond the bits that can't be removed). Usual browser add-ins such as flash for yt etc. Nothing hugely out of the ordinary, although a few of those make heavy use of networking and could, theoretically, be implicated if the likes of KB 2847346 are to be believed. All windows updates including the latest optional roll-up update have been applied.
Omitting some intermediate steps, I separated nsi out into its own svchost, rebooted and then logged the output of tasklist, every second, for the PIDs of the nsi process and the svchost to which nsi used to belong. The results are plotted here; sure enough, the latter is basically flat, but nsi grows at a steady (if not increasing) rate.
At the same time, I used procmon to record sys calls made by nsi, but all but 6 events were Thread Create and Thread Exit events, which isn't very helpful. Whatever is causing the problem is not causing nsi to make syscalls of its own.
Before I split nsi out, I did a similar trace for nearly four days and that svchost instance started off at 24 MB and grew continuously to about 2150 MB before I stopped it, with the rate of change apparently increasing with time. In the past, I've seen the offending svchost process upwards of 6 GB but, with the procmon running, that was the point at which I began to run out of memory. A couple of times, some memory was released, but not as much as was allocated. I can link this graph later if anybody wants to see it.
I also monitored that with procmon and can provide a break-down of events, but they're probably not very interesting given that it's established nsi that's at fault and that none of its events are particularly interesting.
Is there any tool for tracking what processes are making requests of a particular service?
What's my next move given that the apparently relevant KB hotfix is not applicable?
rpcrt,rpchttp). I assume the reason the hotfix said 'not applicable' is that it's fairly old (2014) and these files have already been patched via windows update. The memory leak will show up in the WSS/PWS/commit sizes of the affected processes, but that doesn't mean that the root cause is in the affected process (nsi). As explained in KB 2847346, processes that don't cancel notifications can causensito leak. – strix Aug 30 '16 at 17:23