Файл: Руссинович М., Маргозис А. Утилиты Sysinternals. Справочник администратора 2012.pdf

Зависание и плохая производительность  

Глава 17  423 

eax=61192840 ebx=00000080 ecx=0000000f edx=00000074 esi=7c829e37 edi=40100080
eip=7c82860c esp=61191c40 ebp=61191cdc icpl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!Ki FastSystemCall Ret:
7c82860c c3               ret

0:223> knL
 # ChildEBP  RetAddr
00 61191c3c  7c826e09 ntdll!KiFastSystemCall Ret
01 61191c40  77e649ff ntdll!ZwCreateFile+0xc
02 61191cdc  608c6b70 kernel 32!CreateFileW+0x377
WARNING: Stack unwind information not available. Following frames may be wrong.
03 61191cfc  7527e1a6 SAVFMSEVSAPI+0x6b70
04 00000000  00000000 0x7527e1a6

Как иногда бывает, отладчик не знал, как интерпретировать стек, встретив 

фрейм, указывающий на Savefmsevsapi — образ, для которого не смог полу-
чить символы. Символы для большинства образов Microsoft опубликованы 
на сервере символов Microsoft, а значит, это, скорее всего, была сторонняя 
библиотека DLL, загруженная в процесс Store.exe, на которую и пало подо-
зрение. Команда lm, выводящая список модулей и информацию о версиях и 
путях загруженных образов, показала, что Savfmsevsapi — часть программы 
антивирусной защиты почты от Symantec:

0:000> lmvm SAVFMSEVSAPI
start     end            module name
608c0000  608e9000       SAVFMSEVSAPI T  (no symbols)
    Loaded symbol   image file:   SAVFMSEVSAPI.dll
    Image path:  C:\Program Files\Symantec\SMSMSE\6.0\Server\SAVFMSEVSAPI.dll
    Image path:  C:\Program
    Image name:  SAVFMSEVSAPI.dll
    Timestamp:        Wed Jul 08 03:09:42 2009 (4A547066)
    CheckSum:         00033066
    ImageSize:        00029000
    File version:     6.0.9.286
    Product version:  6.0.9.286
    File flags:       0 (Mask 0)
    File OS:          10001 DOS Winl6
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Эндрю проверил другие дампы, и нашел в них то же самое. Все указывало 

на виновника — программу от Symantec. Эндрю, с разрешения администра-
тора, отправил дампы и результаты анализа в службу поддержки Symantec. 
Через несколько часов оттуда сообщили, что дампы действительно указы-
вают на проблему с последней версией антивируса, и прислали исправле-
ние ошибки. Администратор установил его и продолжил мониторинг, чтобы 

SIN_ch_17.indd   423

27.12.2011   14:41:30

424  Часть 

III   

Поиск и устранение сбоев: загадочные случаи

убедиться в устранении проблемы. Производительность вернулась на обыч-
ный уровень, а длинные задержки исчезли.

Однако через какое-то время администратор стал получать жалобы от 

некоторых пользователей Outlook на единичные случаи зависания длитель-
ностью до минуты. Эндрю попросил прислать соответствующий 12-часовой 
журнал Performance Monitor, но в этот раз очевидной аномалии не было.

Предполагая, что зависания будут видны в истории использования ЦП 

процессом Store.exe, он удалил все счетчики, кроме счетчика ЦП, и обна-
ружил три скачка в утренние часы, когда пользователи начинали входить в 
систему и повышать нагрузку на сервер (рис. 17-29).

Рис. 17-29.  Скачки использования ЦП процессом Store.exe примерно в 8:30 утра

Поскольку сервер был восьмиядерным, диапазон значений счетчиков 

утилизации ЦП процессом был 0–800, так что скачки были далеки от того, 
чтобы замедлить систему, но они были явно выше обычного. При дальней-
шем рассмотрении и масштабирования вертикальной шкалы для выделе-
ния скачков Эндрю обнаружил, что средняя загруженность ЦП всегда была 
ниже 75% одного ядра, а пики длились 15-30 секунд (рис. 17-30).

Обычная загруженность < 75%

> 10 секунд

Рис. 17-30.  Просмотр пиков использования ЦП

SIN_ch_17.indd   424

27.12.2011   14:41:30

Зависание и плохая производительность  

Глава 17  425 

Что делал сервер Exchange во время пиков? Они были слишком ко-

роткими и случайными по амплитуде, чтобы администратор смог запу-
стить ProcDump и получить необходимые дампы. К счастью, я разработал 
ProcDump с учетом именно такой ситуации и предусмотрел поддержку не-
скольких условий создания дампа. Например, можно настроить ProcDump 
для генерации дампа процесса, когда тот завершается, или когда его закры-
тая память превышает определенный объем, и даже когда достигается ука-
занное значение счетчика производительности. Однако основное условие 
запуска — превышение процессом указанного порога утилизации ЦП в те-
чение указанного промежутка времени.

