Outpost периодически намертво вешает систему

Добрый день. Уже около полугода испытываю указанную проблему. Проявляется с непостоянными интервалами (от трёх-четырёх раз в день до раза в неделю), но всегда при возникновении сетевой активности (загрузка веб-странички, например).

Вчера наконец удалось отловить эту ситуацию в отладочном режиме. Вот эта пакость:

Код (Text):

1. 1: kd> !thread 968cb820
2. THREAD 968cb820  Cid 0004.0220  Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
3. Not impersonating
4. DeviceMap                 8ca08dc0
5. Owning Process            8654d420       Image:         System
6. Attached Process          N/A            Image:         N/A
7. Wait Start TickCount      702121         Ticks: 4574 (0:00:01:11.354)
8. Context Switch Count      41868            
9. UserTime                  00:00:00.000
10. KernelTime                00:01:13.897
11. Win32 Start Address afw (0x939a61de)
12. Stack Init 96361000 Current 96360c78 Base 96361000 Limit 9635e000 Call 0
13. Priority 16 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
14. ChildEBP RetAddr  Args to Child              
15. 963609e8 96feb139 8393586f 969ed5c8 86cd3770 nt!KefAcquireSpinLockAtDpcLevel+0xa (FPO: [0,0,0])
16. 96360a68 84b4c0b0 02abb1e4 00000000 00000000 wanarp!WanNdisReceivePackets+0x217 (FPO: [Non-Fpo])
17. 96360a9c 84b3ebef 009ed5c8 86cd3770 00000000 ndis!ndisMIndicateNetBufferListsToOpen+0xab (FPO: [Non-Fpo])
18. 96360c28 84a7f57f 87e0f470 969ed5c8 00000000 ndis!ndisMDispatchReceiveNetBufferLists+0x7c (FPO: [Non-Fpo])
19. 96360c44 84aaaccd 87e0f470 86cd3770 00000000 ndis!ndisMTopReceiveNetBufferLists+0x2c (FPO: [Non-Fpo])
20. 96360c60 84aaaca4 96829158 86cd3770 00000000 ndis!ndisFilterIndicateReceiveNetBufferLists+0x20 (FPO: [Non-Fpo])
21. 96360c7c 939915a0 96829158 86cd3770 00000000 ndis!NdisFIndicateReceiveNetBufferLists+0x1b (FPO: [Non-Fpo])
22. 96360cb8 84aaaccd 96824008 86cd3770 00000000 pacer!PcFilterReceiveNetBufferLists+0xd2 (FPO: [Non-Fpo])
23. 96360cd4 84aaaca4 968bec10 86cd3770 00000000 ndis!ndisFilterIndicateReceiveNetBufferLists+0x20 (FPO: [Non-Fpo])
24. 96360cf0 939a5677 968bec10 86cd3770 00000000 ndis!NdisFIndicateReceiveNetBufferLists+0x1b (FPO: [Non-Fpo])
25. WARNING: Stack unwind information not available. Following frames may be wrong.
26. 96360d2c 939a62f1 968c3b20 00000000 00000000 afw+0x3677
27. 96360d7c 83a27f7a 968be10c 052baba4 00000000 afw+0x42f1
28. 96360dc0 83890efe 939a61de 968be10c 00000000 nt!PspSystemThreadStartup+0x9d
29. 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Как видно, поток Outpost'а вызывает NdisFIndicateReceiveNetBufferLists, что в результате приводит к попытке захвата уже захваченного спинлока. Более подробно, происходит это вот здесь (wanarp.sys):

Код (Text):

1. CPU Disasm
2. Address   Hex dump          Command                                                                   Comments
3. $+812E      8B4E 34         MOV ECX,DWORD PTR DS:[ESI+34]                                             ; spinlock address
4. $+8131      8B3D 60B13900   MOV EDI,DWORD PTR DS:[<&ntoskrnl_exe.KefAcquireSpinLockAtDpcLevel>]
5. $+8137      FFD7            CALL EDI                                                                  ; deadlock here
6. $+8139      8BCB            MOV ECX,EBX
7. $+813B      FF15 5CB13900   CALL DWORD PTR DS:[<&ntoskrnl_exe.KefReleaseSpinLockFromDpcLevel>]
8. $+8141      837E 40 00      CMP DWORD PTR DS:[ESI+40],0
9. $+8145      8B46 08         MOV EAX,DWORD PTR DS:[ESI+8]
10. $+8148      8B5E 0C         MOV EBX,DWORD PTR DS:[ESI+0C]
11. $+814B      8945 C8         MOV DWORD PTR SS:[EBP-38],EAX
12. $+814E      74 05           JE SHORT 00399155
13. $+8150      8D4B 20         LEA ECX,[EBX+20]
14. $+8153      FFD7            CALL EDI

Если спилок освободить/обнулить вручную, то система продолжает стабильно работать, как ни в чём не бывало. Но предположительно он должен самостоятельно освобождаться тут:

Код (Text):

1. CPU Disasm
2. Address   Hex dump          Command                                                                Comments
3. $+83BE      8A55 0B         MOV DL,BYTE PTR SS:[EBP+0B]
4. $+83C1      8B4F 34         MOV ECX,DWORD PTR DS:[EDI+34]
5. $+83C4      8B35 08B03B00   MOV ESI,DWORD PTR DS:[<&HAL.KfReleaseSpinLock>]
6. $+83CA      FFD6            CALL ESI                                                               ; release spinlock

