spoolsv.exe, утечка в каком-то драйвере...?
 

Принтеров не много, как юзеров по RDP.
Сервер выполняет не сложные функции терминального доступа (1С) и файлохранилища. Юзеров не более 12 одновременно, в среднем 6-8 юзеров.
Принтеров всего 4 шт., их видно на скриншоте, 4018-ых - 2 шт.
spoolsv начинает наполняться сразу же, от 11-16 Мб до тех пор, пока не кончится физическая память/или просто перестанет идти печать/зависнет все к черту. Но последнее редко случается, за сутки набегает примерно 350 и более Мб.
К сожалению не знаю как диагностировать данное явление, в логах ошибок никаких нет. Я не шибко администратор, но немного в этом понимаю. Приходится держать.
Пока решаю проблему перезапуском службы печати пару раз в сутки. Благо действо занимает от 1, до 5 секунд.
Соответственно при наполнении spoolsv более 500 Мб, печать идет с задержкой до 10 секунд. Ну и тормозит все начинает потихоньку.
Драйвера все последние стоят.
Принтеры сетевые (к серверу не подключен ни один), но установлены как локальные.
Ну и вопросы такие конкретно:
-как узнать что именно заставляет раздуваться spoolsv,
-и если узнаем, что делать? Выкидывать принтер?
Спасибо за помощь.

А что происходит с папкой C:\Windows\System32\spool\PRINTERS от времени?

anderson-7, ничего, она пуста. Так же как и остальные папки. Сама папка spool весит 170 Мб, из которых 169 Мб - это drivers. Тут все в порядке по моему.
Сейчас spoolsv достиг 50 Мб. Я его перезапустил час назад наверное.

spoolsv в процессах в единичном экземпляре?
Какие то утилиты от драйверов на принтеры тоже подгружены в процессах?

anderson-7, Да, spoolsv один. Подгружены:
CNAB7SWK.exe
CNAB8SWK.exe
CNABCSWK.exe
CNAP2LAK.exe

Некоторые по несколько экземпляров на каждого терминальное подключение.
У меня есть предположение, что в этом виновата утилита Canon....висит в трее Принтер CAPT называется. Она постоянно хочет мониторить принтер, но этой ей не всегда удается. Иногда компьютеры с принтером отключены например.
Но его нельзя НЕ ставить. Он появляется после установки драйвера...на lbp3010 или lbp6000.

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

anderson-7, сейчас убрал из Автозагрузки, я просто там и не глядел, но кажется, они все равно запустятся, при первой же печати. Сегодня попробую перезагрузить сервер, он уже более 2 недель работает. За одно и проверю эту версию, может и будет эффект.

Посмотрите в VMMap.
Другие варианты можно поискать по запросу Windbg process memory leak.

Цитата Petya V4sechkin:
Посмотрите в VMMap. »
Скачал, поставил трасерт, вот первые результаты заскринил.
Драйверные утилиты отключил. Плюс заметил, что переполнение происходит даже в том случае, когда по RDP никто не подключен.
Но, в онлайне остаются два принтера...это один mf4018 и lbp3010 чаще всего круглые сутки. Сейчас все хосты с принтерами в оффлайне, только один хост с mf4018 работает. Память продолжает пожираться. Видимо...память пожирается не зависимо от того, в онлайне ли принтер с проблемным драйвером на данный момент времени.(предположительно).
----
Я в этом не очень всем шарю, по этому, прошу прощения заранее если не пойму чего-то. С серверами не часто общаюсь, вообще я тут и эникей и электрик и т.п. персонал в одном лице. Но сервер поднимал сам, 1С КА+RDP+Файл.серв.+VPN меж двух офисов и рещение всех траблов с инетом, хостами и просто не умением чего-то делать на компьютере юзером....отвечаю я.
----
Но т.к. планирую уходить через 2-3 месяца, хотелось бы оставить безпроблемный простой сервер передав пароли при уходе руководителю.
Да и самому интересно, что же это такое...раньше такого не было, в течение года, а может просто не было замечено мной. Каких-то глюбальных изменений в конфигурации чего бы то ни было в сервере...не было. Кроме периодического открытия и продувки компрессором от пыли.

Котяр, по VMMap видно только, что утечка в Heap.
Теперь щелкайте в нижней части окна на каждой строчке Heap и в меню View -> Strings (если повезет, там будет что-нибудь интересное).

