2

svchost и nsi на протяжении многих лет постоянно ассоциировались с утечками памяти, а поиски в Google вызывали много хитов (но мало решений). Связанные вопросы с соответствующими ответами задавались много раз на суперпользователе в прошлом, но все, что я видел, было людьми, спрашивающими, как определить, какой процесс содержит утечку, которая не очень помогает, если я уже знаю это.

Я открываю этот вопрос, потому что проблема, кажется, сохраняется, несмотря на заявления о том, что это решение было исправлено тем или иным способом, а также сообщать о результатах моего собственного расследования, если это будет полезно, и посмотреть, как еще я смогу разобраться в проблеме.

Единственное, что можно было предположить для решения проблемы, - это применение базы знаний 2950358 (извините, я не могу ссылаться из-за отсутствия репутации), но установщик просто говорит, что это обновление не применимо к этой системе.

Машина, ОС и программное обеспечение: Win7 Pro x64, 8 ГБ памяти с видео nVidia GTX 580 (драйверы от nVidia, 372.54 от 15 августа, то есть 15 дней назад на момент написания этой статьи). Процессы, которые почти всегда работают, включают Spotify, Chrome (в настоящее время v52.0.2743.116), Skype (в настоящее время 7.26.0.101), а также несколько процессов Cygwin mintty , bash и ssh . Internet Explorer не установлен (за исключением битов, которые нельзя удалить). Обычные надстройки браузера, такие как flash для yt и т.д. Ничего особенного, хотя некоторые из них интенсивно используют сетевые технологии и могут, теоретически, быть вовлечены, если верить подобным KB 2847346. Все обновления Windows, включая последнее необязательное обновление, были применены.

Пропустив некоторые промежуточные шаги, я разделил nsi на его собственный svchost , перезагрузил и затем каждую секунду регистрировал вывод tasklist для идентификаторов PID процесса nsi и svchost к которому раньше принадлежал nsi . Результаты представлены здесь ; конечно, последний в основном плоский, но nsi растет с постоянной (если не увеличивается) скоростью.

В то же время я использовал procmon для записи вызовов sys, сделанных nsi , но все события, кроме 6, были событиями Create Create и Thread Exit, что не очень полезно. Все, что вызывает проблему, не заставляет nsi создавать собственные системные вызовы .

Перед тем, как разделить nsi , я проводил аналогичную трассировку в течение почти четырех дней, и этот экземпляр svchost стартовал с 24 МБ и непрерывно рос до примерно 2150 МБ, прежде чем я его остановил, причем скорость изменения, очевидно, со временем возрастала. В прошлом я видел сбойный процесс svchost более 6 ГБ, но с procmon я начал исчерпывать память. Пару раз какая-то память освобождалась, но не так сильно, как было выделено. Я могу связать этот график позже, если кто-нибудь захочет его увидеть.

Я также следил за этим с помощью procmon и мог обеспечить разбивку событий, но они, вероятно, не очень интересны, учитывая, что он установил nsi который виноват, и что ни одно из его событий не особенно интересно.

Есть ли какой - либо инструмент для отслеживания , какие процессы делают запросы конкретной услуги?

Каков мой следующий шаг, учитывая, что исправление, очевидно, релевантное KB не применимо?

0