Если кто-то сталкивался и разбирался или кому-то просто будет интересно разобраться, мне бы хотелось получить ответы на следующие вопросы:
1) Что это за спинлок? (выглядит, как лок для каждой из структур, указатели на которые находятся в таблице _g_puipConnTable)
2) Я бы и рад свалить вину на Outpost, т.к. поток его, но не видовый ли это баг на самом деле? В общем, кто виноват?
3) Самый фантастический вопрос. Как от этого избавиться? А то, когда из-за попытки заглянуть в какую-нибудь онлайн-справку всё виснет в разгар работы при нескольких открытых проектах и работающих виртуалках, просто ноут об стену разбить готов.

Система: Vista (6.0.6002) SP2
Версия Outpost: 7.1 (3415.520.1247)
Версия ndis.sys: 6.0.6002.18005
Версия wanarp.sys: 6.0.6001.18000
Версия afw.sys: 1.0.509.11220

 

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

 

int_256
Наверное, я рискую получить ещё один совет в духе "выкинь висту", "выкинь ноут"... или ещё что похуже, но всё таки сошлюсь на то, что уже сказал выше: предположительно это баг Windows, а не Outpost, т.к. спинлок принадлежит внутренней системной структуре и захватывается/освобождается системной функцией.

 

Outpost действительно какашка. Бсодов не было, но тормоза у меня были эпические. Try ZoneAlarm. Хотя мне и встроенного фаера хватает.

 

Гуан авер. Всё есчо думаете что фаер вас защитит от сплоитов ?

 

Booster
Ну мне встроенного не хватает, а к интерфейсу и гибким настройкам Outpost привык как-то.
gaeprust
Эм... Не до конца понял Ваш комментарий, но на защиту от zerodays я и не рассчитываю (был где-то вопрос о результате попадания всеразрушающего ядра в неразрушимую стену). Лично я точно знаю, зачем мне фаервол, и когда и какие угрозы он мне позволяет нивелировать.

 

Ну а что там не понятно. Нормальному VX-софту без разницы ваша проактивка, она не заметна. Есть она, нет её - какая разница, если всегда права поднимаются через одей сплоит. А те патчи на NtOpenProcess - ну тут и обсуждать нечего, баян десятилетней давности.

 

Кстате известная всем ненавистная кнопка:

Это примитивная тулза холиварщика EP_XOFF. При нажатии оной отваливается абсолютно всё - и гуантрояны и паразитные аверы

 

l_inc
А что вам такого особенного нужно от стенки? Прикрыть порты можно и без него.

gaeprust

Почему? Загрузку нужно сделать, тут его стенка и прихлопнет.

 

gaeprust
Вопрос к вам как к знатоку VX. ASLR малвари сильно мешает или нет?

 

Booster
Ну как минимум нужно иметь возможность прикрывать отдельные соединения (по критериям вида: [процесс]:[протокол]:[направление соединения]:[удалённый ip]:[удалённый порт]:[локальный порт]), видеть в реальном времени соединения и иметь возможность разрывать их рантайме. Разумеется, необходимый минимум этим не ограничивается, но уже этих запросов достаточно, чтобы была необходимость в фаерволе.

 

l_inc
Если вам всё это нужно, то всё равно outpost не лучший выбор. Понимаю, отечественный производитель и всё такое, но всё же. ^)

 

Ладно. Тема, в общем-то, не об этом. Может кто-нибудь подтвердить, что баг виндовый?

 

gaeprust
Мда. Тулза то примитивная товарищ Клерк, но у вас то и такой нет И со своим срачем ни о чем (vx) вы уже порядком заипали.

Насчет фаервола, используется исключительно для возможности контролировать соединения, задавать правила для подключений. Вы же Клерк, по ходу даже не знаете предназначение софта, а уже начинаете его обсирать.

Успокойтесь, вы никому не нужны и не интересны. Оставайтесь этакой достопримечательностью васм.ру на большее вы все равно не способны.

l_inc
Это чисто Outpost. У меня последняя версия 7 падала периодически на XP где-то с месяц, в результате я плюнул и перешел на комод. Пока в синьку не улетал.

 

l_inc

Для этого минимума и 3.5 версия оного софта подходит (каких либо зависаний за 5 лет не было замечено).

 

T800
Когда жалуешься на проблемы старых версий, так крутят пальцем у виска, намекая, что "блин, ну а что ты ждёшь от такого старья с кучей непофикшеных багов?" (и я согласен, да и сам так делаю)
А когда говоришь, что последняя версия (ожидая, что вот тут уж к версии не придерутся), так всё равно с недоумением смотрят: "А нафига тебе новая? У меня вон 0.01 с прошлого века стоит, и ни одного бага".

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

И опять таки: тема не об этом.

 

l_inc, ну и зря. Дальше 3.5 аутглюк стал ммм... какашкой.
T800 аналогично.

 

l_inc
Не знаток ndis, но - http://msdn.microsoft.com/en-us/library/ff570918%28v=vs.85%29.aspx наталкивает на мысль, что виноват именно outpost.

 

Booster
Да ну. Общая рекомендация сразу свидетельствует о вине Outpost?
Меня смущает, что сразу после захвата спинлока в коде идёт освобождение другого спинлока (g_rlConnTableLock, указатель на который находится в этот момент в ebx). Т.е. вполне вероятно, что где-то другой поток в этот момент (машина двуядерная) пытается захватить g_rlConnTableLock, уже имея на руках спинлок по адресу dword [esi+34h]. К сожалению, я не догадался посмотреть, что делал другой поток.

 

l_inc

Маловероятно, код захвата спинлока один и IRQL в момент захвата равен DISPATCH. Ось сама юзает спинлоки и в случае проблем, у всех бы тоже зависало. На всякий случай ещё можно проверить на конфликт аппаратных прерываний, хотя при такой частоте появления - маловероятно.

Нет, но накасячить он конечно мог.