Petya V4sechkin, В большей части heap'ов фигурирует один из хостов, на котором раньше был один из mf4018, но в связи с перестановкой переткнул принтер на другой хост...хм...в Heap'ах много всего, но больше всего то, что прикрепил. За менее чем 12 часов spoolsv сожрал уже 250 Мб.
Вот что большей частью идет. Либо этот хост в одиночку, либо попеременно с \\Server (это имя сервера).
Либо этот же хост с какими нибудь принтерами...
Да много чего, в общем, в heap'ах упоминаются все принтеры/драйверы...что я думаю норма...
Сейчас посмотрю что там с тем самым хостом kos-nb-1.
---
Посмотрел, ничего подозрительного не обнаружил...Все в порядке.
Странные дела, да и не должны хосты как-то воздействовать на spoolsv который находится на сервере....

воспользуйтесь LeakDiag. Она умеет мониторить вызовы диспетчера кучи(Heap Manager) и пишет в лог стек трейс.

хотя не, утилита устаревшая. Лучше заюзать appverifier, он вместе с ОС поставляется, лежит в system32. Правда использовать нужно в совокупности с Debugging Tools for Windows . Алгоритм поиска утечки заключается в отслеживании открытых и закрытых дескрипторов. Если интересно, можно попробовать.

Efir, конечно интересно, только я в этом видимо совсем буду тупить, но, час мануалы посмотрю.
Debugging Tools for Windows мне видимо x64 надо найти? Вы дали ссылку на х32. Хотя я не давно скачивал пакет sdk, час оттуда поставлю, там должен быть Deb.Tools. А вот шо делать дальше...

разрядность не имеет значения, отладочные примитивы осуществляет ос.
я к сожалению сегодня не дома, возможно вечером напишу, т.к. мне самому нужно руководствоваться литературой. Да, Debugging Tools for Windows входит в SDK, можете брать оттуда. Для начала установите Debugging Tools и настройте отладочные символы. В диалоге "Свойства системы" на вкладке "Дополнительно" есть кнопка для открытия диалога "Переменные окружения". Создайте там переменную с именем _NT_SYMBOL_PATH и значением srv*d:\symbols*хттп://msdl.microsoft.com/download/symbols;cache*d:\symbols, где d:\symbols, - это путь, по которому отладчик будет кешировать отладочную инфу, можете указать свой. хттп замените на http, а то двиг форума ссылку делает.

Efir, это в системные переменные среды вбить верно?
Вроде сделал, мануалов не много гугл выдает. Особо толкового не смог ничего найти.
А вот ****msdl.micro******nload/symbols** это что-то вроде словаря видимо, если я правильно понимаю, для удобного вывода информации?
Я тут пока методом научного тыка windbg x64...запустил...тыкаю :wild:

да, все верно проделано.

ну что-то типа. Когда пишется программа, переменные и функции именуются. После компиляции, тобишь преобразовании исходного кода в машинный, эти имена превращаются в цифры(адреса). Так как исходный код майкрософт не предоставляет, то во время отладки видно лишь мало о чем говорящие цифры. Поэтому они предоставляют файлы, в которых и хранится информация о том, как называется та или иная функция или переменная и таким образом видно в какой функции мы находимся во время отладки, как выглядит последовательность вызовов функций и т.д. Вот эти файлы скачиваются отладчиком по указанному выше урл.

Котяр, в предыдущем сообщении я рекомендовал вам поисковый запрос Windbg process memory leak.
Ссылок столько, что аж глаза разбегаются.

Пример
Memory Leak Analysis using Windbg

Да понятно что разбегаются, они по большей части копи пасты одного и того же. Я все эти шаги делал, но ничего из всего этого понять не удалось, мало того, при аттаче к процессу, он перестает работать. То есть печать останавливается, что не допустимо в рабочее время.
Я конечно попробую после работы...но, сами понимаете, после работы - это после работы. Но раз уж взялся...попробую сегодня вечером.

Чуть подробней изучил вопрос, пару советов спросил у братухи и стало ясно, что способов локализовать утечку в куче вагон и маленькая телега. Используя WP Toolkit, Application Verifier, WinDbg из Debugging Tools for Windows или User-Mode Dump Heap из того же пакета.

