Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Очень странная ошибка 13.07.05 13:14 Число просмотров: 3562
Автор: amirul <Serge> Статус: The Elderman
|
> Если же нет, то подскажи чё делать дальше.
Сразу скажу, что вывод команды !analyze -v это практически все, что есть в минидампе и делать дальше просто нечего. Если бы это был полный дамп или хотя бы дамп ядра (которого в большинстве случаев больше чем достаточно), то можно было пытаться найти причину неисправности, а так я могу только попытаться объяснить что пошло не так (но не причину этого).
> NO_MORE_IRP_STACK_LOCATIONS (35)
Чтобы понять что это значит, для начала маленький ликбез. В винде весь ввод/вывод осуществляется посылкой IRP (I/O Request Packet - запрос на ввод/вывод) объектам-устройствам (DEVICE_OBJECT). Объект устройство не всегда как то связан с чем то "железным", это просто такая штука, которая может принимать и обрабатывать запросы на ввод вывод. Эти объекты-устройства существуют не сами по себе, а в стеках устройств (типа цепочки). Например "файловая система"->"логический том"->"физический диск"->"мост PCI-IDE"->"PCI" (в реальности он может выглядеть не так - это всего лишь пример).
Каждое из этих устройств в стеке выполняет свою строго определенную часть работы, а за остальной частью работы обращается к устройствам ниже себя в стеке. Например, файловая система получает запрос прочитать из определенного файла определенное число байт. Драйвер, контроллирующий устройство "файловая система", преобразует этот запрос в серию чтений кластеров на диске: сначала надо найти этот файл в каталоге (читаются кластеры каталога), из каталога файловая система узнает какие кластера соответствуют запрошенной области файла, и наконец читает эти кластера.
Само чтение кластеров производится запросом к нижележащему устройству. Устройство "логический том" может быть софтверным RAID-ом или просто партицией на диске, оно преобразует логические номера кластеров в томе в конкретные секторы конкретных дисков и передает запрос на чтение им. В самом низу стоит драйвер, выполняющий непосредственную работу с "железякой" - чтение/запись в порты ввода/вывода, обработку прерываний и пр..
Кроме "разделения труда" эта система позволяет еще и безболезненно добавлять функциональность. Например для создания шифрованного диска нужно просто вставить прослойку между файловой системой и логическим томом, для антивирусного монитора можно получать все запросы на открытие файла и проверять его перед тем, как открывать, файрволы могут фильтровать пакеты/соединения (у сетевых протоколов тоже есть свои стеки устройств) и пр.. Для этого необходимо просто вставить свой объект-устройство в стек.
Сам IRP состоит из заголовка, в котором записана общая информация о запросе и stack location-ов (по одному на каждое устройство в стеке). Когда драйверу устройства необходимо обратиться к нижележащему устройству, он получает stack location этого устройства, заполняет запрос к нему и вызывает IoCallDriver. Обычно при создании IRP указывается какому стеку устройств он будет послан и система определяет сколько stack location-ов должно быть в этом IRP (фактически количество устройств в стеке).
Если все, кто встраивается в стек написаны правильно, то проблем не возникает. Если же кто-то начинает "нечестную игру" (например пакет перехватил, а в стек не встроился и пытается еще и преобразовать этот пакет в новый IoCallDriver, если встроился после того, как был сгенерирован IRP, но до того как он обработан и прочее)
> STACK_TEXT:
> b288ace8 805174bb 00000035 f9b86978 00000000
> nt!KeBugCheckEx+0x19
> b288ad00 b2eec58f f9b869e8 f9b86978 fe9ac320
> nt!IopfCallDriver+0x17
> b288ad2c b2ee64b5 00b869ec 02b86978 e1751640
> netbt!NTReceive+0x351
> b288ad48 804dfdfd e09ac320 f9b869e8 f9b86008
> netbt!NbtDispatchInternalCtrl+0xcf
> b288ad58 b2c31d9a fdde8dd8 80543a00 fdde8da0
> nt!IopfCallDriver+0x31
> b288ad88 b2c06ae4 00000000 f9b8db70 00000000
> srv!SrvFsdRestartWriteAndX+0x299
> b288adac 805609b0 f9b86008 00000000 00000000
> srv!WorkerThread+0x11c
> b288addc 804e8c54 b2c069c8 fdde8da0 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x16
Не совсем понятно куда netbt пытается отослать IRP (только что проверил - на моей системе под ним в стеке нет никаких устройств). Вообще тут надо разбираться с netbt (а я о нем практически ничего не знаю), на это нет ни времени ни возможности (по минидампу все равно ни фига не получится понять).
Короче, я бы тут подозревал в первую очередь фильтры (драйвера, которые каким то образом меняют способ обработки запроса путем его перехвата) - в первую очередь, как тебе уже подсказали, файрвол и антивирус. А вообще лучше переставь систему.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