Из журнала Performance Monitor Эндрю получил информацию, необхо-

димую для составления условия получения дампов при возникновении пи-
ков использования ЦП:

procdump.exe -n 20 -s 10 -c 75 -u store.exe c:\dumps\store_75pc_10sec.dmp

С такими параметрами ProcDump генерирует дамп процесса Store.exe, 

когда использование ЦП этим процессом превышает 75% (-c 75) для одного 
ядра (-u) в течение 10 секунд (-s 10). Перед завершением работы генери-
руется 20 дампов (-n 20) в папке C:\Dumps под именами, начинающимися 
с «store_75pc_10sec». Администратор выполнил эту команду, перед уходом 
дамой, а на следующее утро имел 20 дампов. Он отправил их Эндрю, кото-
рый просмотрел их в отладчике Windbg по очереди.

Когда Procdump генерирует дамп по условию о превышении использо-

вания ЦП, в файле дампа устанавливается контекст потока, потреблявшего 
наибольшее количество ресурсов ЦП во время создания дампа. Поскольку 
команды отладчика для выгрузки дампа стека выполняются в контексте те-
кущего потока, достаточно просто выполнить их для просмотра стека про-
цесса, с наибольшей вероятностью вызвавшего пик утилизации ЦП. Больше 
половины дампов не содержали полезной информации, так как были полу-
чены уже после скачка, или когда выполнялся код, явно не имеющий отно-
шения к проблеме. Однако в нескольких дампах были данные, аналогичные 
показанным на рис. 17-31.

Рис. 17-31.  Стек Store.exe c инструкцией store!TWIR::EcFindRow+0xae

SIN_ch_17.indd   425

27.12.2011   14:41:30

426  Часть 

III   

Поиск и устранение сбоев: загадочные случаи

Выделенный на рисунке фрейм указывает на функцию Store EcFindRow, 

что говорит о том, что пики вызваны длительными запросами к базе данных. 
Такого рода запросы выполняются, когда Outlook обращается к папке почто-
вого ящика, содержащей тысячи элементов. Эндрю предложил администрато-
ру проверить большие почтовые ящики и дал ссылку на статью службы под-
держки Exchange, в которой рассказывается, как делать это в каждой из вер-
сий Exchange (http://msexchangeteam.com/archive/2009/12/07/453450.aspx).

Созданный сценарий показал, что у нескольких пользователей в пап-

ках хранятся десятки тысяч писем. Администратор попросил этих поль-
зователей оставить не более 5000 писем (это рекомендованное число для 
Exchange 2003, в каждой версии оно увеличивается, и для Exchange 2010 со-
ставляет 100000), заархивировав их, удалив или переложив в другие папки. 
Через пару дней пользователи привели свои почтовые ящики в порядок и 
жалобы полностью исчезли, а последующий мониторинг показал, что про-
блема устранена.

Так ProcDump помог распутать сложный случай с зависанием Outlook.

SIN_ch_17.indd   426

27.12.2011   14:41:31

Глава 18

Вредоносные программы

Вредоносные программы являются причиной многих компьютерных про-
блем. По определению они всегда выполняют действия, нежелательные для 
пользователя. Иногда они пытаются сделать это по-тихому, чтобы пользо-
ватель не заметил их, а иногда — явно, как описано в разделе «Дело о вре-
доносном ПО, завершающем процессы» этой главы. Как и многие обычные 
программы, вредоносные программы нередко содержат ошибки в коде. Но, в 
отличие от большинства нормальных программ, вредоносные часто активно 
препятствуют их обнаружению и удалению.
•  Случай с вирусом, блокирующим утилиты Sysinternals, интересен, по-

тому что касается программы, целенаправленно блокирующей запуск 
утилит Sysinternals. Естественно, проблема была решена с помощью ути-
лит Sysinternals.

•  Случай с вирусом, завершающим процессы произошел, когда мы закан-

чивали писать эту книгу. Знакомый Аарона принес лэптоп своего сына, 
чтобы почистить его. Вирус не сдавался по-хорошему, Autoruns в безо-
пасном режиме было явно недостаточно.

•  Случай с поддельным компонентом системы демонстрирует использо-

вание утилиты Strings для поиска вредоносного ПО.

•  Случай с таинственной точкой ASEP описывает вирус, создающий соб-

ственную точку расширения автозапуска (Auto-start Extensibility Point, 
ASEP). Проблема решена при помощи ListDLLs, Procmon, Procexp и 
Autoruns.

Вирус, блокирующий утилиты Sysinternals

Знакомый попросил одного пользователя утилит Sysinternals взглянуть на 
систему, подозревая, что она заражена. Запуск и вход в систему происходи-
ли очень долго, а поиск с помощью Microsoft Security Essentials никогда не 
доходил до конца. Пользователь поискал необычные процессы в Диспетчере 
задач, но ничего особого не нашел.

SIN_ch_18.indd   427

27.12.2011   14:42:24