Вкратце как работает спулер печати. Если знаете, можете пропустить абзац. Драйверы принтеров, физических или виртуальных, не важно, представляют собой динамические библиотеки, которые загружаются в контекст процесса spoolsv. Автоматически загружаемые модули можно увидеть, используя утилиту Autoruns. На скриншоте ниже видно список автоматически запускаемых подсистемой печати библиотек.



На скриншоте ниже, с помощью Process Explorer , можно видеть загруженные на данный момент в адресное пространство spoolsv драйвера принтеров.



Драйвера коммутируются с подсистемой печати посредством импорта из библиотеки spoolss.dll. На скриншоте ниже показан импорт драйвера виртуального принтера. Из названий функций видно как драйверы добавляют принтеры, открывают, перечисляют, закрывают и т.д.



В прошлом посте я хотел использовать AppVerifier, но в msdn пишут
то есть утечки детектируются только в библиотеках, которые не освобождают ресурсы во время выгрузки, тобишь кто хендл не закрыл, тот и "дал течь". Хоть и на 99% можно быть уверенным что утекает память из-за указанных выше сторонних библиотек, выгружатся они будут лишь при остановке принтспулера. Выгрузка диспетчера печати в общем-то тоже не является проблемой, ибо, как писал ТС, перезапускает его пару раз на день, когда раздувается его рабочий набор. Котяр На скриншоте Process Explorer, справа, видно версию установленных драйверов. Исправить проблему не разбираясь, можно сменив версию на более новую, либо старую, но раз уж писал столько букв, давайте добьем.

Выше Petya V4sechkin дал ссылку, в которой алгоритм поиска утечки основан на снятии дампа с кучи с помощью Windbg руками. Котяр Т.к. вам прийдется дольше разбиратся, что нужно делать и что написано в логах, предлагаю воспользоваться UMDH, которая входит в Debugging Tools for Windows, который вы уже установили. Действия ваши таковы. Снимаете с помощью утилиты 2 дампа, первый сделанный во время старта спулера, второй на ваше усмотрение, когда используемая им память подростет. Дальше с помощью этой утилиты делается сравнение дампов и анализ пишется в лог. Вот этот лог и прикрипите в тему. Как сделать дампы и лог напишу чуть позже либо можете почитать справку, там всего 3 команды.

Котяр, можете сделать дамп процесса:

1. в командной строке (cmd.exe) от имени Администратора выполните:
   
   Код:

   ---

   "путь\gflags.exe" /i spoolsv.exe +ust

   ---

   только путь правильный к gflags.exe укажите;
2. перезапустите службу "Диспетчер печати";
3. подождите немного, пока она отожрет некоторое количество памяти, чтобы утечка была видна;
4. создайте дамп процесса spoolsv.exe с помощью Диспетчера задач;
5. заархивируйте полученный DMP-файл и выложите на любой файлообменник, например http://rghost.ru

о, еще один способ, - снять дамп. Но все же umdh лучше на мой взгляд. Petya V4sechkin, как считаете?

Efir, почитал описание - да, "у ней внутре" уже все автоматизировано, пишет лог со стеком.

Petya V4sechkin, на данный момент spoolsv отъедает 3хх Мб памяти.
При попытке сделать дамп gflags - скрин.
Дамп диспетчером тоже сделал на всякий. Около 350 Мб. Сейчас заливаю.
Вот дамп диспетчером задач

umdh - не могу найти. Наверное он еще в каком-либо пакете. Я при установке, не все пакеты поставил из sdk.

он не в sdk входит, а в Debugging Tools for Windows. Следуйте советам Petya V4sechkin, а то я влез...

Это не дамп, а указание хранить stack trace database для процесса.
После этого необходимо было перезапустить службу (процесс spoolsv.exe) и подождать, когда отожрет память.
И только затем создавать дамп.

P. S. Но с umdh полегче будет анализировать, если что.

Цитата Petya V4sechkin:
И только затем создавать дамп. »
Понятно, сейчас перезагрузил сервер. Выполнил:
1)"C:\Program Files (x86)\Support Tools\gflags.exe" /i spoolsv.exe +ust
2)Начал службу печати сначала.
3)spoolsv.exe начал с примерно 14Мб. Сейчас жду переполнения, в крайнем случае, утром сниму дамп и выложу.
Вот дамп.

Efir, umdh в Debugging Tools for Windows нашел, пока идем тогда по рекомендациям уважаемого Petya V4sechkin.
А дальше посмотрим, если ничего не выйдет так...